From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: hch@lst.de, viro@zeniv.linux.org.uk, brauner@kernel.org,
dchinner@redhat.com, jack@suse.cz, chandan.babu@oracle.com,
martin.petersen@oracle.com, linux-kernel@vger.kernel.org,
linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
tytso@mit.edu, jbongio@google.com, ojaswin@linux.ibm.com
Subject: Re: [PATCH 6/6] fs: xfs: Set FMODE_CAN_ATOMIC_WRITE for FS_XFLAG_ATOMICWRITES set
Date: Fri, 23 Feb 2024 20:18:30 -0800 [thread overview]
Message-ID: <20240224041830.GK6184@frogsfrogsfrogs> (raw)
In-Reply-To: <f7ad3aed-3482-4eee-8c81-8e471916ef82@oracle.com>
On Wed, Feb 21, 2024 at 05:38:39PM +0000, John Garry wrote:
> On 21/02/2024 17:00, Darrick J. Wong wrote:
> > > > Hmm. Well, if we move towards pushing all the hardware checks out of
> > > > xfs/iomap and into whatever goes on underneath submit_bio then I guess
> > > > we don't need to check device support here at all.
> > > Yeah, I have been thinking about this. But I was still planning on putting a
> > > "bdev on atomic write" check here, as you mentioned.
> > >
> > > But is this a proper method to access the bdev for an xfs inode:
> > >
> > > STATIC bool
> > > xfs_file_can_atomic_write(
> > > struct xfs_inode *inode)
> > > {
> > > struct xfs_buftarg *target = xfs_inode_buftarg(inode);
> > > struct block_device *bdev = target->bt_bdev;
> > >
> > > if (!xfs_inode_atomicwrites(inode))
> > > return false;
> > >
> > > return bdev_can_atomic_write(bdev);
> > > }
> > There's still a TOCTOU race problem if the bdev gets reconfigured
> > between xfs_file_can_atomic_write and submit_bio.
>
> If that is the case then a check in the bio submit path is required to catch
> any such reconfigure problems - and we effectively have that in this series.
>
> I am looking at change some of these XFS bdev_can_atomic_write() checks, but
> would still have a check in the bio submit path.
<nod> "check in the bio submit path" sounds good to me. Adding in
redundant checks which are eventually gated on whatever submit_bio does
sounds like excessive overhead and layering violations.
> >
> > However, if you're only using this to advertise the capability via statx
> > then I suppose that's fine -- userspace has to have some means of
> > discovering the ability at all. Userspace is also inherently racy.
> >
> > > I do notice the dax check in xfs_bmbt_to_iomap() when assigning iomap->bdev,
> > > which is creating some doubt?
> > Do you mean this?
> >
> > if (mapping_flags & IOMAP_DAX)
> > iomap->dax_dev = target->bt_daxdev;
> > else
> > iomap->bdev = target->bt_bdev;
> >
> > The dax path wants dax_dev set so that it can do the glorified memcpy
> > operation, and it doesn't need (or want) a block device.
>
> Yes, so proper to use target->bt_bdev for checks for bdev atomic write
> capability, right?
Right. fsdax doesn't support atomic memcpy to pmem.
--D
>
> Thanks,
> John
>
>
next prev parent reply other threads:[~2024-02-24 4:18 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 14:26 [PATCH 0/6] block atomic writes for XFS John Garry
2024-01-24 14:26 ` [PATCH 1/6] fs: iomap: Atomic write support John Garry
2024-02-02 17:25 ` Darrick J. Wong
2024-02-05 11:29 ` John Garry
2024-02-13 6:55 ` Christoph Hellwig
2024-02-13 8:20 ` John Garry
2024-02-15 11:08 ` John Garry
2024-02-13 18:08 ` Darrick J. Wong
2024-02-05 15:20 ` Pankaj Raghav (Samsung)
2024-02-05 15:41 ` John Garry
2024-01-24 14:26 ` [PATCH 2/6] fs: Add FS_XFLAG_ATOMICWRITES flag John Garry
2024-02-02 17:57 ` Darrick J. Wong
2024-02-05 12:58 ` John Garry
2024-02-13 6:56 ` Christoph Hellwig
2024-02-13 17:08 ` Darrick J. Wong
2024-01-24 14:26 ` [PATCH 3/6] fs: xfs: Support FS_XFLAG_ATOMICWRITES for rtvol John Garry
2024-02-02 17:52 ` Darrick J. Wong
2024-02-03 7:40 ` Ojaswin Mujoo
2024-02-05 12:51 ` John Garry
2024-02-13 17:22 ` Darrick J. Wong
2024-02-14 12:19 ` John Garry
2024-01-24 14:26 ` [PATCH 4/6] fs: xfs: Support atomic write for statx John Garry
2024-02-02 18:05 ` Darrick J. Wong
2024-02-05 13:10 ` John Garry
2024-02-13 17:37 ` Darrick J. Wong
2024-02-14 12:26 ` John Garry
2024-02-09 7:00 ` Ojaswin Mujoo
2024-02-09 17:30 ` John Garry
2024-02-12 11:48 ` Ojaswin Mujoo
2024-02-12 12:05 ` Ojaswin Mujoo
2024-01-24 14:26 ` [PATCH RFC 5/6] fs: xfs: iomap atomic write support John Garry
2024-02-02 18:47 ` Darrick J. Wong
2024-02-05 13:36 ` John Garry
2024-02-06 1:15 ` Dave Chinner
2024-02-06 9:53 ` John Garry
2024-02-07 0:06 ` Dave Chinner
2024-02-07 14:13 ` John Garry
2024-02-09 1:40 ` Dave Chinner
2024-02-09 12:47 ` John Garry
2024-02-13 23:41 ` Dave Chinner
2024-02-14 11:06 ` John Garry
2024-02-14 23:03 ` Dave Chinner
2024-02-15 9:53 ` John Garry
2024-02-13 17:50 ` Darrick J. Wong
2024-02-14 12:13 ` John Garry
2024-01-24 14:26 ` [PATCH 6/6] fs: xfs: Set FMODE_CAN_ATOMIC_WRITE for FS_XFLAG_ATOMICWRITES set John Garry
2024-02-02 18:06 ` Darrick J. Wong
2024-02-05 10:26 ` John Garry
2024-02-13 17:59 ` Darrick J. Wong
2024-02-14 12:36 ` John Garry
2024-02-21 17:00 ` Darrick J. Wong
2024-02-21 17:38 ` John Garry
2024-02-24 4:18 ` Darrick J. Wong [this message]
2024-02-09 7:14 ` [PATCH 0/6] block atomic writes for XFS Ojaswin Mujoo
2024-02-09 9:22 ` John Garry
2024-02-12 12:06 ` Ojaswin Mujoo
2024-02-13 7:22 ` Christoph Hellwig
2024-02-13 17:55 ` Darrick J. Wong
2024-02-14 7:45 ` Christoph Hellwig
2024-02-21 16:56 ` Darrick J. Wong
2024-02-23 6:57 ` Christoph Hellwig
2024-02-13 23:50 ` Dave Chinner
2024-02-14 7:38 ` Christoph Hellwig
2024-02-13 7:45 ` Ritesh Harjani
2024-02-13 8:41 ` John Garry
2024-02-13 9:10 ` Ritesh Harjani
2024-02-13 22:49 ` Dave Chinner
2024-02-14 10:10 ` John Garry
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=20240224041830.GK6184@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=brauner@kernel.org \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jbongio@google.com \
--cc=john.g.garry@oracle.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=ojaswin@linux.ibm.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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).