From: Damien Le Moal <dlemoal@kernel.org>
To: cem@kernel.org, linux-xfs@vger.kernel.org
Cc: hch@lst.de
Subject: Re: [PATCH 1/4] xfs: factor out isize updates from xfs_dio_write_end_io
Date: Tue, 10 Mar 2026 13:51:20 +0100 [thread overview]
Message-ID: <9127da59-fb17-4c4e-b9c5-ecb745a68693@kernel.org> (raw)
In-Reply-To: <20260310115555.114197-2-cem@kernel.org>
On 2026/03/10 12:55, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
>
> This is the only code needed for zoned inodes, so factor it out so
> we can move zoned inodes ioend to its own callback.
>
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
> fs/xfs/xfs_file.c | 59 +++++++++++++++++++++++++++++------------------
> 1 file changed, 36 insertions(+), 23 deletions(-)
>
> diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
> index 6246f34df9fd..45ecd743fa32 100644
> --- a/fs/xfs/xfs_file.c
> +++ b/fs/xfs/xfs_file.c
> @@ -560,6 +560,41 @@ xfs_zoned_write_space_reserve(
> flags, ac);
> }
>
> +/*
> + * We need to lock the test/set EOF update as we can be racing with
> + * other IO completions here to update the EOF. Failing to serialise
> + * here can result in EOF moving backwards and Bad Things Happen when
> + * that occurs.
> + *
> + * As IO completion only ever extends EOF, we can do an unlocked check
> + * here to avoid taking the spinlock. If we land within the current EOF,
> + * then we do not need to do an extending update at all, and we don't
> + * need to take the lock to check this. If we race with an update moving
> + * EOF, then we'll either still be beyond EOF and need to take the lock,
> + * or we'll be within EOF and we don't need to take it at all.
> + */
> +static int
> +xfs_dio_endio_set_isize(
> + struct inode *inode,
> + loff_t offset,
> + ssize_t size)
> +{
> + struct xfs_inode *ip = XFS_I(inode);
> +
> + if (offset + size <= i_size_read(inode))
> + return 0;
> +
> + spin_lock(&ip->i_flags_lock);
> + if (offset + size > i_size_read(inode)) {
> + i_size_write(inode, offset + size);
> + spin_unlock(&ip->i_flags_lock);
> + } else {
> + spin_unlock(&ip->i_flags_lock);
> + }
The spinlock unlock does not need to be inside the if and else:
+ spin_lock(&ip->i_flags_lock);
+ if (offset + size > i_size_read(inode))
+ i_size_write(inode, offset + size);
+ spin_unlock(&ip->i_flags_lock);
Other than this, looks OK to me.
> +
> + return xfs_setfilesize(ip, offset, size);
> +}
> +
> static int
> xfs_dio_write_end_io(
> struct kiocb *iocb,
> @@ -623,30 +658,8 @@ xfs_dio_write_end_io(
> * with the on-disk inode size being outside the in-core inode size. We
> * have no other method of updating EOF for AIO, so always do it here
> * if necessary.
> - *
> - * We need to lock the test/set EOF update as we can be racing with
> - * other IO completions here to update the EOF. Failing to serialise
> - * here can result in EOF moving backwards and Bad Things Happen when
> - * that occurs.
> - *
> - * As IO completion only ever extends EOF, we can do an unlocked check
> - * here to avoid taking the spinlock. If we land within the current EOF,
> - * then we do not need to do an extending update at all, and we don't
> - * need to take the lock to check this. If we race with an update moving
> - * EOF, then we'll either still be beyond EOF and need to take the lock,
> - * or we'll be within EOF and we don't need to take it at all.
> */
> - if (offset + size <= i_size_read(inode))
> - goto out;
> -
> - spin_lock(&ip->i_flags_lock);
> - if (offset + size > i_size_read(inode)) {
> - i_size_write(inode, offset + size);
> - spin_unlock(&ip->i_flags_lock);
> - error = xfs_setfilesize(ip, offset, size);
> - } else {
> - spin_unlock(&ip->i_flags_lock);
> - }
> + error = xfs_dio_endio_set_isize(inode, offset, size);
>
> out:
> memalloc_nofs_restore(nofs_flag);
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2026-03-10 12:51 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-10 11:55 [PATCH 0/4] Zoned device cleanups cem
2026-03-10 11:55 ` [PATCH 1/4] xfs: factor out isize updates from xfs_dio_write_end_io cem
2026-03-10 12:51 ` Damien Le Moal [this message]
2026-03-10 12:52 ` Christoph Hellwig
2026-03-10 11:55 ` [PATCH 2/4] xfs: move zoned dio ioend to its own function cem
2026-03-10 12:53 ` Christoph Hellwig
2026-03-10 12:54 ` Damien Le Moal
2026-03-10 11:55 ` [PATCH 3/4] xfs: factor out xfs_zone_inc_written cem
2026-03-10 12:54 ` Christoph Hellwig
2026-03-10 12:55 ` Damien Le Moal
2026-03-10 11:55 ` [PATCH 4/4] xfs: opencode xfs_zone_record_blocks cem
2026-03-10 12:54 ` Christoph Hellwig
2026-03-10 12:56 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9127da59-fb17-4c4e-b9c5-ecb745a68693@kernel.org \
--to=dlemoal@kernel.org \
--cc=cem@kernel.org \
--cc=hch@lst.de \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.