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 63FF7C3600C for ; Thu, 3 Apr 2025 16:12:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2ADE5280005; Thu, 3 Apr 2025 12:12:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2385B280001; Thu, 3 Apr 2025 12:12:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0FE05280005; Thu, 3 Apr 2025 12:12:30 -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 E4A38280001 for ; Thu, 3 Apr 2025 12:12:29 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6BAFB1CB8B3 for ; Thu, 3 Apr 2025 16:12:30 +0000 (UTC) X-FDA: 83293225260.20.1F6CF86 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by imf21.hostedemail.com (Postfix) with ESMTP id A3E411C0008 for ; Thu, 3 Apr 2025 16:12:28 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (imf21.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743696748; a=rsa-sha256; cv=none; b=GKJSouF7Ur0skO/q2ndS3KCeh9HwUXJsaEykfeMDqx4bm92RPv1dctTBmsLr67Vdh3DPok gn7NdEJ8h6srx1WwESzxou+ZoHxg0iH/IzfSQrjYsuwPdqFFMAhS5ctjsVIHPdF63s9YsH LPTUJg2dojhTNgI2HvgakHm6nMpGUCc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=mit.edu; spf=pass (imf21.hostedemail.com: domain of tytso@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=tytso@mit.edu ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743696748; 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; bh=XTxTVdsJTMoOVLQd4MdCZRTR4eyckFEPgGfQNwDD1Pw=; b=4bnOZrttmxVZ6xESpVDP9X3rplQ8VcF2i3weXzp0qgpswOTu7n+spvlAqjIhC25VWZXSet d/pBjz37VSsDwp+jh62ALapXE97LY3fHCFGjaXJrGedKkFICdmC+IXOJCYTtmhYLkVse72 oy3KTaohb+Lon1tnt1KhTEqywq2k2bs= Received: from trampoline.thunk.org (pool-173-48-119-246.bstnma.fios.verizon.net [173.48.119.246]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 533GBsv8001822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 3 Apr 2025 12:11:54 -0400 Received: by trampoline.thunk.org (Postfix, from userid 15806) id B7F192E0019; Thu, 03 Apr 2025 12:11:53 -0400 (EDT) Date: Thu, 3 Apr 2025 12:11:53 -0400 From: "Theodore Ts'o" To: Jan Kara Cc: Luis Chamberlain , Matthew Wilcox , brauner@kernel.org, adilger.kernel@dilger.ca, linux-ext4@vger.kernel.org, riel@surriel.com, hannes@cmpxchg.org, oliver.sang@intel.com, david@redhat.com, axboe@kernel.dk, hare@suse.de, david@fromorbit.com, djwong@kernel.org, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, linux-mm@kvack.org, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com Subject: Re: [PATCH 2/3] fs/buffer: avoid races with folio migrations on __find_get_block_slow() Message-ID: <20250403161153.GA3051250@mit.edu> References: <20250330064732.3781046-1-mcgrof@kernel.org> <20250330064732.3781046-3-mcgrof@kernel.org> <20250401214951.kikcrmu5k3q6qmcr@offworld> <2jrcw4mtwcophanqmi2y74ffgf247m6ap44u3gedpylsjl3bz6@yueuwkmcwm66> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2jrcw4mtwcophanqmi2y74ffgf247m6ap44u3gedpylsjl3bz6@yueuwkmcwm66> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: A3E411C0008 X-Stat-Signature: hbb7xoggdq9w4wqp1zr946rg5gj8wrza X-Rspam-User: X-HE-Tag: 1743696748-124280 X-HE-Meta: U2FsdGVkX18DOqphk4A16qn49xPsx4eZKeotuLnT9hFr0EtaLfi5oUZUkXFEcxD6k41Ug422123FEmUmNJh5G7RwOPK+Vh9GlZ9CeitUt8L8BIeCNY3kV9HnBy3PWPOq2AIdvxT3pE03mvUa++W7CidKuM81mZzrWo9EAMyy9TrRpb44nHJsuccopYgDIurm7xy0jzUZpeucA5i88ZpD5Xd9jMwZHZUptzWe8FYffYGGM+yR8n26VKh3QY0+70RPVtTttZX9AJOOCMh+o+G6NOCzepi+PNATxwxgJn7qINjRc8l9mYvJFyFKSiGatajLQK5oG8cOf33nEwqFeuaNx4T2R0Ze9l19lOTEGhjI2EKCNOuTAQOkpw9x92z/js5Lax2bAvflGSuJ2mRJKif0svhAZp78lkpk0WLhuf8b6uqGK7l2GltXb660D6v3SHG48gDIDvSIbHQYdwp4IstxeMPWLRRtPbmHYHwq4lO9mvCx8k96Rbv1hxZuw0kl8whafWbA7UczsZ39G+VFVtntivhPHqFOk6SFnTNtMFp/NYaOMXVt8vZyNCzea7MG8mSc7fczDUXBm0UC23/OO0NCPVMuSdVPtfHIISdq9/gtU7pFyp+HrQOMWZQ0wlMIBBmJLeXMfrtKM5pplx8WYRBxuGsfyX6zJmcyaRaHUqPRDk0VFCuttLVY2oq1nLpTB0zmTI48xk9d+WNIoTZ7nyTMEQBN++Y+wTXX4y7i6ofsXdnQdb0dqf6wz5ytyKZuOM6tvm3eDT9s05OPihpLo0mMHzvxLCc7ibO2qbBjLCD6LL+tygtaTcgWHXGYPqL20tFqKiAgbAoXMfYY+ywyMYgxv+pmOfoBz6YCgB30ntBm4PYBxzFXzQ1NjSZhpWQilkVh0TYMkzEaZp7xWFDULInOAf0KoVTHcrCNs0zhzHjVnw2zOg0Gidm4UTbSVDUzjF033yefjEQp3E2LoWKv5C1 vX4rgAEW ItptPiq0T/CLvXjB3M3l3Nh2xYxB9cPevYUR+51ZrjytIM8a/76o1s7vWqzn0eUwHDD1Pgydl7tYwWtW2xuL07kKsHIZmukRm2FIyi1cLsrTdoUJcbkodMM34d8fo3plS0toRf+7iYah8B6tQnRtRiP6r0E5d1C81ZUcaiBrRMYDJXWL9QQlRahPBrHmhxDPIKv3GpLoUfql4fG1El5iOfUSRKSXO8FhfmsqtjWDp6HkUjcQ= 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, Apr 03, 2025 at 03:43:12PM +0200, Jan Kara wrote: > fs/ext4/ialloc.c:recently_deleted() - this one is the most problematic > place. It must bail rather than sleeping (called under a spinlock) but > it depends on the fact that if bh is not returned, then the data has been > written out and evicted from memory. Luckily, the usage of > recently_deleted() is mostly an optimization to reduce damage in case > of crash so rare false failure should be OK. Ted, what is your opinion? Yes, if we can just assume that inode has not been recently deleted in the rare case where a miogration is taking place, that should be fine. So in practice, recently_deleted() could just call some variant of find_get_block() (with some flag ) which returns NULL if we need to sleep (e.g., if it is not in the buffer cache so a read would need to take place, or we need to wait for the page migration to complete), that should work fine. Thanks, - Ted