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] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z5hn_cRb_cLzHX4Z@infradead.org>
Date: Mon, 27 Jan 2025 21:15:41 -0800
From: Christoph Hellwig <hch@...radead.org>
To: Dave Chinner <david@...morbit.com>
Cc: Chi Zhiling <chizhiling@....com>, Christoph Hellwig <hch@...radead.org>,
	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 Tue, Jan 28, 2025 at 07:49:17AM +1100, Dave Chinner wrote:
> > As for why an exclusive lock is needed for append writes, it's because
> > we don't want the EOF to be modified during the append write.
> 
> We don't care if the EOF moves during the append write at the
> filesystem level. We set kiocb->ki_pos = i_size_read() from
> generic_write_checks() under shared locking, and if we then race
> with another extending append write there are two cases:
> 
> 	1. the other task has already extended i_size; or
> 	2. we have two IOs at the same offset (i.e. at i_size).
> 
> In either case, we don't need exclusive locking for the IO because
> the worst thing that happens is that two IOs hit the same file
> offset. IOWs, it has always been left up to the application
> serialise RWF_APPEND writes on XFS, not the filesystem.

I disagree.  O_APPEND (RWF_APPEND is just the Linux-specific
per-I/O version of that) is extensively used for things like
multi-thread loggers where you have multiple threads doing O_APPEND
writes to a single log file, and they expect to not lose data
that way.  The fact that we currently don't do that for O_DIRECT
is a bug, which is just papered over that barely anyone uses
O_DIRECT | O_APPEND as that's not a very natural use case for
most applications (in fact NFS got away with never allowing it
at all).  But extending racy O_APPEND to buffered writes would
break a lot of applications.