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 0BA53C61CE8 for ; Thu, 12 Jun 2025 04:06:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9865C6B007B; Thu, 12 Jun 2025 00:06:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 930516B0088; Thu, 12 Jun 2025 00:06:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 849026B0089; Thu, 12 Jun 2025 00:06:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 65D9C6B007B for ; Thu, 12 Jun 2025 00:06:45 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 945CA14043F for ; Thu, 12 Jun 2025 04:06:43 +0000 (UTC) X-FDA: 83545412286.14.72A2064 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf22.hostedemail.com (Postfix) with ESMTP id E8EC1C0011 for ; Thu, 12 Jun 2025 04:06:41 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="J/fbMnh6"; spf=pass (imf22.hostedemail.com: domain of djwong@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=djwong@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=1749701202; 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=DhljD83j0Y3Kd7abd2ObhYBsjPf6lzYk+K16KWTyqCw=; b=ZVeWXOPWL764lJRW3VA6QE7AfWFpr6BBww7KmaX/pfTPYVmCiZKSQxQ6YRYM8pbE6dbxBe F/crZdpqnVOUZJI/HrGgfX3OVduRQ7GfM8n26tSqEF4N1wzSswIFK6EuYyLYpQdnvlyukD z2SJsCyzd5LybctILjsF7IEPVK9kO9M= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="J/fbMnh6"; spf=pass (imf22.hostedemail.com: domain of djwong@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749701202; a=rsa-sha256; cv=none; b=MAIH9xCHKRG5DC9N8+BQUHjoiSpt0Fp15wTeegRrnLDNMRSmCHkRtwn0shyYzEstwttumX gl/3W2wW0gMCp72ET3XxMui5d5zA95TZfQtLWjWg6VPk13hIPpuow5bA9D0cAPVwcc7A2+ x9xxhap+7hsMWYkX3eVHrNj3Q7WR1fo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 0283260EDF; Thu, 12 Jun 2025 04:06:41 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A1A7C4CEEA; Thu, 12 Jun 2025 04:06:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749701200; bh=Q4ZfThogLrjrzXMAxDJlRiD7rOypQqZu6v0KUZrg3KY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J/fbMnh6A/cjTgo7lUITahboGp1sZvt+yqQ9+dzfJ1x2SVGCkshiUIUJhObb9W2HC iIwbKpuYLlrFtKoLBTyc0SYLoMmmafoJO3CtnT3oLaa5WBmnoJjz8ljuNPlsJ8tH22 Xb9gAO3UPl938q8TSlHmgV7h/STg+DViIZ0EDeCmE/obMMnxC7wej3kZZ29N8kJU5K JhhkuOoxr2VLkHuTyb3gdjniPi5JGAW893QI0S7+tHTg0dz4W9udr69W3Hv+/B4J0m HknQd6s7PeCg1lrlpK8ruUVjVFVdzOJe2xYiZdIOSrUIxJLfMtCQe3tVxsIMILghNV hNH/9z2L7VF/Q== Date: Wed, 11 Jun 2025 21:06:39 -0700 From: "Darrick J. Wong" To: Christoph Hellwig Cc: Brian Foster , linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 3/7] iomap: optional zero range dirty folio processing Message-ID: <20250612040639.GO6156@frogsfrogsfrogs> References: <20250605173357.579720-1-bfoster@redhat.com> <20250605173357.579720-4-bfoster@redhat.com> <20250609160420.GC6156@frogsfrogsfrogs> <20250610145552.GM6156@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E8EC1C0011 X-Rspamd-Server: rspam07 X-Stat-Signature: 3u7o9jqqu4s5u8ujrxheros1547e5xzu X-Rspam-User: X-HE-Tag: 1749701201-696408 X-HE-Meta: U2FsdGVkX1/cI7K2HGyn+I0NFbIBh+gMVevv3i1bRBcIsvjCDsXW752BThhRvSlJklF9O5Qvr5gnv1R0bxseuRtaUmA6NAf5W5umlND/q0/hQJJQuFu6q1luKeKVCxc8E1LSOehfMcabm/r3Dgb6KSs9azQ1uXlAp/d3tAHl1FFCO6+ojeeKYTCsf6RZTQlQPuO7d5vo7fmhiM8Bhk8vhVtUF/k3qSVt57Z7Wx574iUp6u4nmMAPYbmu7a7nsuhvb1P1H9z+PbuF54ng1xqPCEhqfSS7Q1Uia49HW61lhP/yzX9WnnO/yozNUTtWdLLPgkK7HxCw/GLkETWqArqqvQSHms9t2y7imBR1T2CinPJR6NaSsxoBiEG8Jhjw6j9pk2nceuZ1AZYRnm2+SJClEK4GeCD+6/Z2+hfc9jIdyFXwcvWYXWrf6wwM7IRdrR56ZUWR7D3NV7Tl917u2433OVwkZoOKiKH7tjL15Ojoe9LOn8R0UAZrFmTrsUm8grbAEeiwd/5BAoi8+DOUmorTIgr4ZPY34VmPo1u6VlYx13AyEl8/BCwGXpcIiFKwkbziB0Ez4WX05Wfo8YKpQcHKUSg216v8f711J4WRKrgNrq0Bun26zWW6e87aG9yjo12tJ36jZwG6nbJ3xt/452pCupwOqbrFRBZigPLYTY2zVkoe/djb1WziIc6ywtcs8Ggt1w5gcaerhTpirqXzoXvE7XGSufEdWoeiXBI0igOtqDwihWYxWsSzNCsNdEU6tOWJqqdifPVC4mssiiH3aFp6/tHOyaPrELH8Mun0tEpAp7sGrtXKQWQzmb+8yA72QB1IAqovRTvsbc35svw2yRo0RLlZYw2lWDT0O35whEiupkRDjaDjZm/AQcgoCfGg/uJ/nkZj4lcS2CO59ZoY9LeNRCvINI8qSkpT0/nS5W5Zo3LE7moTBi4efAhMHEmQGFFkg5VZ5F03VQYZa8oOk6P aFFkb2YY 8HDJPngwqwtOL0tiGdeZRlb4p4Rj2optHlpAd1g6Bo/kQa2Gc/Pr6Cf82j5vNwYI+Z1/bdTLQ102Sx7nJUIsc5C2SmON/Rhx+oVo1/0s9t4JwKmH7gPL3pZAEhzFKWWvKRw1MEmd0sqbq+urcQOfZluU5yXkFLlCs978QnVD70/cQxTKVUwfy36rN7m5iqtAqP1ojgZGJMq7WXKv2jyJGqH+kryc9kH3w3bBbuaRPsrne4cBGO6z6RxPMHt6/nJ2iEAxn9CtQtqw0Wn5lityBnwewtA== 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 Tue, Jun 10, 2025 at 08:55:10PM -0700, Christoph Hellwig wrote: > On Tue, Jun 10, 2025 at 07:55:52AM -0700, Darrick J. Wong wrote: > > Hrmm. On closer examination, at least for xfs we've taken i_rwsem and > > the invalidate_lock so I think it should be the case that you don't need > > to revalidate. I think the same locks are held for iomap_unshare_range > > (mentioned elsewhere in this thread) though it doesn't apply to regular > > pagecache writes. > > We should document these assumptions, preferable using (lockdep) > asserts. Agreed. I think most of iomap/buffered-io.c wants the caller to hold i_rwsem in shared mode for reads; i_rwsem in exclusive mode for writes; and the invalidate lock for page faults. The big exception iirc is iomap_zero_range where you need to hold i_rwsem and the mapping invalidate lock, right? --D