From: "Darrick J. Wong" <djwong@kernel.org>
To: John Garry <john.g.garry@oracle.com>
Cc: axboe@kernel.dk, tytso@mit.edu, dchinner@redhat.com,
viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.com,
chandan.babu@oracle.com, hch@lst.de, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, gfs2@lists.linux.dev,
linux-xfs@vger.kernel.org, catherine.hoang@oracle.com,
ritesh.list@gmail.com, mcgrof@kernel.org,
mikulas@artax.karlin.mff.cuni.cz, agruenba@redhat.com,
miklos@szeredi.hu, martin.petersen@oracle.com
Subject: Re: [PATCH v4 01/22] fs: Add generic_atomic_write_valid_size()
Date: Thu, 20 Jun 2024 14:24:01 -0700 [thread overview]
Message-ID: <20240620212401.GA3058325@frogsfrogsfrogs> (raw)
In-Reply-To: <a123946e-1df2-48da-b120-67b50c3aa9f5@oracle.com>
On Thu, Jun 13, 2024 at 08:35:53AM +0100, John Garry wrote:
> On 12/06/2024 22:10, Darrick J. Wong wrote:
> > On Fri, Jun 07, 2024 at 02:38:58PM +0000, John Garry wrote:
> > > Add a generic helper for FSes to validate that an atomic write is
> > > appropriately sized (along with the other checks).
> > >
> > > Signed-off-by: John Garry <john.g.garry@oracle.com>
> > > ---
> > > include/linux/fs.h | 12 ++++++++++++
> > > 1 file changed, 12 insertions(+)
> > >
> > > diff --git a/include/linux/fs.h b/include/linux/fs.h
> > > index 069cbab62700..e13d34f8c24e 100644
> > > --- a/include/linux/fs.h
> > > +++ b/include/linux/fs.h
> > > @@ -3645,4 +3645,16 @@ bool generic_atomic_write_valid(loff_t pos, struct iov_iter *iter)
> > > return true;
> > > }
> > > +static inline
> > > +bool generic_atomic_write_valid_size(loff_t pos, struct iov_iter *iter,
> > > + unsigned int unit_min, unsigned int unit_max)
> > > +{
> > > + size_t len = iov_iter_count(iter);
> > > +
> > > + if (len < unit_min || len > unit_max)
> > > + return false;
> > > +
> > > + return generic_atomic_write_valid(pos, iter);
> > > +}
> >
> > Now that I look back at "fs: Initial atomic write support" I wonder why
> > not pass the iocb and the iov_iter instead of pos and the iov_iter?
>
> The original user of generic_atomic_write_valid() [blkdev_dio_unaligned() or
> blkdev_dio_invalid() with the rename] used these same args, so I just went
> with that.
Don't let the parameter types of static blockdev helpers determine the
VFS API that filesystems need to implement untorn writes.
In the block layer enablement patch, this could easily be:
bool generic_atomic_write_valid(const struct kiocb *iocb,
const struct iov_iter *iter)
{
size_t len = iov_iter_count(iter);
if (!iter_is_ubuf(iter))
return false;
if (!is_power_of_2(len))
return false;
if (!IS_ALIGNED(iocb->ki_pos, len))
return false;
return true;
}
Then this becomes:
bool generic_atomic_write_valid_size(const struct kiocb *iocb,
const struct iov_iter *iter,
unsigned int unit_min,
unsigned int unit_max)
{
size_t len = iov_iter_count(iter);
if (len < unit_min || len > unit_max)
return false;
return generic_atomic_write_valid(iocb, iter);
}
Yes, that means you have to rearrange the calling conventions of
blkdev_dio_invalid a little bit, but the first two arguments match
->read_iter and ->write_iter. Filesystem writers can see that the first
two arguments are the first two parameters to foofs_write_iter() and
focus on the hard part, which is figuring out unit_{min,max}.
static ssize_t
xfs_file_dio_write(
struct kiocb *iocb,
struct iov_iter *from)
{
...
if ((iocb->ki_flags & IOCB_ATOMIC) &&
!generic_atomic_write_valid_size(iocb, from,
i_blocksize(inode),
XFS_FSB_TO_B(mp, ip->i_extsize)))
return -EINVAL;
}
> > And can these be collapsed into a single generic_atomic_write_checks()
> > function?
>
> bdev file operations would then need to use
> generic_atomic_write_valid_size(), and there is no unit_min and unit_max
> size there, apart from bdev awu min and max. And if I checked them, we would
> be duplicating checks (of awu min and max) in the block layer.
Fair enough, I concede this point.
--D
>
> Cheers,
> John
>
next prev parent reply other threads:[~2024-06-20 21:24 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 14:38 [PATCH v4 00/22] block atomic writes for xfs John Garry
2024-06-07 14:38 ` [PATCH v4 01/22] fs: Add generic_atomic_write_valid_size() John Garry
2024-06-12 21:10 ` Darrick J. Wong
2024-06-13 7:35 ` John Garry
2024-06-20 21:24 ` Darrick J. Wong [this message]
2024-06-07 14:38 ` [PATCH v4 02/22] iomap: Allow filesystems set IO block zeroing size John Garry
2024-06-12 21:32 ` Darrick J. Wong
2024-06-13 10:31 ` John Garry
2024-06-21 21:18 ` Darrick J. Wong
2024-06-24 13:58 ` John Garry
2024-06-07 14:39 ` [PATCH v4 03/22] xfs: Use extent size granularity for iomap->io_block_size John Garry
2024-06-12 21:47 ` Darrick J. Wong
2024-06-13 11:13 ` John Garry
2024-06-07 14:39 ` [PATCH v4 04/22] xfs: only allow minlen allocations when near ENOSPC John Garry
2024-06-07 14:39 ` [PATCH v4 05/22] xfs: always tail align maxlen allocations John Garry
2024-06-07 14:39 ` [PATCH v4 06/22] xfs: simplify extent allocation alignment John Garry
2024-06-07 14:39 ` [PATCH v4 07/22] xfs: make EOF allocation simpler John Garry
2024-06-07 14:39 ` [PATCH v4 08/22] xfs: introduce forced allocation alignment John Garry
2024-06-07 14:39 ` [PATCH v4 09/22] xfs: align args->minlen for " John Garry
2024-06-07 14:39 ` [PATCH v4 10/22] xfs: Introduce FORCEALIGN inode flag John Garry
2024-06-07 14:39 ` [PATCH v4 11/22] xfs: Do not free EOF blocks for forcealign John Garry
2024-06-07 14:39 ` [PATCH v4 12/22] xfs: Update xfs_inode_alloc_unitsize_fsb() " John Garry
2024-06-07 14:39 ` [PATCH v4 13/22] xfs: Unmap blocks according to forcealign John Garry
2024-06-11 10:08 ` John Garry
2024-06-07 14:39 ` [PATCH v4 14/22] xfs: Only free full extents for forcealign John Garry
2024-06-07 14:39 ` [PATCH v4 15/22] xfs: Don't revert allocated offset " John Garry
2024-06-07 14:39 ` [PATCH v4 16/22] xfs: Enable file data forcealign feature John Garry
2024-06-07 14:39 ` [PATCH v4 17/22] fs: Add FS_XFLAG_ATOMICWRITES flag John Garry
2024-06-07 14:39 ` [PATCH v4 18/22] iomap: Atomic write support John Garry
2024-06-07 14:39 ` [PATCH v4 19/22] xfs: Support FS_XFLAG_ATOMICWRITES for forcealign John Garry
2024-06-07 14:39 ` [PATCH v4 20/22] xfs: Support atomic write for statx John Garry
2024-06-07 14:39 ` [PATCH v4 21/22] xfs: Validate atomic writes John Garry
2024-06-07 14:39 ` [PATCH v4 22/22] xfs: Support setting FMODE_CAN_ATOMIC_WRITE 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=20240620212401.GA3058325@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=agruenba@redhat.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=catherine.hoang@oracle.com \
--cc=chandan.babu@oracle.com \
--cc=dchinner@redhat.com \
--cc=gfs2@lists.linux.dev \
--cc=hch@lst.de \
--cc=jack@suse.com \
--cc=john.g.garry@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-erofs@lists.ozlabs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mcgrof@kernel.org \
--cc=miklos@szeredi.hu \
--cc=mikulas@artax.karlin.mff.cuni.cz \
--cc=ritesh.list@gmail.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).