From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id ED3FAC77B73 for ; Sat, 6 May 2023 17:05:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2164F6B0072; Sat, 6 May 2023 13:05:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C63D6B0078; Sat, 6 May 2023 13:05:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08EF06B007B; Sat, 6 May 2023 13:05:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EF5A86B0072 for ; Sat, 6 May 2023 13:05:10 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9305A40777 for ; Sat, 6 May 2023 17:05:10 +0000 (UTC) X-FDA: 80760455580.21.ADB5E84 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf15.hostedemail.com (Postfix) with ESMTP id 72462A0007 for ; Sat, 6 May 2023 17:05:08 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=amO642ir; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683392708; a=rsa-sha256; cv=none; b=0AmMJFU2A/+BWuhwIHsI6QCp3KL5o+Hwx686fMLh0hNockpZSdJ8gkV0nTWL1/zlJjqJ35 73z6Lhdg5AL+lqJQ7MC+Q+Bp0uCY2VvzIoeaA2DeTTq98CVmnSO4N72t9BfbQdedyzaDGO twv1JAqaKKlWl8YTEEjaOU9ya8wzflc= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=amO642ir; spf=pass (imf15.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683392708; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=BohPGjhU0MW7cH+kq6sMfSx9As3zddOMBgwyOGlEMPA=; b=INUfCh1pmoC3jDSa8xiPyjIgLCzUyFrcZJJORBk/7dkQ4NvgrwwZ9HU3fplC15EjZRm9Oj QmYlUKN6eQQYv/5BXCcsOpnD+DSaLw8gvjsd6rR3TJVG8xa3oqPblqsrd1gDvq7R9JW+Mz 7vpGwTEi9JlK9SBW2pTF+coTvtqL4w4= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-50bcc565280so4502004a12.2 for ; Sat, 06 May 2023 10:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1683392706; x=1685984706; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=BohPGjhU0MW7cH+kq6sMfSx9As3zddOMBgwyOGlEMPA=; b=amO642irESKUrByQEGv4mG5yGNIinZSlcx8MIOGbzsrfvU5CT0tFS68FES5kxwLGSI vDEYg7um3WeTWPbk3u2BPNLkUdhx8UwYcPvsIS4ieHi9XOPiL1IEPkKmBDwOzceYERqe cUthvYyZu6h5f2/BagIcRzlgqlrdVwfzNAFYQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683392706; x=1685984706; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=BohPGjhU0MW7cH+kq6sMfSx9As3zddOMBgwyOGlEMPA=; b=CyK7WNzhJWpLM907Unf40a8fKBjszhasKa/6QYBJMZ6xJOEIfBPqtiABxr+mcbckdx yeeOB6ZPmYM7I26LqZBJJXM0vRDCM3V3le8q+b6z/iHUFlgnlfwEdf2a0ec/qBHGL2Ti S5jMHmDI8mWozG8+c8TKNIXRRgeEay1oZvVNnEJofQM64ZocxbmYF8Zdyi+7zvtWjYX5 ws5s0t3PPypRCEPwFj1LbSb+UdjvxJoB/hGLrSm4aqxbvhQPAX9yYd/wT3J3B6Tttymg YkCppss8r1uf1ZTCkJHa9A1FJp6xxwdZbOoBDfIyyJKRWF21IVN8InM/EWX5bN55z4io cVZA== X-Gm-Message-State: AC+VfDwv20WAGSsUU1p5etNQQdqfKDWZ/sqx57LOt6rooyP4cGPwnCGr kIbfLafa6IohAFqZbkt1hXcEduoxLLYJXfKIrhJ0mg== X-Google-Smtp-Source: ACHHUZ4Np+W5oiUTd5YMrAKGwjxFxA8q6x3utZcrhPfN3zUBsG5B8HvN3uhQpGa1jUrIgSJh+Lp+8A== X-Received: by 2002:a05:6402:1056:b0:506:86aa:78ed with SMTP id e22-20020a056402105600b0050686aa78edmr4638821edu.20.1683392706514; Sat, 06 May 2023 10:05:06 -0700 (PDT) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com. [209.85.208.41]) by smtp.gmail.com with ESMTPSA id q20-20020aa7cc14000000b0050c0d651fb1sm2537876edt.75.2023.05.06.10.05.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 May 2023 10:05:05 -0700 (PDT) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-50c8d87c775so2956814a12.3 for ; Sat, 06 May 2023 10:05:05 -0700 (PDT) X-Received: by 2002:a17:906:fd8c:b0:94f:3cf5:6d7f with SMTP id xa12-20020a170906fd8c00b0094f3cf56d7fmr4182892ejb.46.1683392704861; Sat, 06 May 2023 10:05:04 -0700 (PDT) MIME-Version: 1.0 References: <20230506160415.2992089-1-willy@infradead.org> In-Reply-To: From: Linus Torvalds Date: Sat, 6 May 2023 10:04:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] filemap: Handle error return from __filemap_get_folio() To: "Matthew Wilcox (Oracle)" , Josef Bacik , Johannes Weiner Cc: Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Dan Carpenter , syzbot+48011b86c8ea329af1b9@syzkaller.appspotmail.com, Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: rr8ywj69d4sbds8so8rdxrsgcddrjxa7 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 72462A0007 X-HE-Tag: 1683392708-541942 X-HE-Meta: U2FsdGVkX1/gCOcXxUoa+KnBn+xMf24rkPuf63IYjCDYM2CSN6+rfTAz7PFocxgGkt8R4alFTLOXat7v9FlZty6Jt2CL4SBJtlZXPkNJppXqr5/sqJY6f8Q03kVXGz81ALdjGcy7ZNvv1fjcl43tc3NBr+jiYEapgHsin368KfcH5iU5X3KdrRRzTVwBs91BPif9ezE+rdpP28d/2HJGgU3CKDCRCuBgWlKQZPMX/aQkDSORiKCKKbZgPC2rLJLio5SZTcP1fuhr8UMGOrkLByvMlHupLh+Try9lyn0dFLYNq9ra15SldFmb2L152pSro+2u8YTiQWjw+znuhhEZedt76LlH2HFM2I16fgdxGysJhYZHVTy4Lry8KmOD4HXyxSBKCIWNkLWCUnMcvf5FNnx1CgPw7x/yMTLTJFL2gUngzyyuXvtZly4bQYQ2wyEurFg6gneY5oAhl7nnz4F/4mfyb95cFkjmdTWJUf6OBArBJiZieOyspAllX5FJ/AwhSDEQ6SG6T+RiyeFjXj+BFmuOa/Q1zGeAEGMChZ9rslqfido5TUzpBxsfT3Qj0TcRfgaoj/riTLWjvQa88WvSzAIQ2KOpt0gwn9FK7kPLIp5wihkvZGBNngKbjEAFUO6/oYSTHO5Z/G6uxYLtOuTTXexRwlO5iVA4RfKWUvLzTFjXxQYKVabEf1Cws0G0x613YbaAybacU4mqebnLVqEd/pxnPUcWdzBJE4s2cnPb7RLCO2wsEfAi9HuKoiTbHqVoeHTUq4SphN/tBf5YgzICbiKuRodSVQYs7BHRsW5cS8Hfc4lichMPu9SGFMeb7Ln4TxQdL8l6Lvc2Or0eXGdNtiQ/k8b3qd9/nXOJKdrpyQP9dGeqeutGxw35Nw45MH0pvW7QQEtnmIyoRlr7dLzno5SH5ox/7YiFs7keePg7Pe1ETyVJK0RXynQfEgeGMoFitMBbd8lCUXXAiSgWF1u 63bWV/8G 0DAnFhf0Ctn9pJjYrYHauyjoC6I7ffo7W+UWmOOtX6yhsZqHodmd8VZOdRUdtChmPtnhl1j+xrSTpCP51znl2L6n1mQUB5g94RguWdWWzS+Y3IPZYbp86fRL5uyos5M/EmpdlDkrVGW6cJCpPcOTxcghrJMR/pBnCOyW9VMIQtfZhjllPYZfEHIqBm4cbZTWB4YCg+yU6aTXmsDIV6TyW7u5C7VtZUgh4uNwrPQ3HwvSDH9mZBdpmwJAPARiYafv9p0pvXIvgYeo0t5cZ5HhUR8LkZia/YzyNWPHCfF4Ofxa3jYkFa+SfL5tfMabFq/oIrD1b3Byn3jTNuBTfmuvMRL73+AFQA61yaclPA6n7fXWO0ud9Senrf1szALdo8Y3bsapryExQP2PRcMrCFT29t+GWB9punyLkIp8fKDMSZmRkrqjWUWeo0O+ZRk6Vl1NpAWRiOSV+TaXblmDccxUAh8zP8cjdXF2RF+ZyCAijKeLhb3WuiYkzUPpePMDmp691O2pJeRTg0IZlV/soEZTbBR5PEY6Sy3UUwL8dRcnBamLml5SeViNyT//3s56NTEUqPGjcX4zHmfrKgjXBwHyBZLQ4xqV34pezAu8cWSLfAGUePoRihULcNHB8V9SZDeDzRvePXku7hyJsp9Mc516mhKcAgRU23Mbu7XlajTuDgRCT0EZksY2KOpDJqhGftMnmQvSKdINeix0SArw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, May 6, 2023 at 9:35=E2=80=AFAM Linus Torvalds wrote: > > And yes, the simplest fix for the "wrong test" would be to just add a > new "out_nofolio" error case after "out_retry", and use that. > > However, even that seems wrong, because the return value for that path > is the wrong one. Actually, my suggested patch is _also_ wrong. The problem is that we do need to return VM_FAULT_RETRY to let the caller know that we released the mmap_lock. And once we return VM_FAULT_RETRY, the other error bits don't even matter. So while I think the *right* thing to do is to return VM_FAULT_OOM | VM_FAULT_RETRY, that doesn't actually end up working, because if VM_FAULT_RETRY is set, the caller will know that "yes, mmap_lock was dropped", but the callers will also just ignore the other bits and unconditionally retry. How very very annoying. This was introduced several years ago by commit 6b4c9f446981 ("filemap: drop the mmap_sem for all blocking operations"). Looking at that, we have at least one other similar error case wrong too: the "page_not_uptodate" case carefully checks for IO errors and retries only if there was no error (or for the AOP_TRUNCATED_PAGE) case. For an actual IO error on page reading, it returns VM_FAULT_SIGBUS. Except - again - for that "if (fpin) goto out_retry" case, which will just return VM_FAULT_RETRY and retry the fault. I do not believe that retrying the fault is the right thing to do when we ran out of memory, or when we had an IO error, and I do not think it was intentional that the error handling was changed. But I think this is all just a mistake from how that VM_FAULT_RETRY works in the callers. How very very annoying. So scratch that patch suggestion of mine, but let's bring in some people involved with the original fpin code, and see if we can find some solution that honors that error case too. Linus