linux-kernel - Re: [PATCH] xfs: Remove i_rwsem lock in buffered read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z4dNyZi8YyP3Uc_C@infradead.org>
Date: Tue, 14 Jan 2025 21:55:21 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Brian Foster <bfoster@...hat.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>, Chi Zhiling <chizhiling@....com>,
	Amir Goldstein <amir73il@...il.com>,
	Dave Chinner <david@...morbit.com>, cem@...nel.org,
	linux-xfs@...r.kernel.org, linux-kernel@...r.kernel.org,
	Chi Zhiling <chizhiling@...inos.cn>,
	John Garry <john.g.garry@...cle.com>
Subject: Re: [PATCH] xfs: Remove i_rwsem lock in buffered read

On Mon, Jan 13, 2025 at 08:40:51AM -0500, Brian Foster wrote:
> Sorry if this is out of left field as I haven't followed the discussion
> closely, but I presumed one of the reasons Darrick and Christoph raised
> the idea of using the folio batch thing I'm playing around with on zero
> range for buffered writes would be to acquire and lock all targeted
> folios up front. If so, would that help with what you're trying to
> achieve here? (If not, nothing to see here, move along.. ;).

I mostly thought about acquiring, as locking doesn't really have much
batching effects.  That being said, no that you got the idea in my mind
here's my early morning brainfart on it:

Let's ignore DIRECT I/O for the first step.  In that case lookup /
allocation and locking all folios for write before copying data will
remove the need for i_rwsem in the read and write path.  In a way that
sounds perfect, and given that btrfs already does that (although in a
very convoluted way) we know it's possible.

But direct I/O throws a big monkey wrench here as already mentioned by
others.  Now one interesting thing some file systems have done is
to serialize buffered against direct I/O, either by waiting for one
to finish, or by simply forcing buffered I/O when direct I/O would
conflict.  It's easy to detect outstanding direct I/O using i_dio_count
so buffered I/O could wait for that, and downgrading to buffered I/O
(potentially using the new uncached mode from Jens) if there are any
pages on the mapping after the invalidation also sounds pretty doable.
I don't really have time to turn this hand waving into, but maybe we 
should think if it's worthwhile or if I'm missing something important.