Re: [PATCH v4 experimental-tests] erofs-utils: tests: test FUSE error handling on corrupted inodes

On 2026/4/1 16:05, Gao Xiang wrote:
> 
> 
> On 2026/4/1 15:55, Nithurshen wrote:
>> This patch introduces a regression test (erofs/099) to verify that
>> the FUSE daemon gracefully handles corrupted inodes without crashing
>> or violating the FUSE protocol.
>>
>> Recently, a bug was identified where erofs_read_inode_from_disk()
>> would fail, but erofsfuse_getattr() lacked a return statement
>> after sending an error reply. This caused a fall-through, sending
>> a second reply via fuse_reply_attr() and triggering a libfuse
>> segmentation fault.
>>
>> To prevent future regressions, this test:
>> 1. Creates a valid EROFS image.
>> 2. Surgically corrupts the root inode (injecting random data at
>>     offset 1152) while leaving the superblock intact so it mounts.
>> 3. Mounts the image in the foreground to capture daemon stderr.
>> 4. Runs 'stat' to trigger the inode read failure.
>> 5. Evaluates the stderr log to ensure no segfaults, aborts, or
>>     "multiple replies" warnings are emitted by libfuse.
>>
>> Signed-off-by: Nithurshen <[email protected]>
>> ---
>> Changes in v4:
>> - Corrected the commit message and notes to accurately match the
>>    code submitted (v3 accidentally included a draft message that
>>    did not match the diff).
>>
>> Changes in v3:
>> - Disabled superblock checksums using `-Enosbcrc` in _scratch_mkfs.
>> - Used `_scratch_unmount` instead of standard `umount`.
>>
>> Note regarding the corruption method:
>> My apologies for the confusion in v3. The email described
>> using `dump.erofs` and `0xFF`, but the patch contained my code
>> using the hardcoded offset 1152 and `/dev/urandom`. I am resending
>> the patch as v4 so the commit message accurately reflects the code.
>>
>> I originally kept the hardcoded root offset (1152) because targeting
>> `/testfile` dynamically with `/dev/urandom` was slightly flaky. If
>> the random bytes happened to form a valid-looking layout, the bug
>> was bypassed. Wiping 1024 bytes at offset 1152 reliably destroys the
>> root metadata and guarantees the bug triggers 100% of the time.
>>
>> Is this hardcoded offset approach acceptable for this specific test?
>> If you strictly prefer the `dump.erofs` approach (using 0xFF instead
>> of urandom to guarantee the error), please let me know and I will
>> gladly send those updates in a v5 patch.
> 
> Are we still miscommunicating? I asked using `dump.erofs` for many
> many times but you still send those useless patches?
> 
> Is it hard to understand? No hardcode offset please.

And why do you think /dev/urandom is a good idea? A regression test
is needed, determination is needed, why bother with /dev/urandom?

> 
> Thanks,
> Gao Xiang