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 C4FDAEB64D9 for ; Fri, 7 Jul 2023 16:46:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 63B3E8D0002; Fri, 7 Jul 2023 12:46:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C4178D0001; Fri, 7 Jul 2023 12:46:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43E3B8D0002; Fri, 7 Jul 2023 12:46:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 323508D0001 for ; Fri, 7 Jul 2023 12:46:48 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DC7C280121 for ; Fri, 7 Jul 2023 16:46:47 +0000 (UTC) X-FDA: 80985394854.02.33C3A60 Received: from mail-vk1-f174.google.com (mail-vk1-f174.google.com [209.85.221.174]) by imf27.hostedemail.com (Postfix) with ESMTP id 093114000C for ; Fri, 7 Jul 2023 16:46:45 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=rdIoGdwP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688748406; a=rsa-sha256; cv=none; b=w69mRLX0oGvt/3qSdvJK3oKDORxxxNcY7alWEltNgNZ6wH38hJOOFPau2S5rYYc/hKQ0Do h3EMP0DL7oHsQBvVHVDMS+Z0Duvubab0pKUJ8ZjPk8BrgKyxXzAxzv1pkweQLZtboXFfMe mqyRNTXm20SEDNqODZjXculA0UrVr4Q= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=rdIoGdwP; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf27.hostedemail.com: domain of 42.hyeyoo@gmail.com designates 209.85.221.174 as permitted sender) smtp.mailfrom=42.hyeyoo@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688748406; 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=Z/ReIviycKOpXSvVBgcqd1EotrbzaoMQKO3qVU7I/G8=; b=zCdhv5EMDwrWu/BD9IR6CNijDMhCmEAcQem4T+Kq2uiN5gjp2wZdJvtB+pzDNMI9iZt03D ZhYp7kAn+AGgXp8jkrH/j4cRANQ5DOLciWFNX0YLK935cJ7vynIabmvvr4MXB64uA90pE0 50DlWn9PJyae4xt6wjfwAX/UGlkKq9I= Received: by mail-vk1-f174.google.com with SMTP id 71dfb90a1353d-47e25709402so855783e0c.0 for ; Fri, 07 Jul 2023 09:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688748405; x=1691340405; 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=Z/ReIviycKOpXSvVBgcqd1EotrbzaoMQKO3qVU7I/G8=; b=rdIoGdwP5Ghffl0SSNU+UexYiw7dQQTY/KbUSpraUXheaqWYQIzf9VS2G54zkxoXeK Zs8WYI2qt4N0BqTuDA21gVijWUiGiy3OrYR8lv3DKyrgrFEFY/VwOEHPHcniApVN32A0 PyNQdCHlm8WB6hLN7Grylpw6RdoDNjUV6Py9A1+F4jya88T8Iq9Ka7vxdq5yT5c1LaGv mhT4LjqqufdVQx6CIlQHGhtHR9EIUodVt14QLVcTA2E3j7ZHuNoD2AWGoyZkb9l6fTKO 8M1Q1mr7rQzV9JK8pww9IzJ4dCo0vnfyDZPwzvga/a4qwpdfyRbTwoQs0RfSeuNrnbjJ agjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688748405; x=1691340405; 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=Z/ReIviycKOpXSvVBgcqd1EotrbzaoMQKO3qVU7I/G8=; b=YpxV2K6ZXl2U+mde+Bf9b/Al9/7VvwabNqh38iKLDij2FBQHETZRgWVSo8jly0RT0L IpCMVzSh6NgFpdGdr+DSmbmhLxcmJYyI9oMrUe9cD9Yq7Pvt/Eb78xGY6b82covSoFeW ttaCorY70jauXytBf8ipCoIHECp6ITy/KvtELmlgw1efJR3loUzzM1N/oehkpCHxclCA muTZFTlb6hjy+Vlu0FVTp9cFOVdnAB0KK0mcnjwWroLP/GP3P9EP8DeMDWURdpz6Lu5Y DkNQQ04lFlPojIygBp1W3d/VHFWOXj5n0UyZJsxo0tBghtSgn3mcJo4SB6iXjIfVjSri pQtQ== X-Gm-Message-State: ABy/qLY++0qtWhIoTBgdHMOwxMi1qknriVjqIckGCkVVDohYNNv0dari i3lbkIPfluwAYh8Y3syRPuHJlvPFyYvKhFIE8QQ= X-Google-Smtp-Source: APBJJlGKmNTgweK2kwJWs4/wFqNBmjg4Djz4jCj6ZqMtOK2vtD8XozEN8rFv3LAaQCX0JTqMTCJbsPKbO24byO+QNwg= X-Received: by 2002:a1f:43c4:0:b0:47e:91fc:d2b8 with SMTP id q187-20020a1f43c4000000b0047e91fcd2b8mr3487027vka.2.1688748404847; Fri, 07 Jul 2023 09:46:44 -0700 (PDT) MIME-Version: 1.0 References: <20230628104852.3391651-1-dhowells@redhat.com> <20230628104852.3391651-3-dhowells@redhat.com> In-Reply-To: From: Hyeonggon Yoo <42.hyeyoo@gmail.com> Date: Sat, 8 Jul 2023 01:46:33 +0900 Message-ID: Subject: Re: [BUG mm-unstable] BUG: KASAN: use-after-free in shrink_folio_list+0x9f4/0x1ae0 To: David Howells Cc: 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 , Dave Wysochanski , Dominique Martinet , Ilya Dryomov , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 093114000C X-Stat-Signature: mbfh7qotbzyqzi7rtctbh689dnmupb4b X-HE-Tag: 1688748405-76366 X-HE-Meta: U2FsdGVkX19Rr5REkllCcVds/scuHe4K9eW1ZJg3CEFHdU9t4PkfjGOmeiDTNTBmtqFQbRESmdFWLtziOdHuGwb2TvhNCHucfhURw634nyrFB70WLEpM5P40QE2bUq8XasIU4y+oj14SU7/Yw9sKCNrApxXrOeokZh3U1a214pXGcEmiRwgibB7TXx5KZCY5ABiKW1ZeYO7bNxw0VC1QTgjD6lJhap74popP6niBIJxE6D7LVMK4KH1TcGL8vIgFeNA6zvFUp2zOXUObBtPW3taqm9A4NXs8N18zpTQmf3kqVHyasBbgbt7jwo4E+vI5KtEYa0yoH/50YmfBWZ6CxCNnrpKUUPzXC8EJn00stkhq/m+fnNIIpOmrViqFsPYfrW4m/TcU47a/Apap8XISvq+t5Ub2DofDjUO8erLCPGjtdCBTFaUiybZu/McZB47AowbSbtjhm54ZSTXzLGn9sOG244x+303w6jCGve3LIRm3e57q5EaDSCot1lue0LrjFVweOPZWaiT1llBnFfZLpZh/e0c/UWCF/HRElO5Gg9m2NzH8wzLfkvvww4EzUBh/nxLTjQ9AIrse4xb3bybYAaQ4eUBjzEJR9PIZ5Ch4a58v6xiHx0bTLHRG9hkKRLpQPuMwhvAJX3DJrYvcCj8Wk6iX4H17vn1iwK/eHMS8rKi/ojI4/zlaqNf3jOGsXlCyr17D5/DUnomeuTLapK4ZkHBnpTnb4x6Z7Ow/+B3RrvDBBK3ExvkWjmYezHEm2KdZ1k4sT8JLMz+Nfo/YOy7blsHSIofc4U3wIwj02Y8TsV8UjQa54p5NpL2hmk7zZXKmmuVIhPtEl6SSN93SHC+F4SHd8AzV+ziJZP/jFKN6hj1pgqtV4PgNHDjUSrX2Xp6TresuKfSXBxpudG6XLx6QOdLPLIJfm0yEPGE/ytyEdPR4Dxq5ZLFVBZiI/ipo/YbrCvF8NOUJkITbaKSss6d ZLzTZus0 68fMNAg0ilzV92VqzKBmLQQ2ajo6GVFHl6L1aTuprx4rnbR+cW2tAwP/WsUHTsOAr+gySPO9tPJsIq64fgPme+vzUIzgn+9m4lOeyzErcsQTmGcY6WVdxgN2oJLoLmiJzxgVA9iNvgXN83Nw+QpiyFfYVcdMBOXKuzkltkWVzcGMqtXpfOUXibXGnJw1+zOFeKecAjFO9HlTtiUej9w9Z3up2rmksQluYp6q0Q2/xlbS37z+EvAotxdvA5aBIgulpF5p5itvU+ayLZ7H6YKIOL4qMstjXzDPyQduvsVddUpyOizY9qp6HjHf7jEhmEJ2zF961S/D/2q3foYm7OQddOmrTzVXA+w/D0WphZfXBwLUX/0XbKPa6M4Dh9PfNd9ue9YpWacexcrR75XSdzLPVPhpETdR+GOyXkjn8GR/WxU0zllmUCCaHLF7VaKhumcVU716fGvesDmw8OMVG1TOAeCJ5mK4Egyq6xsLBBzH9hSg8LSjAQc0WL1uA88iAyItU9RWgTNtXPi+C+6+9EntPZPKwEGERMIzb26uglR8/WG0y4DfrZHEcD9Epk79tVMPbkm+/SjhTdIyliV7UFKrAsLvzxdhnA/bRV2/f+N/sncUC2j1ydYlXHSx4jtagqiK81QD8XxT13CS26MiT2VrpJUipgFxfzBSi64+ogrk5aG6jEBIthg7SEcO//yG0EpljFBhlShbIjdR5UuQpnignzgUJFwyeSMX2fPRZdgA3nz9Huj/zX7s+YUztfqsXGAydgf38E3ZyhL74DmrL38Axhq4otrzCjFgvrTCPM/35OWMyGn5paytWihzzbkp5Rb6ur8FSUyu/XS5r8Vf+xSA/M81eSypIaag61uVhBRIMaQn5WmAcLkEtS6w2foZ7nLJWxr4Mr74lK2OXb49+yAQYj1hLBqK2PvpCxLAgxTKp6no8rhQ= 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, 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 u= ntil > > 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 don= e > > 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->flags)= ; > > > > where the NO_DATA_TO_READ flag causes cachefiles_prepare_read() to indi= cate > > that netfslib should download from the server or clear the page instead= . > > > > The fscache_note_page_release() function is intended to be called from > > ->releasepage() - but that only gets called if PG_private or PG_private= _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_space > > flag, AS_RELEASE_ALWAYS, that causes filemap_release_folio() to always = call > > ->release_folio() if it's set, even if PG_private or PG_private_2 aren'= t > > set. > > > > Note that this would require folio_test_private() and page_has_private(= ) to > > become more complicated. To avoid that, in the places[*] where these a= re > > 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 t= han > > just a call to the releaser. I've added a function, folio_needs_releas= e() > > 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_fina= l() > > is called. > > > > Additionally, the FSCACHE_COOKIE_NO_DATA_TO_READ flag needs to be clear= ed > > and the optimisation cancelled if a cachefiles object already contains = data > > when we open it. > > > > Fixes: 1f67e6d0b188 ("fscache: Provide a function to note the release o= f 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_rm= ap()"). > > 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 set_= 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(-)