On Sat 16-03-24 04:54:10, Matthew Wilcox wrote: > > This might be an iomap bug, so adding Christoph & Darrick. > > On Sat, Mar 16, 2024 at 12:29:36PM +0800, cheung wall wrote: > > HEAD commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a (tag: v6.7) > > WARNING: CPU: 0 PID: 2920 at fs/buffer.c:1176 > > mark_buffer_dirty+0x232/0x290 > > This is WARN_ON_ONCE(!buffer_uptodate(bh)), so we're trying to mark a > buffer dirty when that buffer is not uptodate. > > > RIP: 0010:mark_buffer_dirty+0x232/0x290 > > fs/buffer.c:1176 > > Call Trace: > > <TASK> > > __block_commit_write+0xe9/0x200 > > fs/buffer.c:2191 > > ... but line 2190 and 91 are: > > set_buffer_uptodate(bh); > mark_buffer_dirty(bh); > > and the folio is locked. So how do we clear the uptodate flag on the > buffer without the folio locked? Given this happens on block device page cache, I can imagine there's someone operating on the cache directly using buffer heads without locking the page. Filesystems do this all the time. I don't see the reproducer doing anything like that but who knows... Honza > > block_write_end+0xb1/0x1f0 > > fs/buffer.c:2267 > > iomap_write_end+0x461/0x8c0 > > fs/iomap/buffered-io.c:857 > > iomap_write_iter > > fs/iomap/buffered-io.c:938 > > [inline] > > iomap_file_buffered_write+0x4eb/0x800 > > fs/iomap/buffered-io.c:987 > > blkdev_buffered_write > > block/fops.c:646 > > [inline] > > blkdev_write_iter+0x4ae/0xa40 > > block/fops.c:696 > > call_write_iter > -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
