linux-kernel - Re: [PATCH v7 5/8] xfs: Support FS_XFLAG

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: <20241004123520.GB19295@lst.de>
Date: Fri, 4 Oct 2024 14:35:20 +0200
From: Christoph Hellwig <hch@....de>
To: John Garry <john.g.garry@...cle.com>
Cc: axboe@...nel.dk, brauner@...nel.org, djwong@...nel.org,
	viro@...iv.linux.org.uk, jack@...e.cz, dchinner@...hat.com,
	hch@....de, cem@...nel.org, linux-block@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-xfs@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, hare@...e.de,
	martin.petersen@...cle.com, catherine.hoang@...cle.com,
	mcgrof@...nel.org, ritesh.list@...il.com, ojaswin@...ux.ibm.com
Subject: Re: [PATCH v7 5/8] xfs: Support FS_XFLAG_ATOMICWRITES

On Fri, Oct 04, 2024 at 09:22:51AM +0000, John Garry wrote:
> Add initial support for new flag FS_XFLAG_ATOMICWRITES.
> 
> This flag is a file attribute that mirrors an ondisk inode flag.  Actual
> support for untorn file writes (for now) depends on both the iflag and the
> underlying storage devices, which we can only really check at statx and
> pwritev2() time.  This is the same story as FS_XFLAG_DAX, which signals to
> the fs that we should try to enable the fsdax IO path on the file (instead
> of the regular page cache), but applications have to query STAT_ATTR_DAX to
> find out if they really got that IO path.
> 
> Current kernel support for atomic writes is based on HW support (for atomic
> writes). Since for regular files XFS has no way to specify extent alignment
> or granularity, atomic write size is limited to the FS block size.

I'm still confused why this flag is needed for the current version
of this patch set.  We should always be able to support atomic writes
<= block size if support by the block device.