From: "Darrick J. Wong" <djwong@kernel.org>
To: lukas@herbolt.com
Cc: Christoph Hellwig <hch@infradead.org>, linux-xfs@vger.kernel.org
Subject: Re: [PATCH RFC] xfs: add FALLOC_FL_WRITE_ZEROES to XFS code base
Date: Tue, 14 Oct 2025 14:15:32 -0700 [thread overview]
Message-ID: <20251014211532.GF6188@frogsfrogsfrogs> (raw)
In-Reply-To: <dee6b75856d013f8aa6de1c17ff0f20a@herbolt.com>
On Tue, Oct 14, 2025 at 10:10:51AM +0200, lukas@herbolt.com wrote:
> On 2025-10-04 06:16, Christoph Hellwig wrote:
> > On Fri, Oct 03, 2025 at 09:00:20PM -0700, Darrick J. Wong wrote:
> > > > > - error = xfs_alloc_file_space(XFS_I(inode), offset, len);
> > > > > + if (mode & FALLOC_FL_WRITE_ZEROES) {
> > > > > + if (!bdev_write_zeroes_unmap_sectors(inode->i_sb->s_bdev))
> > >
> > > not correct ^^^^^^^^^^^^^^^^^^^
> > >
> > > You need to find the block device associated with the file because XFS
> > > is a multi-device filesystem.
> >
> > Indeed. xfs_inode_buftarg will do the work, but we'll need to ensure
>
> Thanks for xfs_inode_buftarg pointer.
>
> > the RT bit doesn't get flipped, i.e. it needs to hold a lock between
> > that check and allocation the blocks if there were none yet.
>
> I am having bit of trouble with that. If I get it right we should hold
> the XFS_ILOCK_EXCL but this lock is then grabbed in the
> xfs_trans_alloc_inode.
>
> So I would need to release before and there would be again a small window
> where the RT flag can be flipped.
>
> Looking at the xfs_alloc_file_space, there is also check for the RT bit
> without
> lock, so this also need an attention.
> rt = XFS_IS_REALTIME_INODE(ip);
> extsz = xfs_get_extsz_hint(ip);
>
> Or the xfs_trans_alloc_inode would need to check if we are a;ready holding
> the
> lock Is there a way how to check the current thread is the owner of the
> xfs_ilock rw_sem?
Hm? The VFS takes inode_lock in vfs_fileattr_set prior to changing the
rt status bit, and and __xfs_file_fallocate takes the same lock (aka the
IOLOCK) before calling xfs_falloc_*.
IOWs, a call to xfs_inode_buftarg would see a stable realtime flag and
return the correct results.
--D
>
> Something like?
> ---
> static inline bool is_current_writer(struct rw_semaphore *sem)
> {
> /* The rwsem_owner() helper can be used to get the owner */
> return sem->owner == current;
> }
> ---
>
next prev parent reply other threads:[~2025-10-14 21:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-02 12:28 [PATCH RFC] xfs: add FALLOC_FL_WRITE_ZEROES to XFS code base Lukas Herbolt
2025-10-03 7:51 ` Christoph Hellwig
2025-10-04 4:00 ` Darrick J. Wong
2025-10-04 4:16 ` Christoph Hellwig
2025-10-14 8:10 ` lukas
2025-10-14 21:15 ` Darrick J. Wong [this message]
2025-10-15 6:30 ` Nirjhar Roy (IBM)
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=20251014211532.GF6188@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.kernel.org \
--cc=lukas@herbolt.com \
/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.