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

Reply via email to