From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Carlos Maiolino <cem@kernel.org>,
Christoph Hellwig <hch@infradead.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 21:46:09 -0700 [thread overview]
Message-ID: <Z_82ETKMHDxE4N2e@infradead.org> (raw)
In-Reply-To: <20250415003308.GE25675@frogsfrogsfrogs>
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?
> +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.
> +
> + 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?
> + 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.
next prev parent reply other threads:[~2025-04-16 4:46 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 [this message]
2025-04-16 5:06 ` Darrick J. Wong
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=Z_82ETKMHDxE4N2e@infradead.org \
--to=hch@infradead.org \
--cc=axboe@kernel.dk \
--cc=cem@kernel.org \
--cc=djwong@kernel.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