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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z5m6kqmdUcLVNa9m@infradead.org>
Date: Tue, 28 Jan 2025 21:20:18 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Christoph Hellwig <hch@...radead.org>, Chi Zhiling <chizhiling@....com>,
	Brian Foster <bfoster@...hat.com>,
	"Darrick J. Wong" <djwong@...nel.org>,
	Amir Goldstein <amir73il@...il.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 Wed, Jan 29, 2025 at 11:59:53AM +1100, Dave Chinner wrote:
> Sure, but we don't think we need full file offset-scope IO exclusion
> to solve that problem.  We can still safely do concurrent writes
> within EOF to occur whilst another buffered append write is doing
> file extension work.

Sure.  The previous mail just sounded like you'd want to do away
with exclusion for assigning the offset.

> IOWs, where we really need to get to is a model that allows
> concurrent buffered IO at all times, except for the case where IO
> operations that change the inode size need to serialise against
> other similar operations (e.g. other EOF extending IOs, truncate,
> etc).
> 
> Hence I think we can largely ignore O_APPEND for the
> purposes of prototyping shared buffered IO and getting rid of the
> IOLOCK from the XFS IO path. I may end up re-using the i_rwsem as
> a "EOF modification" serialisation mechanism for O_APPEND and
> extending writes in general, but I don't think we need a general
> write IO exclusion mechanism for this...

That might be a chance to also fix O_DIRECT while we're at it..