Re: [PATCH] erofs: complete fscache pseudo-bio once when a read is split

[Gao Xiang]

On 2026/6/19 21:58, Michael Bommarito wrote:
> In fscache mode a compressed read uses one pseudo-bio whose io->end_io is
> erofs_fscache_bio_endio(). When prepare_ondemand_read() splits the read at
> a cached/uncached boundary, erofs_fscache_read_io_async() issues several
> fscache subreads on the same bio and erofs_fscache_bio_endio() calls
> bio_endio() on each. The pseudo-bio is not chained, so z_erofs_endio()
> runs once per subread while z_erofs_submit_queue() counted the bio only
> once, underflowing pending_bios: the reader hangs in D state, or, on async
> completion, the first completion frees the decompress queue and the rest
> are use-after-free.
>
> Hold a bio_inc_remaining() reference per issued subread and drop the
> submitter's initial reference with one bio_endio() once submission
> finishes, so the bio completes exactly once. The request path
> (erofs_fscache_req_end_io) is unaffected; it uses its own refcount and
> never calls bio_endio().
>
> Fixes: a1bafc3109d7 ("erofs: support compressed inodes over fscache")
> Cc: stable@xxxxxxxxxxxxxxx
> Signed-off-by: Michael Bommarito <michael.bommarito@xxxxxxxxx>
> Assisted-by: Claude:claude-opus-4-7
> ---
>
> Reproduced on x86-64 with KASAN via the erofs-on-demand path (a cachefiles
> ondemand daemon serving a crafted compressed image that splits a pcluster
> read). Found with the help of an automated review tool.
>
> Without this patch a stock kernel either hangs the reader:
>
>    task:dd  state:D
>    filemap_get_pages / erofs_file_read_iter
>
> or, when completion is asynchronous, faults:
>
>    BUG: KASAN: slab-use-after-free in z_erofs_endio
>    Kernel panic - not syncing: Fatal exception in interrupt
>
> With this patch the same daemon, image and reads complete cleanly: no
> hang, no KASAN report, no panic. Harness and full logs available on
> request.

fscache is already deprecated, I will remove this path
in this or the next cycle: it's not worth to improve
this, and bio_inc_remaining is suspicious since I never
tend to introduce chain pseudo-bios.

Thanks,
Gao Xiang