On Mon, Jan 13, 2025 at 4:41 PM Andreas Gruenbacher <agruenba@xxxxxxxxxx> wrote: > Hi Jan, > > Am Fr., 10. Jan. 2025 um 18:18 Uhr schrieb Kun Hu <huk23@xxxxxxxxxxxxxx>: > > > Thanks. Based on the crash report and the reproducer it indeed looks like > > > some mixing of iomap_folio_state and buffer heads attached to a folio > > > (iomap_folio_state is attached there but we end up calling > > > __block_write_begin_int() which expects buffer heads there) in GFS2. GFS2 > > > guys, care to have a look? > > > > > > > Thanks to Jan. > > > > Hi Andreas, > > > > It seems that iomap_write_begin is expected to handle I/O directly based on folio, rather than entering the buffer head path. Is it possible that GFS2 incorrectly passes data related to buffer head to iomap_write_begin? > > > > Could you please help us to check the exact cause of the issue? > > 32generated_program.c memory maps the filesystem image, mounts it, and > then modifies it through the memory map. It's those modifications that > cause gfs2 to crash, so the test case is invalid. Ah, I misread, the memory map is distinct from the filesystem. So forget about disabling CONFIG_BLK_DEV_WRITE_MOUNTED not working. Thanks, Andreas
