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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).