public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
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

  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