* Re: [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically
From: Christoph Hellwig @ 2025-04-23 8:23 UTC (permalink / raw)
To: John Garry
Cc: brauner, djwong, hch, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250422122739.2230121-12-john.g.garry@oracle.com>
On Tue, Apr 22, 2025 at 12:27:35PM +0000, John Garry wrote:
> +STATIC void
Didn't we phase out STATIC for new code?
> +xfs_calc_default_atomic_ioend_reservation(
> + struct xfs_mount *mp,
> + struct xfs_trans_resv *resp)
> +{
> + if (xfs_has_reflink(mp))
> + resp->tr_atomic_ioend = resp->tr_itruncate;
> + else
> + memset(&resp->tr_atomic_ioend, 0,
> + sizeof(resp->tr_atomic_ioend));
> +}
What is the point of zeroing out the structure for the non-reflink
case? Just as a poision for not using it when not supported as no
code should be doing that? Just thinking of this because it is a
potentially nasty landmine for the zoned atomic support.
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v8 12/15] xfs: add xfs_file_dio_write_atomic()
From: Christoph Hellwig @ 2025-04-23 8:25 UTC (permalink / raw)
To: John Garry
Cc: brauner, djwong, hch, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250422122739.2230121-13-john.g.garry@oracle.com>
On Tue, Apr 22, 2025 at 12:27:36PM +0000, John Garry wrote:
> Add xfs_file_dio_write_atomic() for dedicated handling of atomic writes.
>
> The function works based on two operating modes:
> - HW offload, i.e. REQ_ATOMIC-based
> - CoW based with out-of-places write and atomic extent remapping
>
> The preferred method is HW offload as it will be faster. If HW offload is
> not possible, then we fallback to the CoW-based method.
>
> HW offload would not be possible for the write length exceeding the HW
> offload limit, the write spanning multiple extents, unaligned disk blocks,
> etc.
>
> Apart from the write exceeding the HW offload limit, other conditions for
> HW offload can only be detected in the iomap handling for the write. As
> such, we use a fallback method to issue the write if we detect in the
> ->iomap_begin() handler that HW offload is not possible. Special code
> -ENOPROTOOPT is returned from ->iomap_begin() to inform that HW offload
> not possible.
This text could use a little rewrite starting with the fact that the
hardware offload now isn't required to start with and entirely
optional and then flow from the there to state when we can use it
instead of when we can't use it.
Otherwise looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v8 13/15] xfs: add xfs_compute_atomic_write_unit_max()
From: Christoph Hellwig @ 2025-04-23 8:26 UTC (permalink / raw)
To: John Garry
Cc: brauner, djwong, hch, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250422122739.2230121-14-john.g.garry@oracle.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v8 14/15] xfs: update atomic write limits
From: Christoph Hellwig @ 2025-04-23 8:27 UTC (permalink / raw)
To: John Garry
Cc: brauner, djwong, hch, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250422122739.2230121-15-john.g.garry@oracle.com>
Looks good:
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v8 12/15] xfs: add xfs_file_dio_write_atomic()
From: John Garry @ 2025-04-23 8:29 UTC (permalink / raw)
To: Christoph Hellwig
Cc: brauner, djwong, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423082525.GB29539@lst.de>
On 23/04/2025 09:25, Christoph Hellwig wrote:
> On Tue, Apr 22, 2025 at 12:27:36PM +0000, John Garry wrote:
>> Add xfs_file_dio_write_atomic() for dedicated handling of atomic writes.
>>
>> The function works based on two operating modes:
>> - HW offload, i.e. REQ_ATOMIC-based
>> - CoW based with out-of-places write and atomic extent remapping
>>
>> The preferred method is HW offload as it will be faster. If HW offload is
>> not possible, then we fallback to the CoW-based method.
>>
>> HW offload would not be possible for the write length exceeding the HW
>> offload limit, the write spanning multiple extents, unaligned disk blocks,
>> etc.
>>
>> Apart from the write exceeding the HW offload limit, other conditions for
>> HW offload can only be detected in the iomap handling for the write. As
>> such, we use a fallback method to issue the write if we detect in the
>> ->iomap_begin() handler that HW offload is not possible. Special code
>> -ENOPROTOOPT is returned from ->iomap_begin() to inform that HW offload
>> not possible.
>
> This text could use a little rewrite starting with the fact that the
> hardware offload now isn't required to start with and entirely
> optional and then flow from the there to state when we can use it
> instead of when we can't use it.
ok, sure
>
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
Thanks!
^ permalink raw reply
* Re: [PATCH v8 05/15] xfs: ignore HW which cannot atomic write a single block
From: John Garry @ 2025-04-23 8:28 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Darrick J. Wong, brauner, viro, jack, cem, linux-fsdevel,
dchinner, linux-xfs, linux-kernel, ojaswin, ritesh.list,
martin.petersen, linux-ext4, linux-block, catherine.hoang,
linux-api
In-Reply-To: <20250423081055.GA28307@lst.de>
On 23/04/2025 09:10, Christoph Hellwig wrote:
> On Wed, Apr 23, 2025 at 08:15:43AM +0100, John Garry wrote:
>> Ideally we could have not set them in the first place, but need to know the
>> blocksize when xfs_alloc_buftarg() is called, but it is not yet set for
>> mp/sb. Is there any neat way to know the blocksize when xfs_alloc_buftarg()
>> is called?
>
> The buftarg is needed to read the superblock, which is used to determine
> the block size, so no.
>
> But maybe we should just delay setting the atomic values until later so
> that it can be done in a single pass? E.g. into xfs_setsize_buftarg
> which then should probably be rename to something like
> xfs_buftarg_setup.
>
How about just do away with btp->bt_bdev_awu_{min, max} struct members,
and call bdev_atomic_write_unit_max(mp->m_ddev_targp->bt_bdev) [and same
for RT] to later to set the mp awu max values at mountfs time? I think
that would work..
^ permalink raw reply
* Re: [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time
From: Christoph Hellwig @ 2025-04-23 8:32 UTC (permalink / raw)
To: John Garry
Cc: brauner, djwong, hch, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250422122739.2230121-16-john.g.garry@oracle.com>
On Tue, Apr 22, 2025 at 12:27:39PM +0000, John Garry wrote:
> From: "Darrick J. Wong" <djwong@kernel.org>
>
> Introduce a mount option to allow sysadmins to specify the maximum size
> of an atomic write. If the filesystem can work with the supplied value,
> that becomes the new guaranteed maximum.
>
> The value mustn't be too big for the existing filesystem geometry (max
> write size, max AG/rtgroup size). We dynamically recompute the
> tr_atomic_write transaction reservation based on the given block size,
> check that the current log size isn't less than the new minimum log size
> constraints, and set a new maximum.
>
> The actual software atomic write max is still computed based off of
> tr_atomic_ioend the same way it has for the past few commits.
The cap is a good idea, but a mount option for something that has
strong effects for persistent application formats is a little suboptimal.
But adding a sb field and an incompat bit wouldn't be great either.
Maybe this another use case for a trusted xattr on the root inode like
the autofsck flag?
^ permalink raw reply
* Re: [PATCH v8 05/15] xfs: ignore HW which cannot atomic write a single block
From: Christoph Hellwig @ 2025-04-23 8:33 UTC (permalink / raw)
To: John Garry
Cc: Christoph Hellwig, Darrick J. Wong, brauner, viro, jack, cem,
linux-fsdevel, dchinner, linux-xfs, linux-kernel, ojaswin,
ritesh.list, martin.petersen, linux-ext4, linux-block,
catherine.hoang, linux-api
In-Reply-To: <f27ea8f7-700a-4fb1-b9cd-a0cba04c9e47@oracle.com>
On Wed, Apr 23, 2025 at 09:28:14AM +0100, John Garry wrote:
>> But maybe we should just delay setting the atomic values until later so
>> that it can be done in a single pass? E.g. into xfs_setsize_buftarg
>> which then should probably be rename to something like
>> xfs_buftarg_setup.
>>
>
> How about just do away with btp->bt_bdev_awu_{min, max} struct members, and
> call bdev_atomic_write_unit_max(mp->m_ddev_targp->bt_bdev) [and same for
> RT] to later to set the mp awu max values at mountfs time? I think that
> would work..
Sounds reasonable.
^ permalink raw reply
* Re: [PATCH v4 3/3] fs: introduce getfsxattrat and setfsxattrat syscalls
From: Jan Kara @ 2025-04-23 9:53 UTC (permalink / raw)
To: Christian Brauner
Cc: Andrey Albershteyn, Richard Henderson, Matt Turner, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Naveen N Rao, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
David S. Miller, Andreas Larsson, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Chris Zankel, Max Filippov, Alexander Viro,
Jan Kara, Mickaël Salaün, Günther Noack,
Arnd Bergmann, Pali Rohár, Paul Moore, James Morris,
Serge E. Hallyn, linux-alpha, linux-kernel, linux-arm-kernel,
linux-m68k, linux-mips, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, linux-fsdevel, linux-security-module,
linux-api, linux-arch, linux-xfs
In-Reply-To: <20250422-abbekommen-begierde-bcf48dd74a2e@brauner>
On Tue 22-04-25 16:59:02, Christian Brauner wrote:
> On Fri, Mar 21, 2025 at 08:48:42PM +0100, Andrey Albershteyn wrote:
> > From: Andrey Albershteyn <aalbersh@redhat.com>
> >
> > Introduce getfsxattrat and setfsxattrat syscalls to manipulate inode
> > extended attributes/flags. The syscalls take parent directory fd and
> > path to the child together with struct fsxattr.
> >
> > This is an alternative to FS_IOC_FSSETXATTR ioctl with a difference
> > that file don't need to be open as we can reference it with a path
> > instead of fd. By having this we can manipulated inode extended
> > attributes not only on regular files but also on special ones. This
> > is not possible with FS_IOC_FSSETXATTR ioctl as with special files
> > we can not call ioctl() directly on the filesystem inode using fd.
> >
> > This patch adds two new syscalls which allows userspace to get/set
> > extended inode attributes on special files by using parent directory
> > and a path - *at() like syscall.
> >
> > CC: linux-api@vger.kernel.org
> > CC: linux-fsdevel@vger.kernel.org
> > CC: linux-xfs@vger.kernel.org
> > Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
> > Acked-by: Arnd Bergmann <arnd@arndb.de>
...
> > + struct fsxattr __user *, ufsx, size_t, usize,
> > + unsigned int, at_flags)
> > +{
> > + struct fileattr fa = {};
> > + struct path filepath;
> > + int error;
> > + unsigned int lookup_flags = 0;
> > + struct filename *name;
> > + struct fsxattr fsx = {};
> > +
> > + BUILD_BUG_ON(sizeof(struct fsxattr) < FSXATTR_SIZE_VER0);
> > + BUILD_BUG_ON(sizeof(struct fsxattr) != FSXATTR_SIZE_LATEST);
> > +
> > + if ((at_flags & ~(AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH)) != 0)
> > + return -EINVAL;
> > +
> > + if (!(at_flags & AT_SYMLINK_NOFOLLOW))
> > + lookup_flags |= LOOKUP_FOLLOW;
> > +
> > + if (at_flags & AT_EMPTY_PATH)
> > + lookup_flags |= LOOKUP_EMPTY;
> > +
> > + if (usize > PAGE_SIZE)
> > + return -E2BIG;
> > +
> > + if (usize < FSXATTR_SIZE_VER0)
> > + return -EINVAL;
> > +
> > + name = getname_maybe_null(filename, at_flags);
> > + if (!name) {
>
> This is broken as it doesn't handle AT_FDCWD correctly. You need:
>
> name = getname_maybe_null(filename, at_flags);
> if (IS_ERR(name))
> return PTR_ERR(name);
>
> if (!name && dfd >= 0) {
> CLASS(fd, f)(dfd);
Ah, you're indeed right that if dfd == AT_FDCWD and filename == NULL, the
we should operate on cwd but we'd bail with error here. I've missed that
during my review. But as far as I've checked the same bug is there in
path_setxattrat() and path_getxattrat() so we should fix this there as
well?
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v7 11/14] xfs: add xfs_file_dio_write_atomic()
From: Darrick J. Wong @ 2025-04-23 14:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423081902.GD28307@lst.de>
On Wed, Apr 23, 2025 at 10:19:02AM +0200, Christoph Hellwig wrote:
> On Wed, Apr 23, 2025 at 07:42:51AM +0200, Christoph Hellwig wrote:
> > On Mon, Apr 21, 2025 at 09:42:41AM -0700, Darrick J. Wong wrote:
> > > Well it turns out that was a stupid question -- zoned=1 can't be enabled
> > > with reflink, which means there's no cow fallback so atomic writes just
> > > plain don't work:
> >
> > Exactly. It is still on my todo list to support it, but there are a
> > few higher priority items on it as well, in addition to constant
> > interruptions for patch reviews :)
>
> Actually, for zoned we don't need reflink support - as we always write
> out place only the stuffing of multiple remaps into a single transaction
> is needed. Still no need to force John to do this work, I can look into
> this (probably fairly trivial) work once we have good enough test cases
> in xfstests that I can trust them to verify I got things right.
<nod> I think we'll need a new fstest to set an error trap on a step
midway through a multi-extent ioend completion to make sure that's
actually working properly. And probably new write commands for fsx and
fsstress to exercise RWF_ATOMIC.
(Catherine: please send the accumulated atomic writes fstests)
--D
^ permalink raw reply
* Re: [PATCH v7 11/14] xfs: add xfs_file_dio_write_atomic()
From: Darrick J. Wong @ 2025-04-23 14:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423054251.GA23087@lst.de>
On Wed, Apr 23, 2025 at 07:42:51AM +0200, Christoph Hellwig wrote:
> On Mon, Apr 21, 2025 at 09:42:41AM -0700, Darrick J. Wong wrote:
> > Well it turns out that was a stupid question -- zoned=1 can't be enabled
> > with reflink, which means there's no cow fallback so atomic writes just
> > plain don't work:
>
> Exactly. It is still on my todo list to support it, but there are a
> few higher priority items on it as well, in addition to constant
> interruptions for patch reviews :)
Heheh I'll try to go dig through all the stuff you've sent to the list
yesterday, though I've got an hour of paperwork ahead of me that has to
get done asap. :/
--D
> > I /think/ all you'd have to do is create an xfs_zoned_end_atomic_io
> > function that does what xfs_zoned_end_io but with a single
> > tr_atomic_ioend transaction; figure out how to convey "this is an
> > atomic out of place write" to xfs_end_ioend so that it knows to call
> > xfs_zoned_end_atomic_io; and then update the xfs_get_atomic_write*
> > helpers.
>
> Roughly, yes.
>
>
^ permalink raw reply
* Re: [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically
From: Darrick J. Wong @ 2025-04-23 14:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423082307.GA29539@lst.de>
On Wed, Apr 23, 2025 at 10:23:07AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 22, 2025 at 12:27:35PM +0000, John Garry wrote:
> > +STATIC void
>
> Didn't we phase out STATIC for new code?
>
> > +xfs_calc_default_atomic_ioend_reservation(
> > + struct xfs_mount *mp,
> > + struct xfs_trans_resv *resp)
> > +{
> > + if (xfs_has_reflink(mp))
> > + resp->tr_atomic_ioend = resp->tr_itruncate;
> > + else
> > + memset(&resp->tr_atomic_ioend, 0,
> > + sizeof(resp->tr_atomic_ioend));
> > +}
>
> What is the point of zeroing out the structure for the non-reflink
> case? Just as a poision for not using it when not supported as no
> code should be doing that? Just thinking of this because it is a
> potentially nasty landmine for the zoned atomic support.
Yes. I thought about adding a really stupid helper:
static inline bool xfs_has_sw_atomic_write(struct xfs_mount *mp)
{
return xfs_has_reflink(mp);
}
But that seemed too stupid so I left it out. Maybe it wasn't so dumb,
since that would be where you'd enable ZNS support by changing that to:
return xfs_has_reflink(mp) || xfs_has_zoned(mp);
--D
> Otherwise looks good:
>
> Reviewed-by: Christoph Hellwig <hch@lst.de>
>
^ permalink raw reply
* Re: [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time
From: Darrick J. Wong @ 2025-04-23 15:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423083209.GA30432@lst.de>
On Wed, Apr 23, 2025 at 10:32:09AM +0200, Christoph Hellwig wrote:
> On Tue, Apr 22, 2025 at 12:27:39PM +0000, John Garry wrote:
> > From: "Darrick J. Wong" <djwong@kernel.org>
> >
> > Introduce a mount option to allow sysadmins to specify the maximum size
> > of an atomic write. If the filesystem can work with the supplied value,
> > that becomes the new guaranteed maximum.
> >
> > The value mustn't be too big for the existing filesystem geometry (max
> > write size, max AG/rtgroup size). We dynamically recompute the
> > tr_atomic_write transaction reservation based on the given block size,
> > check that the current log size isn't less than the new minimum log size
> > constraints, and set a new maximum.
> >
> > The actual software atomic write max is still computed based off of
> > tr_atomic_ioend the same way it has for the past few commits.
>
> The cap is a good idea, but a mount option for something that has
> strong effects for persistent application formats is a little suboptimal.
> But adding a sb field and an incompat bit wouldn't be great either.
>
> Maybe this another use case for a trusted xattr on the root inode like
> the autofsck flag?
That would be even better, since you could set it at mkfs time and it
would persist until the next xfs_property set call.
--D
^ permalink raw reply
* Re: [PATCH v8 05/15] xfs: ignore HW which cannot atomic write a single block
From: Darrick J. Wong @ 2025-04-23 15:12 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423083317.GB30432@lst.de>
On Wed, Apr 23, 2025 at 10:33:17AM +0200, Christoph Hellwig wrote:
> On Wed, Apr 23, 2025 at 09:28:14AM +0100, John Garry wrote:
> >> But maybe we should just delay setting the atomic values until later so
> >> that it can be done in a single pass? E.g. into xfs_setsize_buftarg
> >> which then should probably be rename to something like
> >> xfs_buftarg_setup.
> >>
> >
> > How about just do away with btp->bt_bdev_awu_{min, max} struct members, and
> > call bdev_atomic_write_unit_max(mp->m_ddev_targp->bt_bdev) [and same for
> > RT] to later to set the mp awu max values at mountfs time? I think that
> > would work..
>
> Sounds reasonable.
I disagree, leaving the hardware awu_min/max in the buftarg makes more
sense to me because the buftarg is our abstraction for a block device,
and these fields describe the atomic write units that we can use with
that block device.
IOWs, I don't like dumping even more into struct xfs_mount. xfs_group
has an awu_max for the software fallback, xfs_buftarg has an awu_min/max
for hardware, and even this V8 has yet a third pair of awu_min/max in
xfs_mount which I think is just the buftarg version but possibly
truncated. I find those last two pairs confusing.
--D
^ permalink raw reply
* Re: [PATCH v8 15/15] xfs: allow sysadmins to specify a maximum atomic write limit at mount time
From: Darrick J. Wong @ 2025-04-23 15:21 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423150110.GB25675@frogsfrogsfrogs>
On Wed, Apr 23, 2025 at 08:01:10AM -0700, Darrick J. Wong wrote:
> On Wed, Apr 23, 2025 at 10:32:09AM +0200, Christoph Hellwig wrote:
> > On Tue, Apr 22, 2025 at 12:27:39PM +0000, John Garry wrote:
> > > From: "Darrick J. Wong" <djwong@kernel.org>
> > >
> > > Introduce a mount option to allow sysadmins to specify the maximum size
> > > of an atomic write. If the filesystem can work with the supplied value,
> > > that becomes the new guaranteed maximum.
> > >
> > > The value mustn't be too big for the existing filesystem geometry (max
> > > write size, max AG/rtgroup size). We dynamically recompute the
> > > tr_atomic_write transaction reservation based on the given block size,
> > > check that the current log size isn't less than the new minimum log size
> > > constraints, and set a new maximum.
> > >
> > > The actual software atomic write max is still computed based off of
> > > tr_atomic_ioend the same way it has for the past few commits.
> >
> > The cap is a good idea, but a mount option for something that has
> > strong effects for persistent application formats is a little suboptimal.
> > But adding a sb field and an incompat bit wouldn't be great either.
> >
> > Maybe this another use case for a trusted xattr on the root inode like
> > the autofsck flag?
>
> That would be even better, since you could set it at mkfs time and it
> would persist until the next xfs_property set call.
[/me hands himself another coffee]
The only problem is, setting the property while the fs is mounted does
not change the actual fs capability until the next mount since
properties are regular (and not magic) xattrs.
--D
> --D
>
^ permalink raw reply
* Re: [PATCH v8 05/15] xfs: ignore HW which cannot atomic write a single block
From: Christoph Hellwig @ 2025-04-23 15:46 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, John Garry, brauner, viro, jack, cem,
linux-fsdevel, dchinner, linux-xfs, linux-kernel, ojaswin,
ritesh.list, martin.petersen, linux-ext4, linux-block,
catherine.hoang, linux-api
In-Reply-To: <20250423151224.GC25675@frogsfrogsfrogs>
On Wed, Apr 23, 2025 at 08:12:24AM -0700, Darrick J. Wong wrote:
> I disagree, leaving the hardware awu_min/max in the buftarg makes more
> sense to me because the buftarg is our abstraction for a block device,
> and these fields describe the atomic write units that we can use with
> that block device.
Yeah. If you want to keep it I'd suggest we go back to my earlier
suggestion.
^ permalink raw reply
* Re: [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically
From: Christoph Hellwig @ 2025-04-23 15:53 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Christoph Hellwig, John Garry, brauner, viro, jack, cem,
linux-fsdevel, dchinner, linux-xfs, linux-kernel, ojaswin,
ritesh.list, martin.petersen, linux-ext4, linux-block,
catherine.hoang, linux-api
In-Reply-To: <20250423145850.GA25675@frogsfrogsfrogs>
On Wed, Apr 23, 2025 at 07:58:50AM -0700, Darrick J. Wong wrote:
> > > +xfs_calc_default_atomic_ioend_reservation(
> > > + struct xfs_mount *mp,
> > > + struct xfs_trans_resv *resp)
> > > +{
> > > + if (xfs_has_reflink(mp))
> > > + resp->tr_atomic_ioend = resp->tr_itruncate;
> > > + else
> > > + memset(&resp->tr_atomic_ioend, 0,
> > > + sizeof(resp->tr_atomic_ioend));
> > > +}
> >
> > What is the point of zeroing out the structure for the non-reflink
> > case? Just as a poision for not using it when not supported as no
> > code should be doing that? Just thinking of this because it is a
> > potentially nasty landmine for the zoned atomic support.
>
> Yes. I thought about adding a really stupid helper:
Why don't we just always set up the xfs_trans_resv structure? We
do that for all kinds of other transactions not supported as well,
don't we?
> static inline bool xfs_has_sw_atomic_write(struct xfs_mount *mp)
> {
> return xfs_has_reflink(mp);
> }
>
> But that seemed too stupid so I left it out. Maybe it wasn't so dumb,
> since that would be where you'd enable ZNS support by changing that to:
>
> return xfs_has_reflink(mp) || xfs_has_zoned(mp);
But that helper might actually be useful in various places, so
independent of the above I'm in favor of it.
^ permalink raw reply
* Re: [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically
From: Darrick J. Wong @ 2025-04-23 15:58 UTC (permalink / raw)
To: Christoph Hellwig
Cc: John Garry, brauner, viro, jack, cem, linux-fsdevel, dchinner,
linux-xfs, linux-kernel, ojaswin, ritesh.list, martin.petersen,
linux-ext4, linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423155340.GA32225@lst.de>
On Wed, Apr 23, 2025 at 05:53:40PM +0200, Christoph Hellwig wrote:
> On Wed, Apr 23, 2025 at 07:58:50AM -0700, Darrick J. Wong wrote:
> > > > +xfs_calc_default_atomic_ioend_reservation(
> > > > + struct xfs_mount *mp,
> > > > + struct xfs_trans_resv *resp)
> > > > +{
> > > > + if (xfs_has_reflink(mp))
> > > > + resp->tr_atomic_ioend = resp->tr_itruncate;
> > > > + else
> > > > + memset(&resp->tr_atomic_ioend, 0,
> > > > + sizeof(resp->tr_atomic_ioend));
> > > > +}
> > >
> > > What is the point of zeroing out the structure for the non-reflink
> > > case? Just as a poision for not using it when not supported as no
> > > code should be doing that? Just thinking of this because it is a
> > > potentially nasty landmine for the zoned atomic support.
> >
> > Yes. I thought about adding a really stupid helper:
>
> Why don't we just always set up the xfs_trans_resv structure? We
> do that for all kinds of other transactions not supported as well,
> don't we?
Works for me. There's really no harm in it mirroring tr_itruncate since
it won't affect the log size calculation.
> > static inline bool xfs_has_sw_atomic_write(struct xfs_mount *mp)
> > {
> > return xfs_has_reflink(mp);
> > }
> >
> > But that seemed too stupid so I left it out. Maybe it wasn't so dumb,
> > since that would be where you'd enable ZNS support by changing that to:
> >
> > return xfs_has_reflink(mp) || xfs_has_zoned(mp);
>
> But that helper might actually be useful in various places, so
> independent of the above I'm in favor of it.
<nod> John, who should work on the next round, you or me?
--D
^ permalink raw reply
* Re: [PATCH v8 11/15] xfs: commit CoW-based atomic writes atomically
From: John Garry @ 2025-04-23 16:38 UTC (permalink / raw)
To: Darrick J. Wong, Christoph Hellwig
Cc: brauner, viro, jack, cem, linux-fsdevel, dchinner, linux-xfs,
linux-kernel, ojaswin, ritesh.list, martin.petersen, linux-ext4,
linux-block, catherine.hoang, linux-api
In-Reply-To: <20250423155851.GL25700@frogsfrogsfrogs>
On 23/04/2025 16:58, Darrick J. Wong wrote:
> <nod> John, who should work on the next round, you or me?
If you can just share your changes then I can re-post. I can fix up the
smaller things, like commit messages.
Thanks,
John
^ permalink raw reply
* Re: newlines in filenames; POSIX.1-2024
From: Theodore Ts'o @ 2025-04-24 0:05 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: linux-kernel, linux-api, linux-man
In-Reply-To: <3wpydsib5maytq4m4ve4b7wfbfkxwzd5m6u5woqr43qr6mickk@gw4ww6vvgyo5>
On Wed, Apr 23, 2025 at 09:31:42AM +0200, Alejandro Colomar wrote:
>
> <http://austingroupbugs.net/view.php?id=251>
Ugh. Reading through that bug, despite the fact that the original
proposal was *significantly* bared down, has greatly reduced my
respect for the Austin Group.
One of the people in that bug argued unironically that using pipes
should be deprecated. i.e., that somehow "find . ... -print0 | xargs
-0 ..." was a security problem.
<<Sigh>>
Other people pointed out that creating proscriptions that were not
implemented by many/most historical implementations would fragment the
standard and decrease the respect people would have towards the POSIX
specification. That was the "toilet paper" comment which you
referenced.
Well, they got that right.
> I think a mode for disallowing _any control characters_ (aka
> [:cntrl:], aka 0-31) would be a good choice.
As the Austin Group Bug pointed out, the problem is that the control
characters can be printable characters, depending on the code page
that you might be using. The example that was given was cp437.
The problem is that historically speaking, the kernel does *not* know
about what locale that is in use. We made an exception to handle case
folding, where we added Unicode tables into the kernel. Some would
say that was a major mistake, and it's certainly been a headache.
- Ted
^ permalink raw reply
* Re: newlines in filenames; POSIX.1-2024
From: Alejandro Colomar @ 2025-04-24 7:00 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-kernel, linux-api, linux-man
In-Reply-To: <20250424000534.GB765145@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
Hi Ted,
On Wed, Apr 23, 2025 at 07:05:34PM -0500, Theodore Ts'o wrote:
> On Wed, Apr 23, 2025 at 09:31:42AM +0200, Alejandro Colomar wrote:
> >
> > <http://austingroupbugs.net/view.php?id=251>
>
> Ugh. Reading through that bug, despite the fact that the original
> proposal was *significantly* bared down, has greatly reduced my
> respect for the Austin Group.
>
> One of the people in that bug argued unironically that using pipes
> should be deprecated. i.e., that somehow "find . ... -print0 | xargs
> -0 ..." was a security problem.
Huh! I hadn't read that part.
> <<Sigh>>
>
> Other people pointed out that creating proscriptions that were not
> implemented by many/most historical implementations would fragment the
> standard and decrease the respect people would have towards the POSIX
> specification. That was the "toilet paper" comment which you
> referenced.
>
> Well, they got that right.
>
> > I think a mode for disallowing _any control characters_ (aka
> > [:cntrl:], aka 0-31) would be a good choice.
>
> As the Austin Group Bug pointed out, the problem is that the control
> characters can be printable characters, depending on the code page
> that you might be using. The example that was given was cp437.
>
> The problem is that historically speaking, the kernel does *not* know
> about what locale that is in use. We made an exception to handle case
> folding, where we added Unicode tables into the kernel. Some would
> say that was a major mistake, and it's certainly been a headache.
Hmmmm, I'm not too worried about that code page for my own system, and
most people aren't either. I still believe it would be good to have the
option to forbid 0-31, and let those users who need access file systems
with such weird conventions continue using the default (that is, not
enabling the new mode). I think ASCII has won the character wars;
especially in POSIX systems.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/3] fs: introduce getfsxattrat and setfsxattrat syscalls
From: Christian Brauner @ 2025-04-24 9:06 UTC (permalink / raw)
To: Jan Kara
Cc: Andrey Albershteyn, Richard Henderson, Matt Turner, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Naveen N Rao, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
David S. Miller, Andreas Larsson, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Chris Zankel, Max Filippov, Alexander Viro,
Mickaël Salaün, Günther Noack, Arnd Bergmann,
Pali Rohár, Paul Moore, James Morris, Serge E. Hallyn,
linux-alpha, linux-kernel, linux-arm-kernel, linux-m68k,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, linux-fsdevel, linux-security-module, linux-api,
linux-arch, linux-xfs
In-Reply-To: <rbzlwvecvrp4xawwp5nywdq6wp5hgjhrtrabpszv74xmfqbj4f@x7v6eqfc5gcd>
On Wed, Apr 23, 2025 at 11:53:25AM +0200, Jan Kara wrote:
> On Tue 22-04-25 16:59:02, Christian Brauner wrote:
> > On Fri, Mar 21, 2025 at 08:48:42PM +0100, Andrey Albershteyn wrote:
> > > From: Andrey Albershteyn <aalbersh@redhat.com>
> > >
> > > Introduce getfsxattrat and setfsxattrat syscalls to manipulate inode
> > > extended attributes/flags. The syscalls take parent directory fd and
> > > path to the child together with struct fsxattr.
> > >
> > > This is an alternative to FS_IOC_FSSETXATTR ioctl with a difference
> > > that file don't need to be open as we can reference it with a path
> > > instead of fd. By having this we can manipulated inode extended
> > > attributes not only on regular files but also on special ones. This
> > > is not possible with FS_IOC_FSSETXATTR ioctl as with special files
> > > we can not call ioctl() directly on the filesystem inode using fd.
> > >
> > > This patch adds two new syscalls which allows userspace to get/set
> > > extended inode attributes on special files by using parent directory
> > > and a path - *at() like syscall.
> > >
> > > CC: linux-api@vger.kernel.org
> > > CC: linux-fsdevel@vger.kernel.org
> > > CC: linux-xfs@vger.kernel.org
> > > Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> ...
> > > + struct fsxattr __user *, ufsx, size_t, usize,
> > > + unsigned int, at_flags)
> > > +{
> > > + struct fileattr fa = {};
> > > + struct path filepath;
> > > + int error;
> > > + unsigned int lookup_flags = 0;
> > > + struct filename *name;
> > > + struct fsxattr fsx = {};
> > > +
> > > + BUILD_BUG_ON(sizeof(struct fsxattr) < FSXATTR_SIZE_VER0);
> > > + BUILD_BUG_ON(sizeof(struct fsxattr) != FSXATTR_SIZE_LATEST);
> > > +
> > > + if ((at_flags & ~(AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH)) != 0)
> > > + return -EINVAL;
> > > +
> > > + if (!(at_flags & AT_SYMLINK_NOFOLLOW))
> > > + lookup_flags |= LOOKUP_FOLLOW;
> > > +
> > > + if (at_flags & AT_EMPTY_PATH)
> > > + lookup_flags |= LOOKUP_EMPTY;
> > > +
> > > + if (usize > PAGE_SIZE)
> > > + return -E2BIG;
> > > +
> > > + if (usize < FSXATTR_SIZE_VER0)
> > > + return -EINVAL;
> > > +
> > > + name = getname_maybe_null(filename, at_flags);
> > > + if (!name) {
> >
> > This is broken as it doesn't handle AT_FDCWD correctly. You need:
> >
> > name = getname_maybe_null(filename, at_flags);
> > if (IS_ERR(name))
> > return PTR_ERR(name);
> >
> > if (!name && dfd >= 0) {
> > CLASS(fd, f)(dfd);
>
> Ah, you're indeed right that if dfd == AT_FDCWD and filename == NULL, the
> we should operate on cwd but we'd bail with error here. I've missed that
> during my review. But as far as I've checked the same bug is there in
> path_setxattrat() and path_getxattrat() so we should fix this there as
> well?
Yes, please!
^ permalink raw reply
* Re: [PATCH v4 3/3] fs: introduce getfsxattrat and setfsxattrat syscalls
From: Andrey Albershteyn @ 2025-04-24 17:45 UTC (permalink / raw)
To: Christian Brauner
Cc: Jan Kara, Richard Henderson, Matt Turner, Russell King,
Catalin Marinas, Will Deacon, Geert Uytterhoeven, Michal Simek,
Thomas Bogendoerfer, James E.J. Bottomley, Helge Deller,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy, Naveen N Rao, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Yoshinori Sato, Rich Felker, John Paul Adrian Glaubitz,
David S. Miller, Andreas Larsson, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Chris Zankel, Max Filippov, Alexander Viro,
Mickaël Salaün, Günther Noack, Arnd Bergmann,
Pali Rohár, Paul Moore, James Morris, Serge E. Hallyn,
linux-alpha, linux-kernel, linux-arm-kernel, linux-m68k,
linux-mips, linux-parisc, linuxppc-dev, linux-s390, linux-sh,
sparclinux, linux-fsdevel, linux-security-module, linux-api,
linux-arch, linux-xfs
In-Reply-To: <20250424-zuspielen-luxus-3d49b600c3bf@brauner>
On 2025-04-24 11:06:07, Christian Brauner wrote:
> On Wed, Apr 23, 2025 at 11:53:25AM +0200, Jan Kara wrote:
> > On Tue 22-04-25 16:59:02, Christian Brauner wrote:
> > > On Fri, Mar 21, 2025 at 08:48:42PM +0100, Andrey Albershteyn wrote:
> > > > From: Andrey Albershteyn <aalbersh@redhat.com>
> > > >
> > > > Introduce getfsxattrat and setfsxattrat syscalls to manipulate inode
> > > > extended attributes/flags. The syscalls take parent directory fd and
> > > > path to the child together with struct fsxattr.
> > > >
> > > > This is an alternative to FS_IOC_FSSETXATTR ioctl with a difference
> > > > that file don't need to be open as we can reference it with a path
> > > > instead of fd. By having this we can manipulated inode extended
> > > > attributes not only on regular files but also on special ones. This
> > > > is not possible with FS_IOC_FSSETXATTR ioctl as with special files
> > > > we can not call ioctl() directly on the filesystem inode using fd.
> > > >
> > > > This patch adds two new syscalls which allows userspace to get/set
> > > > extended inode attributes on special files by using parent directory
> > > > and a path - *at() like syscall.
> > > >
> > > > CC: linux-api@vger.kernel.org
> > > > CC: linux-fsdevel@vger.kernel.org
> > > > CC: linux-xfs@vger.kernel.org
> > > > Signed-off-by: Andrey Albershteyn <aalbersh@redhat.com>
> > > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > ...
> > > > + struct fsxattr __user *, ufsx, size_t, usize,
> > > > + unsigned int, at_flags)
> > > > +{
> > > > + struct fileattr fa = {};
> > > > + struct path filepath;
> > > > + int error;
> > > > + unsigned int lookup_flags = 0;
> > > > + struct filename *name;
> > > > + struct fsxattr fsx = {};
> > > > +
> > > > + BUILD_BUG_ON(sizeof(struct fsxattr) < FSXATTR_SIZE_VER0);
> > > > + BUILD_BUG_ON(sizeof(struct fsxattr) != FSXATTR_SIZE_LATEST);
> > > > +
> > > > + if ((at_flags & ~(AT_SYMLINK_NOFOLLOW | AT_EMPTY_PATH)) != 0)
> > > > + return -EINVAL;
> > > > +
> > > > + if (!(at_flags & AT_SYMLINK_NOFOLLOW))
> > > > + lookup_flags |= LOOKUP_FOLLOW;
> > > > +
> > > > + if (at_flags & AT_EMPTY_PATH)
> > > > + lookup_flags |= LOOKUP_EMPTY;
> > > > +
> > > > + if (usize > PAGE_SIZE)
> > > > + return -E2BIG;
> > > > +
> > > > + if (usize < FSXATTR_SIZE_VER0)
> > > > + return -EINVAL;
> > > > +
> > > > + name = getname_maybe_null(filename, at_flags);
> > > > + if (!name) {
> > >
> > > This is broken as it doesn't handle AT_FDCWD correctly. You need:
> > >
> > > name = getname_maybe_null(filename, at_flags);
> > > if (IS_ERR(name))
> > > return PTR_ERR(name);
> > >
> > > if (!name && dfd >= 0) {
> > > CLASS(fd, f)(dfd);
> >
> > Ah, you're indeed right that if dfd == AT_FDCWD and filename == NULL, the
> > we should operate on cwd but we'd bail with error here. I've missed that
> > during my review. But as far as I've checked the same bug is there in
> > path_setxattrat() and path_getxattrat() so we should fix this there as
> > well?
>
> Yes, please!
>
Thanks for the review, Christian. I will fix issues you noticed as
suggested. I see that Jan already sent fix for path_[s|g]etxattrat()
so won't do anything here.
--
- Andrey
^ permalink raw reply
* Re: newlines in filenames; POSIX.1-2024
From: Christoph Hellwig @ 2025-04-25 14:54 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: Alejandro Colomar, linux-kernel, linux-api, linux-man
In-Reply-To: <20250422222131.GE569616@mit.edu>
On Tue, Apr 22, 2025 at 05:21:31PM -0500, Theodore Ts'o wrote:
> Do we have any information of which implementations (if any) might
> decide to disallow new-line characters?
AFAIK: none. At least none that matters.
> Personally, I'm not convinced a newline is any different from any
> number of weird-sh*t characters, such as zero-width space Unicode
> characters, ASCII ETX or EOF characters, etc.
It isn't any different in a substantial way.
> I suppose we could add a new mount option which disallows the
> weird-sh*t characters, but I bet it will break some userspace
> programs, and it also begs the question of *which* weird-sh*t
> characters should be disallowed by the kernel.
Don't go there. The only limitations that does make some limited
sense in some limited environment is limiting to valid utf8. We've
already done that for CI, and that's causing enough problems despite
having a use case. Adding random mount options to limit random
characters has a lot of downside but absolutely no actual upside.
>
> > I guess there's no intention to change that behavior. But I should
> > ask. I thought of adding this paragraph to all pages that create
> > file names:
> >
> > +.SH CAVEATS
> > +POSIX.1-2024 encourages implementations to
> > +disallow creation of filenames containing new-line characters.
> > +Linux doesn't follow this,
> > +and allows using new-line characters.
> >
> > Are there any comments?
>
> I think this is giving the Austin Group way more attention/respect
> than they deserve, especially when it's an optional "encourage", but
> whatever...
Yeah. Don't even mention these idiotic recommendations, any attention
spent on this is too much.
^ permalink raw reply
* [PATCH v9 01/15] fs: add atomic write unit max opt to statx
From: John Garry @ 2025-04-25 16:44 UTC (permalink / raw)
To: brauner, djwong, hch, viro, jack, cem
Cc: linux-fsdevel, dchinner, linux-xfs, linux-kernel, ojaswin,
ritesh.list, martin.petersen, linux-ext4, linux-block,
catherine.hoang, linux-api, John Garry
In-Reply-To: <20250425164504.3263637-1-john.g.garry@oracle.com>
XFS will be able to support large atomic writes (atomic write > 1x block)
in future. This will be achieved by using different operating methods,
depending on the size of the write.
Specifically a new method of operation based in FS atomic extent remapping
will be supported in addition to the current HW offload-based method.
The FS method will generally be appreciably slower performing than the
HW-offload method. However the FS method will be typically able to
contribute to achieving a larger atomic write unit max limit.
XFS will support a hybrid mode, where HW offload method will be used when
possible, i.e. HW offload is used when the length of the write is
supported, and for other times FS-based atomic writes will be used.
As such, there is an atomic write length at which the user may experience
appreciably slower performance.
Advertise this limit in a new statx field, stx_atomic_write_unit_max_opt.
When zero, it means that there is no such performance boundary.
Masks STATX{_ATTR}_WRITE_ATOMIC can be used to get this new field. This is
ok for older kernels which don't support this new field, as they would
report 0 in this field (from zeroing in cp_statx()) already. Furthermore
those older kernels don't support large atomic writes - apart from block
fops, but there would be consistent performance there for atomic writes
in range [unit min, unit max].
Signed-off-by: John Garry <john.g.garry@oracle.com>
Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: "Darrick J. Wong" <djwong@kernel.org>
---
block/bdev.c | 3 ++-
fs/ext4/inode.c | 2 +-
fs/stat.c | 6 +++++-
fs/xfs/xfs_iops.c | 2 +-
include/linux/fs.h | 3 ++-
include/linux/stat.h | 1 +
include/uapi/linux/stat.h | 8 ++++++--
7 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/block/bdev.c b/block/bdev.c
index 4844d1e27b6f..b4afc1763e8e 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -1301,7 +1301,8 @@ void bdev_statx(struct path *path, struct kstat *stat,
generic_fill_statx_atomic_writes(stat,
queue_atomic_write_unit_min_bytes(bd_queue),
- queue_atomic_write_unit_max_bytes(bd_queue));
+ queue_atomic_write_unit_max_bytes(bd_queue),
+ 0);
}
stat->blksize = bdev_io_min(bdev);
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 94c7d2d828a6..cdf01e60fa6d 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -5692,7 +5692,7 @@ int ext4_getattr(struct mnt_idmap *idmap, const struct path *path,
awu_max = sbi->s_awu_max;
}
- generic_fill_statx_atomic_writes(stat, awu_min, awu_max);
+ generic_fill_statx_atomic_writes(stat, awu_min, awu_max, 0);
}
flags = ei->i_flags & EXT4_FL_USER_VISIBLE;
diff --git a/fs/stat.c b/fs/stat.c
index f13308bfdc98..c41855f62d22 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -136,13 +136,15 @@ EXPORT_SYMBOL(generic_fill_statx_attr);
* @stat: Where to fill in the attribute flags
* @unit_min: Minimum supported atomic write length in bytes
* @unit_max: Maximum supported atomic write length in bytes
+ * @unit_max_opt: Optimised maximum supported atomic write length in bytes
*
* Fill in the STATX{_ATTR}_WRITE_ATOMIC flags in the kstat structure from
* atomic write unit_min and unit_max values.
*/
void generic_fill_statx_atomic_writes(struct kstat *stat,
unsigned int unit_min,
- unsigned int unit_max)
+ unsigned int unit_max,
+ unsigned int unit_max_opt)
{
/* Confirm that the request type is known */
stat->result_mask |= STATX_WRITE_ATOMIC;
@@ -153,6 +155,7 @@ void generic_fill_statx_atomic_writes(struct kstat *stat,
if (unit_min) {
stat->atomic_write_unit_min = unit_min;
stat->atomic_write_unit_max = unit_max;
+ stat->atomic_write_unit_max_opt = unit_max_opt;
/* Initially only allow 1x segment */
stat->atomic_write_segments_max = 1;
@@ -732,6 +735,7 @@ cp_statx(const struct kstat *stat, struct statx __user *buffer)
tmp.stx_atomic_write_unit_min = stat->atomic_write_unit_min;
tmp.stx_atomic_write_unit_max = stat->atomic_write_unit_max;
tmp.stx_atomic_write_segments_max = stat->atomic_write_segments_max;
+ tmp.stx_atomic_write_unit_max_opt = stat->atomic_write_unit_max_opt;
return copy_to_user(buffer, &tmp, sizeof(tmp)) ? -EFAULT : 0;
}
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 756bd3ca8e00..f0e5d83195df 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -610,7 +610,7 @@ xfs_report_atomic_write(
if (xfs_inode_can_atomicwrite(ip))
unit_min = unit_max = ip->i_mount->m_sb.sb_blocksize;
- generic_fill_statx_atomic_writes(stat, unit_min, unit_max);
+ generic_fill_statx_atomic_writes(stat, unit_min, unit_max, 0);
}
STATIC int
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 016b0fe1536e..7b19d8f99aff 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -3475,7 +3475,8 @@ void generic_fillattr(struct mnt_idmap *, u32, struct inode *, struct kstat *);
void generic_fill_statx_attr(struct inode *inode, struct kstat *stat);
void generic_fill_statx_atomic_writes(struct kstat *stat,
unsigned int unit_min,
- unsigned int unit_max);
+ unsigned int unit_max,
+ unsigned int unit_max_opt);
extern int vfs_getattr_nosec(const struct path *, struct kstat *, u32, unsigned int);
extern int vfs_getattr(const struct path *, struct kstat *, u32, unsigned int);
void __inode_add_bytes(struct inode *inode, loff_t bytes);
diff --git a/include/linux/stat.h b/include/linux/stat.h
index be7496a6a0dd..e3d00e7bb26d 100644
--- a/include/linux/stat.h
+++ b/include/linux/stat.h
@@ -57,6 +57,7 @@ struct kstat {
u32 dio_read_offset_align;
u32 atomic_write_unit_min;
u32 atomic_write_unit_max;
+ u32 atomic_write_unit_max_opt;
u32 atomic_write_segments_max;
};
diff --git a/include/uapi/linux/stat.h b/include/uapi/linux/stat.h
index f78ee3670dd5..1686861aae20 100644
--- a/include/uapi/linux/stat.h
+++ b/include/uapi/linux/stat.h
@@ -182,8 +182,12 @@ struct statx {
/* File offset alignment for direct I/O reads */
__u32 stx_dio_read_offset_align;
- /* 0xb8 */
- __u64 __spare3[9]; /* Spare space for future expansion */
+ /* Optimised max atomic write unit in bytes */
+ __u32 stx_atomic_write_unit_max_opt;
+ __u32 __spare2[1];
+
+ /* 0xc0 */
+ __u64 __spare3[8]; /* Spare space for future expansion */
/* 0x100 */
};
--
2.31.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox