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.
