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 E6573EB64DA for ; Fri, 7 Jul 2023 18:12:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D4D78D0001; Fri, 7 Jul 2023 14:12:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 184C96B0074; Fri, 7 Jul 2023 14:12:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0268F8D0001; Fri, 7 Jul 2023 14:12:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E0A216B0072 for ; Fri, 7 Jul 2023 14:12:49 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 670FC1A0524 for ; Fri, 7 Jul 2023 18:12:49 +0000 (UTC) X-FDA: 80985611658.11.36640F3 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id 422FB1C0009 for ; Fri, 7 Jul 2023 18:12:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PsvYJEbx; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of dwysocha@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dwysocha@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688753566; 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=dYp6SX4idj0K2s8mMqxJ4XFt6H9/PBaHUEfz7SiAvZA=; b=iWgbuZB9/SLb0z9H9cVGoPES1yzXoJBaCwCcRr/0XUkkMeNcfISOZr9pSm3drJQLx5pvCC lhFUK2pIm7NLEe469j98cOLvV1RujOo7ESennte/dSl8PBpOQg+GEMFSe1fSID8XPNBlqD wyWFHxsMkk8ZJOAnWs6kAS2tNbiuENY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=PsvYJEbx; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf18.hostedemail.com: domain of dwysocha@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=dwysocha@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688753566; a=rsa-sha256; cv=none; b=toE75lyuYNFoazmaW5Y4H4q/MoEFw36WDocAsF2TNCWl1J0eN6YajvmwOG2oPqHAaZm1PO qAUpR5+pny0lPu5AtQC/OyKZJD2FWrqKw1npyo0Z9tg6fmPPkyzWZyqytkEBOfNA+tUAZA 1o1E5BNDkuTUTmBzH1U88Y+m0pVQPP0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688753565; h=from:from: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; bh=dYp6SX4idj0K2s8mMqxJ4XFt6H9/PBaHUEfz7SiAvZA=; b=PsvYJEbxUBucMhQkMVERI4Y0gEC6D59jE1JTSnGBpr/j2uTq6wbAp2u6+O91yQFDF+OjMP 8sJyE4C/cuur2Tyw3y+mt5EnJMVng6NLXk7BA2akSPXx7J9ecywqo+LxBUNktYyXkpU2GM bR145k8uQxS7PfmVrCbTqr+qw75cSWU= Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-126-oKmiziTgNLWHX2dqVjxxFQ-1; Fri, 07 Jul 2023 14:12:44 -0400 X-MC-Unique: oKmiziTgNLWHX2dqVjxxFQ-1 Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-262e5e719eeso2833472a91.1 for ; Fri, 07 Jul 2023 11:12:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688753563; x=1691345563; 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=dYp6SX4idj0K2s8mMqxJ4XFt6H9/PBaHUEfz7SiAvZA=; b=NLThS8YkNmKbyRXN9suj/yjhi4rUiXDMqDnxHSQbh55QdrXAoTgFe+KGQFvQsu9U7U o18n/ivUkrJkLv/YVKzWYC+jn/H6c6esXhA+qNzFAeJbM7i143ffs3/a3hBW3KE7o6iB QvPgX3HNQ5KPoKb/aqMISkTueFOo/0O+x+sM1l7VO56uNez4P4H7B3DjDp8uZakaWzot VFSyxJW6N0+9Mp/wTtMFw9ApeuSSn7Cy3kU9jGNraMh4Ma5WlWC8Y21JKFEs1cu+5M5s A11hJ/kj2Pe+RBRfYNEwGSZnfanu+GitAG0YcA0qKg+nN1r1Bqw3rbnSLbnxu4cdU9D5 8eKQ== X-Gm-Message-State: ABy/qLYHdf10TQPtO+L0RWv1UGyfScDpQKdAeAH9Ar+gq2K4LxEaIwdi pMRxgv45LxH0SrUsOxFrtggfiD9dWurKxzCMnVQo7XlIZylXrVHjRbHuERQ4oL5AE48I6MX2I+P AKpaqyDdUVFdmmeMRIWHoisxL/4g= X-Received: by 2002:a17:90a:bd01:b0:262:b229:7e45 with SMTP id y1-20020a17090abd0100b00262b2297e45mr4613496pjr.11.1688753563140; Fri, 07 Jul 2023 11:12:43 -0700 (PDT) X-Google-Smtp-Source: APBJJlG6u68dTynLKu27IgkCmRz2kNSu4UGaUBT2IU6X1iGZYQeExxypGVXNQUOEHGzK3cyz6ytMfUjBA5GoKXPvaz8= X-Received: by 2002:a17:90a:bd01:b0:262:b229:7e45 with SMTP id y1-20020a17090abd0100b00262b2297e45mr4613468pjr.11.1688753562822; Fri, 07 Jul 2023 11:12:42 -0700 (PDT) MIME-Version: 1.0 References: <20230628104852.3391651-1-dhowells@redhat.com> <20230628104852.3391651-3-dhowells@redhat.com> In-Reply-To: From: David Wysochanski Date: Fri, 7 Jul 2023 14:12:06 -0400 Message-ID: Subject: Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0 To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: David Howells , Andrew Morton , Matthew Wilcox , Linus Torvalds , Jeff Layton , Christoph Hellwig , linux-afs@lists.infradead.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org, linux-cachefs@redhat.com, linux-fsdevel@vger.kernel.org, Rohith Surabattula , Steve French , Shyam Prasad N , Dominique Martinet , Ilya Dryomov , linux-mm@kvack.org, Daire Byrne X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 422FB1C0009 X-Stat-Signature: 9qhzn941xgu413o3itemugiperuoosaa X-Rspam-User: X-HE-Tag: 1688753566-728575 X-HE-Meta: U2FsdGVkX1+8KbQaZhrfYuEn+0UysSZHhBSlNrKUL4Z8Q5UHoaJsrO7mS/ePF7XvWOtiipxTO4F7jd2Kd0wGF70J8UMKYwkFG/Sd49pFDcYxkknE0rHPGVq70L3sreVPad2LHLAcbOWD4W6r56Tx8D5deVGZ9K+xpFClVXcYiZ2RGy9jf/rBTDzSCVktOROE4JP/cmTtQwjibDNPVMrYRd241NxVwTKeYs8R29YyvVl96ShOz5e5lGd8/u6wAgNbCJS8rccp9ONcf9Lpfq6YZhiA2zjponBkQ28Hd7d4NY19FyCrPP14MjpoGm/64BYZwVHOg+R/iAO8mpKrBate/PyPB9ZHRRkMKSHl7gOn5ZjfcuCMOY4sg/iWKXGqUNfRopnJROD/zm3ZhzhRkKazvHwrpcDRa6YYpjrQaTtF+tHiFDPYPVkSf9wYByDi6aK58cQTOJATqkO4XsAdxCuav8FXbVSV4m3bSh7vJ/vA8Pje6ah0Yyp7aWgFssEbBmP9PQJ7A1jZtXGE14mH0TcLk/YCWeswxRZlQhoeTrZGtg3Ky5dQUkDy7imyuIhm7SFlAVcIFQFk0+MC+v1/szIx26srkgvuhSgmet86wxmMqkMtcfKbWSq1T1oJM/LpRIoUIyDqsJW0QpXBcB9eY0fg4XtWDLn58a+y3hAH7k0PlLqAeDW1mxczQ16lAmkneRonHY1tXsEFpcEcterMwx0a11/FS+yHXIc/YC33PsUg7vGg5+0Sah2On/pgx2i3HbvVgzu/XGeqtkwiDUzuIiweSh/w0ClCn219JGXAf67yNFm1G2ndyU0SmMoVZSYpKf2heAY3cAmDfziNhfM7Tx11Nhz4uV9ZEUaDnO2V/C2vqghLxXxW8QQmbzy3DIz0wj4GKesnLcmyd/LQKMq8NBRP1gKT4fUAATEPN1xPXsJgXcqa3HD99G95sC/OYp9vJNTwc0EwWNoe1eGKccB84yh NhuRy4VD vIAaTJI78AOb7pP+G2SFqO9FBJzqrgMv7vQrz1NSSXh0HElTo5nrpknw+UCrIqDE6yoZrcIPru0RhfZ4nZa85c80FGdajd6r1qn5dLCJNYE3CD5MQMmN9EYFjmPWdjDnKkrj56f/3ivSME0l8TnN7RYv8VN8Jg3OYwXymrPSbwRD+HesprPgnqYuwzxxir5zJMOcBTi0dTIW8BaIEvdQM6KMnnlNuT8JHhnRdZ/1NkE4JATU/MIIGr7a3MdRnUJAF4YGv0Yltd5XhIV9r6Q/9IC0WmmAepNV+tX3JHvvU8m0uz+3pQ2wm7/lirirkK9sn1QMdl7vT66kqRLShTFAyzSHAYLoOt+fdm0W7VDYj4bGLQ6cUnbBSnGS8kEDPBe+bxRDFVr0KLIEJnFvbmPiOlHII+wbQP7ROqjmqQJLoTKnyqQboIMCTkuvf0N9X9u87Af1GFjM+n9hU2tuWKQ9xHgI7wwK2N3zpvghYBgiqRmWSLSTXa0zVw9eUNIViWvnuzR7z9bYX0DI211mnuflKR8L72g17lyPcmd8gqWB8OSVsuwlzl8kxLjqCxMBQG8tI9DtixZLhTTp+GOhujJBr2R4gVod9/bwmcvxW4UR8eKPuDnsW9bYJX0qMbe3k9E5coEZk/cvtgd4nTsH5XalDG2e2aQQHbzC566QEHrnYK5bSxiGWI91hd6eH6Gy5sdFYAFodUmxHV+XrQx7zMUqKgdbRQA== 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 Fri, Jul 7, 2023 at 12:46=E2=80=AFPM Hyeonggon Yoo <42.hyeyoo@gmail.com>= wrote: > > On Sat, Jul 8, 2023 at 1:39=E2=80=AFAM Hyeonggon Yoo <42.hyeyoo@gmail.com= > wrote: > > > > On Wed, Jun 28, 2023 at 11:48:52AM +0100, David Howells wrote: > > > Fscache has an optimisation by which reads from the cache are skipped= until > > > we know that (a) there's data there to be read and (b) that data isn'= t > > > entirely covered by pages resident in the netfs pagecache. This is d= one > > > with two flags manipulated by fscache_note_page_release(): > > > > > > if (... > > > test_bit(FSCACHE_COOKIE_HAVE_DATA, &cookie->flags) && > > > test_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flags)) > > > clear_bit(FSCACHE_COOKIE_NO_DATA_TO_READ, &cookie->flag= s); > > > > > > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to in= dicate > > > that netfslib should download from the server or clear the page inste= ad. > > > > > > The fscache_note_page_release() function is intended to be called fro= m > > > ->releasepage() - but that only gets called if PG_private or PG_priva= te_2 > > > is set - and currently the former is at the discretion of the network > > > filesystem and the latter is only set whilst a page is being written = to the > > > cache, so sometimes we miss clearing the optimisation. > > > > > > Fix this by following Willy's suggestion[1] and adding an address_spa= ce > > > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to alway= s call > > > ->release_folio() if it's set, even if PG_private or PG_private_2 are= n't > > > set. > > > > > > Note that this would require folio_test_private() and page_has_privat= e() to > > > become more complicated. To avoid that, in the places[*] where these= are > > > used to conditionalise calls to filemap_release_folio() and > > > try_to_release_page(), the tests are removed the those functions just > > > jumped to unconditionally and the test is performed there. > > > > > > [*] There are some exceptions in vmscan.c where the check guards more= than > > > just a call to the releaser. I've added a function, folio_needs_rele= ase() > > > to wrap all the checks for that. > > > > > > AS_RELEASE_ALWAYS should be set if a non-NULL cookie is obtained from > > > fscache and cleared in ->evict_inode() before truncate_inode_pages_fi= nal() > > > is called. > > > > > > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be cle= ared > > > and the optimisation cancelled if a cachefiles object already contain= s data > > > when we open it. > > > > > > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release= of a page") > > > Fixes: 047487c947e8 ("cachefiles: Implement the I/O routines") > > > Reported-by: Rohith Surabattula > > > Suggested-by: Matthew Wilcox > > > Signed-off-by: David Howells > > > > Hi David, > > > > I was bisecting a use-after-free BUG on the latest mm-unstable, > > where HEAD is 347e208de0e4 ("rmap: pass the folio to __page_check_anon_= rmap()"). > > > > According to my bisection, this is the first bad commit. > > Use-After-Free is triggered on reclamation path when swap is enabled. > > This was originally occurred during kernel compilation but > can easily be reproduced via: > > stress-ng --bigheap $(nproc) > > > (and couldn't trigger without swap enabled) > > > > the config, KASAN splat, bisect log are attached. > > hope this isn't too late :( > > > > > cc: Matthew Wilcox > > > cc: Linus Torvalds > > > cc: Steve French > > > cc: Shyam Prasad N > > > cc: Rohith Surabattula > > > cc: Dave Wysochanski > > > cc: Dominique Martinet > > > cc: Ilya Dryomov > > > cc: linux-cachefs@redhat.com > > > cc: linux-cifs@vger.kernel.org > > > cc: linux-afs@lists.infradead.org > > > cc: v9fs-developer@lists.sourceforge.net > > > cc: ceph-devel@vger.kernel.org > > > cc: linux-nfs@vger.kernel.org > > > cc: linux-fsdevel@vger.kernel.org > > > cc: linux-mm@kvack.org > > > --- > > > > > > Notes: > > > ver #7) > > > - Make NFS set AS_RELEASE_ALWAYS. > > > > > > ver #4) > > > - Split out merging of folio_has_private()/filemap_release_folio= () call > > > pairs into a preceding patch. > > > - Don't need to clear AS_RELEASE_ALWAYS in ->evict_inode(). > > > > > > ver #3) > > > - Fixed mapping_clear_release_always() to use clear_bit() not se= t_bit(). > > > - Moved a '&&' to the correct line. > > > > > > ver #2) > > > - Rewrote entirely according to Willy's suggestion[1]. > > > > > > fs/9p/cache.c | 2 ++ > > > fs/afs/internal.h | 2 ++ > > > fs/cachefiles/namei.c | 2 ++ > > > fs/ceph/cache.c | 2 ++ > > > fs/nfs/fscache.c | 3 +++ > > > fs/smb/client/fscache.c | 2 ++ > > > include/linux/pagemap.h | 16 ++++++++++++++++ > > > mm/internal.h | 5 ++++- > > > 8 files changed, 33 insertions(+), 1 deletion(-) I think myself / Daire Byrne may have already tracked this down and I found a 1-liner that fixed a similar crash in his environment. Can you try this patch on top and let me know if it still crashes? https://github.com/DaveWysochanskiRH/kernel/commit/902c990e311120179fa5de99= d68364b2947b79ec