Re: [RFC[RAP] 1/2] block: fix race between set_blocksize and read paths

[Christoph Hellwig <hch@infradead.org>]

On Tue, Apr 15, 2025 at 10:01:44PM -0700, Darrick J. Wong wrote:
> It's the same patch as:
> https://lore.kernel.org/linux-fsdevel/20250408175125.GL6266@frogsfrogsfrogs/
> 
> which is to say, xfs/032 with while true; do blkid; done running in the
> background to increase the chances of a collision.

I think the xfs-zoned CI actually hit this with 032 without any extra
action the.

> 	/*
> 	 * Flush and truncate the pagecache before we reconfigure the
> 	 * mapping geometry because folio sizes are variable now.  If
> 	 * a reader has already allocated a folio whose size is smaller
> 	 * than the new min_order but invokes readahead after the new
> 	 * min_order becomes visible, readahead will think there are
> 	 * "zero" blocks per folio and crash.
> 	 */
> 
> And then the read/write paths can say something simpler:
> 
> 	/*
> 	 * Take i_rwsem and invalidate_lock to avoid racing with a
> 	 * blocksize change punching out the pagecache.
> 	 */

Sounds reasonable.

> > I also wonder if we need locking asserts in some of the write side
> > functions that expect the shared inode lock and invalidate lock now?
> 
> Probably.  Do you have specific places in mind?

Looking at it more closely: no.  We're only calling very low-level
helpers, so this might not actually be feasible.