[PATCH] fs: remove power of 2 and length boundary atomic write restrictions
John Garry
john.g.garry at oracle.com
Mon Dec 29 23:54:23 PST 2025
On 24/12/2025 11:53, Vitaliy Filippov wrote:
> generic_atomic_write_valid() returns EINVAL for non-power-of-2 and for
> non-length-aligned writes. This check is used for block devices, ext4
> and xfs, but neither ext4 nor xfs rely on power of 2 restrictions.
>
> For block devices, neither NVMe nor SCSI specification doesn't require
> length alignment and 2^N length. Both specifications only require to
> respect the atomic write boundary if it's set (NABSPF/NABO for NVMe and
> ATOMIC BOUNDARY for SCSI).
> NVMe subsystem already checks writes against
> this boundary; SCSI uses an explicit atomic write command so the write
> is checked by the drive itself.
>
Yes, they do check it - this is a safeguard against being sent something
which cannot be atomically written. But we should not be sending
something to the driver or disk which cannot be atomically written. So
we are providing protection against kernel bugs.
The user should not be concerned about atomic boundaries. They should
not encounter a scenario where they try a write which crosses a boundary
(and cannot be atomically written). Hence the power-of-2 and alignment
rule to avoid this.
> Signed-off-by: Vitaliy Filippov <vitalifster at gmail.com>
> ---
> fs/read_write.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/fs/read_write.c b/fs/read_write.c
> index 833bae068770..5467d710108d 100644
> --- a/fs/read_write.c
> +++ b/fs/read_write.c
> @@ -1802,17 +1802,9 @@ int generic_file_rw_checks(struct file *file_in, struct file *file_out)
>
> int generic_atomic_write_valid(struct kiocb *iocb, struct iov_iter *iter)
> {
> - size_t len = iov_iter_count(iter);
> -
> if (!iter_is_ubuf(iter))
> return -EINVAL;
>
> - if (!is_power_of_2(len))
> - return -EINVAL;
> -
> - if (!IS_ALIGNED(iocb->ki_pos, len))
> - return -EINVAL;
> -
> if (!(iocb->ki_flags & IOCB_DIRECT))
> return -EOPNOTSUPP;
>
More information about the Linux-nvme
mailing list