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 2E024C7EE22 for ; Wed, 10 May 2023 21:45:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7E4AA6B0075; Wed, 10 May 2023 17:45:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 76D6F6B0078; Wed, 10 May 2023 17:45:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 634EC6B007B; Wed, 10 May 2023 17:45:22 -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 4FB6C6B0075 for ; Wed, 10 May 2023 17:45:22 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2348DC0B60 for ; Wed, 10 May 2023 21:45:22 +0000 (UTC) X-FDA: 80775676884.10.8FFB080 Received: from mail-ed1-f53.google.com (mail-ed1-f53.google.com [209.85.208.53]) by imf27.hostedemail.com (Postfix) with ESMTP id ED05E40008 for ; Wed, 10 May 2023 21:45:19 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="A2y4/B83"; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.53 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=1683755120; 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=yg4iZ/HI0Blb6XBzcbcI5diYEFjNlGnB/Pzpil/jZVo=; b=MaX9OUuKHCDqT7acld0mCwfFHH+8YzTfbnRxtb6O7PnBdTv+rRbu/d8M+trAyMfhnXSiRR bKZwY2KQWWUuS/pAIH0x+mvwweGiGdAPLnGgTQ3rjv+yTt0CZp6swxkF7WRqGhYenSCNMJ ENtaviX0n7zwtvsCusHPHE5DO4OmB+k= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="A2y4/B83"; spf=pass (imf27.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683755120; a=rsa-sha256; cv=none; b=HBDrM67T1dyNdujWPSxjh/snjJ8fv6LvAVtHMpCobd/PtlXf/nHnbcVjbkaNGfv07dE3F1 yQw+uLAqbCYmCTnwttiMMk4sbKmicaNbVz2BdrUyFKB0Y4gExEg5bllTdGfY7Htv2oD+Z3 B5hEvEsgz05TKyV7v6MVLxpFY6gajVY= Received: by mail-ed1-f53.google.com with SMTP id 4fb4d7f45d1cf-50bc2feb320so12208896a12.3 for ; Wed, 10 May 2023 14:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1683755118; x=1686347118; 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=yg4iZ/HI0Blb6XBzcbcI5diYEFjNlGnB/Pzpil/jZVo=; b=A2y4/B83HvTFSnMTBk8VHtO0cL1+1lzA88NTn16ESPv2pLwq45zriBNreF50kN3nBM 7QqciVdOv+twhuQ1+dm1Kwes8Bg3YtMUwAuqGnBX8AW+EYhDss2R1z+qL6eQwL+QPM4F vN42T3YB/pdATLuwSLmBZuURJz+uORabkZJoc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683755118; x=1686347118; 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=yg4iZ/HI0Blb6XBzcbcI5diYEFjNlGnB/Pzpil/jZVo=; b=bFGZHXPzV24IOuIxBfUnOSzi/oURBqkEVzIyu0VikRD5E5vgagKF9IaKnlS6zTEsFD 50NUz+M/8MldpOG6QI3PLhfopfN1w6YOVK8xf/pSatxuhzTbVp6wRswTdZq9qHs+8BXC EenxJ7P4bQpngTYl2I23Ad5DXTT/vrGtloR6p3Qwm+6rYXDYDhvfTrYImTxpF2qepI4I Cvt1XIaHwshFmWqy4JTBmLA1UqjAR0fbEZBVQXjgcATnKocU/XBLimHheiA0YpqNcgpY U8l04luSxLVQiNFVeDMRY+z8dD9MbPSiaPCTOBq0ccALZLarRgEF2C58vUKb8m/+a/DE VVeA== X-Gm-Message-State: AC+VfDy2WHEhnFAGICp+ATu/QAbkL52kMmcYFSZyn9KVNXj56FZDUn8x 6xi5cvoFUyo9XDzd+wTgFTtDnwr295cMZmsxf286cg== X-Google-Smtp-Source: ACHHUZ7+WjGf9WsLSevujqjU5jI4la7gCgwk/dWhqHah7tOpdEEB5OrQZ096SdDA3+Qab3pKZuCkHA== X-Received: by 2002:a05:6402:482:b0:50c:52d:7197 with SMTP id k2-20020a056402048200b0050c052d7197mr14170788edv.2.1683755118347; Wed, 10 May 2023 14:45:18 -0700 (PDT) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com. [209.85.218.50]) by smtp.gmail.com with ESMTPSA id f20-20020a056402005400b0050dbc8980c3sm2084658edu.5.2023.05.10.14.45.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 14:45:17 -0700 (PDT) Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-965cc5170bdso1142778066b.2 for ; Wed, 10 May 2023 14:45:16 -0700 (PDT) X-Received: by 2002:a17:907:7282:b0:96a:4654:9a49 with SMTP id dt2-20020a170907728200b0096a46549a49mr1324800ejc.67.1683755116622; Wed, 10 May 2023 14:45:16 -0700 (PDT) MIME-Version: 1.0 References: <20230506160415.2992089-1-willy@infradead.org> <20230509191918.GB18828@cmpxchg.org> In-Reply-To: From: Linus Torvalds Date: Wed, 10 May 2023 16:44:59 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] filemap: Handle error return from __filemap_get_folio() To: Peter Xu , Andrew Lutomirski Cc: Johannes Weiner , "Matthew Wilcox (Oracle)" , Josef Bacik , 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-Stat-Signature: wjrid7utb8qgqkc6iae9h6aopxz554og X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: ED05E40008 X-Rspam-User: X-HE-Tag: 1683755119-669609 X-HE-Meta: U2FsdGVkX1/JRgWx6inAfulbl44X+GWBh4ytWFNHzDfWd4FcgsRyZAbFSmjtJn9/elSI7TeldLv9R7oBZVO6uyD5O1Lacuobnk95p7TLhHIMsfOMixKRvdxWUnJi5z4+1ii18R51slvkUoEMCvRdut6O191MGp8epI0n+nKVsWWFZaxAJ3Daiqfk0CJZQ1OuAjtpf4+dQ3UaydKKtuXcG9rvuDSAEu2YVAwNsb726hXWUZmhCOCqYlN5UG6TkFR1NZkwC5KxCiSOIpCF1DbrfjAH/ibZEWb6EL1WGc2DwfLPZt5kM0DY0hQMflMHFfmMMXOK/dPv97OpqCoPTuHpwAtw/r/mUKZRJdEp/kslsqhkW/ggp82TROWxRiylwv5fSRxDZhAf6DBzd9qBUsg+irmUksPhc2afVO/DMTp1FkhzYYbzvH+CR8sso1lk0rOeA9apKHlOX9rM3ol1rF+HMYQbin3niOco5JzqSoX/NFei5NgGxzjtbw2+ZXWZdPwC/BWEGA1gii2j9dYHu9CKyXxfFS5hkcFASEjeTgcOu/1wsVnx44u32pL9/faHr5GCslH7vg+VGAZlNFXG73+W+ZR7HJXHXArtItaFsS77TPdARZDrmomI1RvlmbnOtGT+6wUEntDd++7rpXar3ykmCEEA+uTmwna0tCfmaG9XZPMHQiMyGU1nSMB9+Uppfe34tSX9U/JKhcCAtwOjlLvyxwMzhLFI9z++MnEr6hZohYP4DwU8eHE5Cy87brRYSjAREEMwAdHThYojvnDYipaAo0sNnjULWM8iIAebubsqCwTOswXagcFyAH+233o7WZwbrSaEkVnqh2whJcR07gePiFQ06SHRiRmGn/4LmaHBoiAeADRd2CY/UicWKUWt8fxqCjx3go6jOuDAaDLHKlvfl7Ni7UBcPYKi9mQQaANUpTuDWS0RF+m+mftKO/t3HLWnxPggaL8oIJYcnCDiXwm TWk/n0vZ WSQwhgSSNQE4xC370yalR2jl6PmIRWkXgnO3BBLL+yH5TRa8k8u0NUew2k8OKuzSBGBiy84hgkO8/99srg5YIrlD3Gq9uda0e9VE8TgdNEG8CAPAU4eYGKWAY5C0G2zFUCu63hJUyEFukLpomO708UX4llo4umCRmx2MWLZvDQbGKVRxiHzWaZY99xjaurmrH44DqDOcdwEaqsD/dwcYNQGKXVzxnCsuzuo+ziMnfJr+tfHvMnPQzZWcD2ijAKbZavY3cue5o0lArkALEpm0Tp0dWuxmTF6f3zVnJRaxyNrYtMpiRLh4fCH4MydFI4xO09zb/MKPdW5j6+lc4l5lt50RJiyhCEBDaDThlWjdfRgXDLTrDBm/eNjrYVfoix67d+9NowYR4xiKUMwnD/gXLtF/CSXkFKzZEHlc2UNb9/IlXGDqnP2If2udO+xtIjxx2IIgiM0Xjcnrbpz1ofxcxN0AyOzMAvjwfDQt6hD6aZTiO0/RvxUeaIMKT5akVgCEaIfrZ8pb2l4Dacfp7z/Awf1U7dc7ZyU2qq3E721k6NZgMlRreZ1IvhbATQf+nOQHpfWeUz9D+DLAPg9/9uNkBB37PIE4DUM4UU3wVyxXgKHRjmPOGojJo5V5i8s5lMeK8Xqihss4RvBHTnkK1FJYrQLJgvTOu8BpNT4qiDwECy9YceijR5nd0SiEf2EZfMNydWLpBakEdUmXTS4g= 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 Wed, May 10, 2023 at 4:33=E2=80=AFPM Linus Torvalds wrote: > > We'd still keep the RETRY bit as a "this did not complete, you need to > retry", but at least the whole secondary meaning of "oh, and if it > isn't set, you need to release the lock you took" would go away. "unless VM_FAULT_COMPLETED is set, in which case everything was fine, and you shouldn't release the lock because we already released it". I completely forgot about that wart that came in last year. I think that if we made handle_mm_fault() always unlock, that thing would go away entirely, since "0" would now just mean the same thing. Is there really any case that *wants* to keep the mmap lock held, and couldn't just always re-take it if it needs to do another page (possibly retry, but the retry case obviously already has that issue)? Certainly nothing wants the vma lock, so it's only the "mmap_sem" case that would be an issue. Linus