On 4/24/25 18:43, Dmitry Antipov wrote: > On 4/24/25 11:58 AM, Chao Yu wrote: > >> I guess we need to figure out why f2fs_bug_on() will be tiggerred? >> >> f2fs_write_end_io() >> { >> ... >> f2fs_bug_on(sbi, folio->mapping == NODE_MAPPING(sbi) && >> folio->index != nid_of_node(&folio->page)); > > Well, syzkaller is very "creative" in generating weirdly damaged filesystems > :-).
Yeah. > > An overall idea of the patch is that an attempt to complete I/O on a > filesystem > which is known to be "broken enough to run fsck" may make the things even > worse > (by making the filesystem even less consistent). So it may be safer just to > refuse all in-flight write attempts at least. We will handle IO once there is critical error (tagged w/ CP_ERROR_FLAG), you can check the detailed behaviors as below: errors=%s Specify f2fs behavior on critical errors. This supports modes: "panic", "continue" and "remount-ro", respectively, trigger panic immediately, continue without doing anything, and remount the partition in read-only mode. By default it uses "continue" mode. ====================== =============== =============== ======== mode continue remount-ro panic ====================== =============== =============== ======== access ops normal normal N/A syscall errors -EIO -EROFS N/A mount option rw ro N/A pending dir write keep keep N/A pending non-dir write drop keep N/A pending node write drop keep N/A pending meta write keep keep N/A ====================== =============== =============== ======== But for SBI_NEED_FSCK case, if the inconsistency is detected in specific inode, can we just stop further updates for this inode? Rather than all inodes? Thanks, > > Dmitry > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel