[PATCH v3 0/3] xfs and DAX atomic writes changes

[PATCH v3 0/3] xfs and DAX atomic writes changes

[John Garry]

This series contains an atomic writes fix for DAX support on xfs and
an improvement to WARN against using IOCB_ATOMIC on the DAX write path.

Also included is an xfs atomic writes mount option fix.

Based on xfs -next at ("b0494366bd5b Merge branch 'xfs-6.17-merge' into
for-next")

John Garry (3):
  fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()
  xfs: disallow atomic writes on DAX
  xfs: reject max_atomic_write mount option for no reflink

 fs/dax.c           |  3 +++
 fs/xfs/xfs_file.c  |  6 +++---
 fs/xfs/xfs_inode.h | 11 +++++++++++
 fs/xfs/xfs_iops.c  |  5 +++--
 fs/xfs/xfs_mount.c | 19 +++++++++++++++++++
 5 files changed, 39 insertions(+), 5 deletions(-)

-- 
2.43.5

[PATCH v3 1/3] fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()

[John Garry]

The DAX write path does not support IOCB_ATOMIC, so reject it when set.

Suggested-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 fs/dax.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/dax.c b/fs/dax.c
index ea0c35794bf9..d9ce810fee9e 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1756,6 +1756,9 @@ dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,
 	loff_t done = 0;
 	int ret;
 
+	if (WARN_ON_ONCE(iocb->ki_flags & IOCB_ATOMIC))
+		return -EIO;
+
 	if (!iomi.len)
 		return 0;
 
-- 
2.43.5

[PATCH v3 2/3] xfs: disallow atomic writes on DAX

[John Garry]

Atomic writes are not currently supported for DAX, but two problems exist:
- we may go down DAX write path for IOCB_ATOMIC, which does not handle
  IOCB_ATOMIC properly
- we report non-zero atomic write limits in statx (for DAX inodes)

We may want atomic writes support on DAX in future, but just disallow for
now.

For this, ensure when IOCB_ATOMIC is set that we check the write size
versus the atomic write min and max before branching off to the DAX write
path. This is not strictly required for DAX, as we should not get this far
in the write path as FMODE_CAN_ATOMIC_WRITE should not be set.

In addition, due to reflink being supported for DAX, we automatically get
CoW-based atomic writes support being advertised. Remedy this by
disallowing atomic writes for a DAX inode for both sw and hw modes.

Reported-by: Darrick J. Wong <djwong@kernel.org>
Fixes: 9dffc58f2384 ("xfs: update atomic write limits")
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 fs/xfs/xfs_file.c  |  6 +++---
 fs/xfs/xfs_inode.h | 11 +++++++++++
 fs/xfs/xfs_iops.c  |  5 +++--
 3 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index ed69a65f56d7..979abcb25bc7 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1099,9 +1099,6 @@ xfs_file_write_iter(
 	if (xfs_is_shutdown(ip->i_mount))
 		return -EIO;
 
-	if (IS_DAX(inode))
-		return xfs_file_dax_write(iocb, from);
-
 	if (iocb->ki_flags & IOCB_ATOMIC) {
 		if (ocount < xfs_get_atomic_write_min(ip))
 			return -EINVAL;
@@ -1114,6 +1111,9 @@ xfs_file_write_iter(
 			return ret;
 	}
 
+	if (IS_DAX(inode))
+		return xfs_file_dax_write(iocb, from);
+
 	if (iocb->ki_flags & IOCB_DIRECT) {
 		/*
 		 * Allow a directio write to fall back to a buffered
diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
index 07fbdcc4cbf5..bd6d33557194 100644
--- a/fs/xfs/xfs_inode.h
+++ b/fs/xfs/xfs_inode.h
@@ -358,9 +358,20 @@ static inline bool xfs_inode_has_bigrtalloc(const struct xfs_inode *ip)
 
 static inline bool xfs_inode_can_hw_atomic_write(const struct xfs_inode *ip)
 {
+	if (IS_DAX(VFS_IC(ip)))
+		return false;
+
 	return xfs_inode_buftarg(ip)->bt_awu_max > 0;
 }
 
+static inline bool xfs_inode_can_sw_atomic_write(const struct xfs_inode *ip)
+{
+	if (IS_DAX(VFS_IC(ip)))
+		return false;
+
+	return xfs_can_sw_atomic_write(ip->i_mount);
+}
+
 /*
  * In-core inode flags.
  */
diff --git a/fs/xfs/xfs_iops.c b/fs/xfs/xfs_iops.c
index 149b5460fbfd..603effabe1ee 100644
--- a/fs/xfs/xfs_iops.c
+++ b/fs/xfs/xfs_iops.c
@@ -616,7 +616,8 @@ xfs_get_atomic_write_min(
 	 * write of exactly one single fsblock if the bdev will make that
 	 * guarantee for us.
 	 */
-	if (xfs_inode_can_hw_atomic_write(ip) || xfs_can_sw_atomic_write(mp))
+	if (xfs_inode_can_hw_atomic_write(ip) ||
+	    xfs_inode_can_sw_atomic_write(ip))
 		return mp->m_sb.sb_blocksize;
 
 	return 0;
@@ -633,7 +634,7 @@ xfs_get_atomic_write_max(
 	 * write of exactly one single fsblock if the bdev will make that
 	 * guarantee for us.
 	 */
-	if (!xfs_can_sw_atomic_write(mp)) {
+	if (!xfs_inode_can_sw_atomic_write(ip)) {
 		if (xfs_inode_can_hw_atomic_write(ip))
 			return mp->m_sb.sb_blocksize;
 		return 0;
-- 
2.43.5

[PATCH v3 3/3] xfs: reject max_atomic_write mount option for no reflink

[John Garry]

If the FS has no reflink, then atomic writes greater than 1x block are not
supported. As such, for no reflink it is pointless to accept setting
max_atomic_write when it cannot be supported, so reject max_atomic_write
mount option in this case.

It could be still possible to accept max_atomic_write option of size 1x
block if HW atomics are supported, so check for this specifically.

Fixes: 4528b9052731 ("xfs: allow sysadmins to specify a maximum atomic write limit at mount time")
Signed-off-by: John Garry <john.g.garry@oracle.com>
---
 fs/xfs/xfs_mount.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index 0b690bc119d7..1ec70f4e57b4 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -784,6 +784,25 @@ xfs_set_max_atomic_write_opt(
 		return -EINVAL;
 	}
 
+	if (xfs_has_reflink(mp))
+		goto set_limit;
+
+	if (new_max_fsbs == 1) {
+		if (mp->m_ddev_targp->bt_awu_max ||
+		    (mp->m_rtdev_targp && mp->m_rtdev_targp->bt_awu_max)) {
+		} else {
+			xfs_warn(mp,
+ "cannot support atomic writes of size %lluk with no reflink or HW support",
+				new_max_bytes >> 10);
+			return -EINVAL;
+		}
+	} else {
+		xfs_warn(mp,
+ "cannot support atomic writes of size %lluk with no reflink support",
+				new_max_bytes >> 10);
+		return -EINVAL;
+	}
+
 set_limit:
 	error = xfs_calc_atomic_write_reservation(mp, new_max_fsbs);
 	if (error) {
-- 
2.43.5

Re: [PATCH v3 1/3] fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()

[Darrick J. Wong]

On Thu, Jul 24, 2025 at 08:12:13AM +0000, John Garry wrote:
> The DAX write path does not support IOCB_ATOMIC, so reject it when set.
> 
> Suggested-by: Darrick J. Wong <djwong@kernel.org>
> Signed-off-by: John Garry <john.g.garry@oracle.com>

Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  fs/dax.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/fs/dax.c b/fs/dax.c
> index ea0c35794bf9..d9ce810fee9e 100644
> --- a/fs/dax.c
> +++ b/fs/dax.c
> @@ -1756,6 +1756,9 @@ dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,
>  	loff_t done = 0;
>  	int ret;
>  
> +	if (WARN_ON_ONCE(iocb->ki_flags & IOCB_ATOMIC))
> +		return -EIO;
> +
>  	if (!iomi.len)
>  		return 0;
>  
> -- 
> 2.43.5
> 
> 

Re: [PATCH v3 3/3] xfs: reject max_atomic_write mount option for no reflink

[Darrick J. Wong]

On Thu, Jul 24, 2025 at 08:12:15AM +0000, John Garry wrote:
> If the FS has no reflink, then atomic writes greater than 1x block are not
> supported. As such, for no reflink it is pointless to accept setting
> max_atomic_write when it cannot be supported, so reject max_atomic_write
> mount option in this case.
> 
> It could be still possible to accept max_atomic_write option of size 1x
> block if HW atomics are supported, so check for this specifically.
> 
> Fixes: 4528b9052731 ("xfs: allow sysadmins to specify a maximum atomic write limit at mount time")
> Signed-off-by: John Garry <john.g.garry@oracle.com>

/me wonders if "mkfs: allow users to configure the desired maximum
atomic write size" needs a similar filter?

Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> ---
>  fs/xfs/xfs_mount.c | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index 0b690bc119d7..1ec70f4e57b4 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -784,6 +784,25 @@ xfs_set_max_atomic_write_opt(
>  		return -EINVAL;
>  	}
>  
> +	if (xfs_has_reflink(mp))
> +		goto set_limit;
> +
> +	if (new_max_fsbs == 1) {
> +		if (mp->m_ddev_targp->bt_awu_max ||
> +		    (mp->m_rtdev_targp && mp->m_rtdev_targp->bt_awu_max)) {
> +		} else {
> +			xfs_warn(mp,
> + "cannot support atomic writes of size %lluk with no reflink or HW support",
> +				new_max_bytes >> 10);
> +			return -EINVAL;
> +		}
> +	} else {
> +		xfs_warn(mp,
> + "cannot support atomic writes of size %lluk with no reflink support",
> +				new_max_bytes >> 10);
> +		return -EINVAL;
> +	}
> +
>  set_limit:
>  	error = xfs_calc_atomic_write_reservation(mp, new_max_fsbs);
>  	if (error) {
> -- 
> 2.43.5
> 
> 

Re: [PATCH v3 3/3] xfs: reject max_atomic_write mount option for no reflink

[John Garry]

On 24/07/2025 17:32, Darrick J. Wong wrote:
> On Thu, Jul 24, 2025 at 08:12:15AM +0000, John Garry wrote:
>> If the FS has no reflink, then atomic writes greater than 1x block are not
>> supported. As such, for no reflink it is pointless to accept setting
>> max_atomic_write when it cannot be supported, so reject max_atomic_write
>> mount option in this case.
>>
>> It could be still possible to accept max_atomic_write option of size 1x
>> block if HW atomics are supported, so check for this specifically.
>>
>> Fixes: 4528b9052731 ("xfs: allow sysadmins to specify a maximum atomic write limit at mount time")
>> Signed-off-by: John Garry<john.g.garry@oracle.com>
> /me wonders if "mkfs: allow users to configure the desired maximum
> atomic write size" needs a similar filter?
> 

Yeah, probably. But I am wondering if we should always require reflink 
for setting that max atomic mkfs option, and not have a special case of 
HW atomics available for 1x blocksize atomic writes.

> Reviewed-by: "Darrick J. Wong"<djwong@kernel.org>

cheers

Re: [PATCH v3 3/3] xfs: reject max_atomic_write mount option for no reflink

[Darrick J. Wong]

On Fri, Jul 25, 2025 at 09:39:42AM +0100, John Garry wrote:
> On 24/07/2025 17:32, Darrick J. Wong wrote:
> > On Thu, Jul 24, 2025 at 08:12:15AM +0000, John Garry wrote:
> > > If the FS has no reflink, then atomic writes greater than 1x block are not
> > > supported. As such, for no reflink it is pointless to accept setting
> > > max_atomic_write when it cannot be supported, so reject max_atomic_write
> > > mount option in this case.
> > > 
> > > It could be still possible to accept max_atomic_write option of size 1x
> > > block if HW atomics are supported, so check for this specifically.
> > > 
> > > Fixes: 4528b9052731 ("xfs: allow sysadmins to specify a maximum atomic write limit at mount time")
> > > Signed-off-by: John Garry<john.g.garry@oracle.com>
> > /me wonders if "mkfs: allow users to configure the desired maximum
> > atomic write size" needs a similar filter?
> > 
> 
> Yeah, probably. But I am wondering if we should always require reflink for
> setting that max atomic mkfs option, and not have a special case of HW
> atomics available for 1x blocksize atomic writes.

I think that's reasonable for mkfs since reflink=1 has been the default
for quite a long while now.

--D

> > Reviewed-by: "Darrick J. Wong"<djwong@kernel.org>
> 
> cheers
> 

Re: [PATCH v3 0/3] xfs and DAX atomic writes changes

[John Garry]

On 24/07/2025 09:12, John Garry wrote:

Hi Carlos,

I was expecting you to pick these up.

Shall I resend next week after v6.17-rc1 is released?

Thanks,
John

> This series contains an atomic writes fix for DAX support on xfs and
> an improvement to WARN against using IOCB_ATOMIC on the DAX write path.
> 
> Also included is an xfs atomic writes mount option fix.
> 
> Based on xfs -next at ("b0494366bd5b Merge branch 'xfs-6.17-merge' into
> for-next")
> 
> John Garry (3):
>    fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()
>    xfs: disallow atomic writes on DAX
>    xfs: reject max_atomic_write mount option for no reflink
> 
>   fs/dax.c           |  3 +++
>   fs/xfs/xfs_file.c  |  6 +++---
>   fs/xfs/xfs_inode.h | 11 +++++++++++
>   fs/xfs/xfs_iops.c  |  5 +++--
>   fs/xfs/xfs_mount.c | 19 +++++++++++++++++++
>   5 files changed, 39 insertions(+), 5 deletions(-)
> 

Re: [PATCH v3 0/3] xfs and DAX atomic writes changes

[Carlos Maiolino]

On Wed, Aug 06, 2025 at 10:15:10AM +0100, John Garry wrote:
> On 24/07/2025 09:12, John Garry wrote:
> 
> Hi Carlos,
> 
> I was expecting you to pick these up.

I did, for -rc1.

> 
> Shall I resend next week after v6.17-rc1 is released?

No, I already have them queued up for -rc1, no need to send them again

Carlos

> 
> Thanks,
> John
> 
> > This series contains an atomic writes fix for DAX support on xfs and
> > an improvement to WARN against using IOCB_ATOMIC on the DAX write path.
> >
> > Also included is an xfs atomic writes mount option fix.
> >
> > Based on xfs -next at ("b0494366bd5b Merge branch 'xfs-6.17-merge' into
> > for-next")
> >
> > John Garry (3):
> >    fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()
> >    xfs: disallow atomic writes on DAX
> >    xfs: reject max_atomic_write mount option for no reflink
> >
> >   fs/dax.c           |  3 +++
> >   fs/xfs/xfs_file.c  |  6 +++---
> >   fs/xfs/xfs_inode.h | 11 +++++++++++
> >   fs/xfs/xfs_iops.c  |  5 +++--
> >   fs/xfs/xfs_mount.c | 19 +++++++++++++++++++
> >   5 files changed, 39 insertions(+), 5 deletions(-)
> >
> 
> 

Re: [PATCH v3 0/3] xfs and DAX atomic writes changes

[John Garry]

On 11/08/2025 13:06, Carlos Maiolino wrote:
>> I was expecting you to pick these up.
> I did, for -rc1.
> 
>> Shall I resend next week after v6.17-rc1 is released?
> No, I already have them queued up for -rc1, no need to send them again

Great, thanks. I was just prepping to send again :)

Re: [PATCH v3 0/3] xfs and DAX atomic writes changes

[Carlos Maiolino]

On Mon, Aug 11, 2025 at 01:08:59PM +0100, John Garry wrote:
> On 11/08/2025 13:06, Carlos Maiolino wrote:
> >> I was expecting you to pick these up.
> > I did, for -rc1.
> >
> >> Shall I resend next week after v6.17-rc1 is released?
> > No, I already have them queued up for -rc1, no need to send them again
> 
> Great, thanks. I was just prepping to send again :)

Sorry, I meant I have them queued up for -rc2 :-) i.e. this week I'm
sending them to Linus

Re: [PATCH v3 0/3] xfs and DAX atomic writes changes

[Carlos Maiolino]

On Thu, 24 Jul 2025 08:12:12 +0000, John Garry wrote:
> This series contains an atomic writes fix for DAX support on xfs and
> an improvement to WARN against using IOCB_ATOMIC on the DAX write path.
> 
> Also included is an xfs atomic writes mount option fix.
> 
> Based on xfs -next at ("b0494366bd5b Merge branch 'xfs-6.17-merge' into
> for-next")
> 
> [...]

Applied to for-next, thanks!

[1/3] fs/dax: Reject IOCB_ATOMIC in dax_iomap_rw()
      commit: e7fb9b71326f43bab25fb8f18c6bfebd7a628696
[2/3] xfs: disallow atomic writes on DAX
      commit: 68456d05eb57a5d16b4be2d3caf421bdcf2de72e
[3/3] xfs: reject max_atomic_write mount option for no reflink
      commit: 8dc5e9b037138317c1d3151a7dabe41fa171cee1

Best regards,
-- 
Carlos Maiolino <cem@kernel.org>