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

[Gao Xiang]

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 <nithurshen.dev at gmail.com>
> ---
> 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.

Thanks,
Gao Xiang