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 6C7D8E77188 for ; Mon, 30 Dec 2024 17:30:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E48EA6B007B; Mon, 30 Dec 2024 12:30:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DF7976B0083; Mon, 30 Dec 2024 12:30:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CE6B36B0085; Mon, 30 Dec 2024 12:30:58 -0500 (EST) 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 AB1176B007B for ; Mon, 30 Dec 2024 12:30:58 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 576E81A0850 for ; Mon, 30 Dec 2024 17:30:58 +0000 (UTC) X-FDA: 82952313612.08.2630E41 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf11.hostedemail.com (Postfix) with ESMTP id 8570140019 for ; Mon, 30 Dec 2024 17:30:13 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h4ORg4K1; spf=pass (imf11.hostedemail.com: domain of mcgrof@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735579808; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3LGzDkH2/YYq2bWC61UHh4EoTTAvbab617lQYHOml9M=; b=FUl7DshJDEwLZwLSsSFitoXBsjO4sk0YDc3oMtfyMZb2xTiXwDcbX7Hi/v63gtBTQY2wTU ivuQ1mwu6xfS1hJDwv0Vobr3tPIXbUrz5ev/wUWP8be6a8KuZ6TAAY8tOU3dQ9berNJUhD p8V6DrrtZ2zKN4ymBuJzo3amoNMI//o= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=h4ORg4K1; spf=pass (imf11.hostedemail.com: domain of mcgrof@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735579808; a=rsa-sha256; cv=none; b=qxTA1gg6Dd+2Ku9AZzSPPF77NBpGhlFDVqxJTGWkQuRrfpS2W0uYjblqy4hJQbPLtKXOAA RLoAqfIbwlMnddpdOGLZnqrkaRwj7WGxfD8AheNaXDSefnQvoK2kOUIgQ4FmDNmmz1gOYm MobdckNdxQ3xPWV6gjRYuv+Hg2CR1yQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 348FFA40E34; Mon, 30 Dec 2024 17:29:06 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC3E6C4CED0; Mon, 30 Dec 2024 17:30:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1735579855; bh=VhQbO01j9UWomptl+H9hBM8wYgb2QsoNj3GCT9fVe84=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=h4ORg4K1o/s1bMTAWZD9fG2h5gt1fBDLQngLj0LpY0b3NXOo+PVQZ9NI0SOpBU/3+ EWOamxppI80anrRz1cb3rQHox5+Vx1pUk4nDze4q4ZSXgDXRYVNjJWU5pElh3jomU4 mdSmQ/GuIXyMSL/obAjt8sUBPmb1T/lemiIpnbWBajsnkJzp59DlMeekkUYuxbUDyY ASGj4l+P7ZK3bE55IRiUL3oemNUWEo6GR24xwA1VUvJTw700WiGODLYq7JoJFehmWa xmAFvC0nTkkbv0XiqSACw/V13p7imRewvd1WTPgLxCtv/+obfBVf4EFB8YZgKdNhTI liNXuDw6N5fbA== Date: Mon, 30 Dec 2024 09:30:53 -0800 From: Luis Chamberlain To: Matthew Wilcox Cc: hare@suse.de, dave@stgolabs.net, david@fromorbit.com, djwong@kernel.org, kbusch@kernel.org, john.g.garry@oracle.com, hch@lst.de, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com, kernel@pankajraghav.com Subject: Re: [PATCH 0/5] fs/buffer: strack reduction on async read Message-ID: References: <20241218022626.3668119-1-mcgrof@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8570140019 X-Rspam-User: X-Stat-Signature: cdik7493ubady4rrresd3r1xkfxzy8x5 X-HE-Tag: 1735579813-64762 X-HE-Meta: U2FsdGVkX19kkXeQfmuvHq+z0kGbdzUE1twf4892slLC7DNDI/WAwknBbJl+P34zr84e/pAh/8gCtr9wxUXiuBLfYQgmm+6n0YeMsHcXuXInVpARLn3m2Xc4YmTSrhR+/jZOePoCtPQOYCeE8m/m3v4X15FHDehGtjELm9I+rC9Lm6L7TyIUu88cbieB0K94vR8LfZAFYVbzfqq+EpCgUEHHCH6OjdOC6cOuxGv2Ajr+TOXOMwNBTrG5FIzt2K5OwVQ2124YIcIM0GAtSjmB/sBZOixUiw6JJjbDivYsbE0F3EBsnO7FilIMitNriT2xmV0O6U820I9pnkFOxclioVXGLerWNc92dsN34thzPfH+yyC9PX7h81dtE44h9u4AkdRijiecImaTbuXpLryh6GxrfEAzT/xU88me2xSdXT050dfGV4gyQGBAaJI7U2S5JmNbq+XNfpa8VWTCru/v7lYfCXrecqcThB6QtHvji1BmBNVrkiPypd9I0KTKGSmOkC76iV29FKSsy3nKh+gAXS4jXsEHtSimzPxCsfxgAD4NvBrYiUBHI3xdg/AMmwt7mG2RMGmLOqlK2l6h39FCZ3YJBH0mIDd5VV9kzyxRDVS9+o2rCYXNWb2MWxWhN0YmryuZa3Yh83qEn7VFoHl6GbPKd34M3oD6pE83F6/un85KlbPTEvzkwFq+mUlA7aPHW0a4MRgLJV8k2tKjX5bS7/vWCsEJ6/XXkQKfc/JeWZgS2730dJ2uEq63sY9qoqoSuWhTXvhyy50LMztauupFF/H/61RI1ovEAilwD7aT0O5PKkOj3dwsZeFFY+pqAAJsd4rCXGAshJ7kjmRcUb8buLdNVpV4BUt8z33HyjIagdUT9D6rPsr8PjmnnBvJkEix3MGzf6I6LLQasDPrFDLwSYXZQ70Bu9Uz/DEAMCaxond1113I61AtuWIvLO2ACfb1bm98EoI3+jiMaRBBFh5 q38nD8i9 yhql1Hovn8kha3qrGl0Eo27YHDrz78gKCCcITBm7SCnJOvpCaXzQpP2pW2XAjMpxrAMJnG0863Kw6n+aIC16Z7vd3dn34Z5SHwuRHVPgcch22Lp8o5j2lHxTsCZ3/XGl7Gkhjyx6oHCUMniZ6z2GEhuRzzEk3mBq8U4zGT4nbxudIoolMJ/j44ykX5oCvDClGzQI7yt4vyaAtPKcwZrilDNI/KXuTThoLL7IWPUXj3fEy8sjJ2Rznn9zAq/Yk36zn2JYmWf8K+VdpPnA8BZSHYx9U0YoOCX/QnN0O 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: List-Subscribe: List-Unsubscribe: On Thu, Dec 19, 2024 at 03:51:34AM +0000, Matthew Wilcox wrote: > So folio->mapping is NULL. > > Ah, I see the problem. end_buffer_async_read() uses the buffer_async_read > test to decide if all buffers on the page are uptodate or not. So both > having no batch (ie this patch) and having a batch which is smaller than > the number of buffers in the folio can lead to folio_end_read() being > called prematurely (ie we'll unlock the folio before finishing reading > every buffer in the folio). > > Once the folio is unlocked, it can be truncated. That's a second-order > problem, but it's the one your test happened to hit. > > This should fix the problem; we always have at least one BH held in > the submission path with the async_read flag set, so > end_buffer_async_read() will not end it prematurely. Oh neat, yes. > By the way, do you have CONFIG_VM_DEBUG enabled in your testing? You mean DEBUG_VM ? Yes: grep DEBUG_VM .config CONFIG_ARCH_HAS_DEBUG_VM_PGTABLE=y CONFIG_DEBUG_VM_IRQSOFF=y CONFIG_DEBUG_VM=y # CONFIG_DEBUG_VM_MAPLE_TREE is not set # CONFIG_DEBUG_VM_RB is not set CONFIG_DEBUG_VM_PGFLAGS=y # CONFIG_DEBUG_VM_PGTABLE is not set > VM_BUG_ON_FOLIO(!folio_test_locked(folio), folio); > in folio_end_read() should have tripped before hitting the race with > truncate. Odd that it did not, I had run into that folio_test_locked() splat but in my attempts to simplify this without your trick to only run into the similar truncate race, your resolution to this is nice. > diff --git a/fs/buffer.c b/fs/buffer.c This is a nice resolution and simplification, thanks, I've tested it and passes without regressions on ext4. I'll take this into this series as an alternative. Luis