From: "Darrick J. Wong" <djwong@kernel.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Carlos Maiolino <cem@kernel.org>,
axboe@kernel.dk, Luis Chamberlain <mcgrof@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
linux-block <linux-block@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
xfs <linux-xfs@vger.kernel.org>,
Jack Vogel <jack.vogel@oracle.com>
Subject: Re: [RF[CRAP] 2/2] xfs: stop using set_blocksize
Date: Tue, 15 Apr 2025 22:06:32 -0700 [thread overview]
Message-ID: <20250416050632.GA25675@frogsfrogsfrogs> (raw)
In-Reply-To: <Z_82ETKMHDxE4N2e@infradead.org>
On Tue, Apr 15, 2025 at 09:46:09PM -0700, Christoph Hellwig wrote:
> On Mon, Apr 14, 2025 at 05:33:08PM -0700, Darrick J. Wong wrote:
> > +/*
> > + * For bdev filesystems that do not use buffer heads, check that this block
> > + * size is acceptable and flush dirty pagecache to disk.
> > + */
>
> Can you turn this into a full fledged kerneldoc comment?
Ok.
> > +int bdev_use_blocksize(struct file *file, int size)
> > +{
> > + struct inode *inode = file->f_mapping->host;
> > + struct block_device *bdev = I_BDEV(inode);
> > +
> > + if (blk_validate_block_size(size))
> > + return -EINVAL;
> > +
> > + /* Size cannot be smaller than the size supported by the device */
> > + if (size < bdev_logical_block_size(bdev))
> > + return -EINVAL;
> > +
> > + if (!file->private_data)
> > + return -EINVAL;
>
> This private_data check looks really confusing. Looking it up I see
> that it is directly copied from set_blocksize, but it could really
> use a comment. Or in fact be removed here and kept in set_blocksize
> only as we don't care about an exclusive opener at all. Even there
> a comment would be rather helpful, though.
When even is it null? I thought it would either be the holder or
bdev_inode if not.
> > +
> > + return sync_blockdev(bdev);
> > +}
>
> I don't think we need sync_blockdev here as we don't touch the
> bdev page cache. Maybe XFS wants to still call it, but it feels
> wrong in a helper just validating the block size.
>
> So maybe drop it, rename the helper to bdev_validate_block_size
> and use it in set_blocksize instead of duplicating the logic?
Ok. bdev_validate_block_size is a much better name for a tighter
function...
> > + error = bdev_use_blocksize(btp->bt_bdev_file, sectorsize);
>
> .. and then split using it in XFS into a separate patch from adding
> the block layer helper.
...and xfs can call sync_blockdev directly from xfs_setsize_buftarg.
I imagine we still want any dirty pagecache to get flushed before we
start submitting our own read bios.
--D
next prev parent reply other threads:[~2025-04-16 5:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-15 0:14 [RFC[RAP] 1/2] block: fix race between set_blocksize and read paths Darrick J. Wong
2025-04-15 0:33 ` [RF[CRAP] 2/2] xfs: stop using set_blocksize Darrick J. Wong
2025-04-16 4:46 ` Christoph Hellwig
2025-04-16 5:06 ` Darrick J. Wong [this message]
2025-04-16 4:41 ` [RFC[RAP] 1/2] block: fix race between set_blocksize and read paths Christoph Hellwig
2025-04-16 5:01 ` Darrick J. Wong
2025-04-16 5:14 ` Christoph Hellwig
2025-04-18 7:51 ` Shinichiro Kawasaki
2025-04-18 15:29 ` Darrick J. Wong
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=20250416050632.GA25675@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=axboe@kernel.dk \
--cc=cem@kernel.org \
--cc=hch@infradead.org \
--cc=jack.vogel@oracle.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mcgrof@kernel.org \
--cc=willy@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox