From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C2AC38E8D1 for ; Fri, 19 Jun 2026 14:20:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.118 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781878861; cv=none; b=po7NNFGkGRKAztZw4BgSDNDn5bPvgaCsEInrpiEorG5mOwUkZmyQ4bU798uf41W4CkO64O822nAUZvaWiLaygKZNogjK8hK5uZw5wJ+RQs9Q7JVQuwCjqkL4PCl1nlDRe8LgOd4qSQWyVXefNCgsMkJYgTNMo4kaXeXP1WBpKpw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781878861; c=relaxed/simple; bh=nJWPfwIGyYDlO6tF8wro/kU5vl4+nle8Pupbr5ar5hg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=RD0JiilfHOyvKkd1n1z+YDBrBgH/xa7U8VW5afdyznv0zHwJeUZVw5OdzfaxX4xYYB4ABJ5PE3ssuD6UIAx1CvfHPngn3NVB2Hwtnyo7Y7KD/a6+xpUlxCqenChMM1gFfWJckH/S5f8ZttXUa/5jf6FbS4FEQ1dl8VgVgu/G1Kw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=icjg2msl; arc=none smtp.client-ip=115.124.30.118 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="icjg2msl" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1781878851; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=v7QN8cgA1vRY/cW4m/TkqL9jlmMh794tIfnv4Iho4io=; b=icjg2mslHZrTTX5WXnSnp/zkQDNThaH9Mzmak3QLSc/cs6LzeEDH6fwJ57B17xfz4Q6H0d/PcumdL4OsF3QUMIXyTOJnv9BYPWJyhpTkVRk0mtfxxseO2uYrneZwrH7YZp4S1EHf2ez+y+CtWrCwp5/ogRRcbyIX4sMTEsOzIOk= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0X5A-J1P_1781878849; Received: from 30.120.66.214(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X5A-J1P_1781878849 cluster:ay36) by smtp.aliyun-inc.com; Fri, 19 Jun 2026 22:20:50 +0800 Message-ID: Date: Fri, 19 Jun 2026 22:20:48 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] erofs: complete fscache pseudo-bio once when a read is split To: Michael Bommarito , Gao Xiang , Chao Yu Cc: Yue Hu , Jeffle Xu , Sandeep Dhavale , linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org References: <20260619135800.1594811-1-michael.bommarito@gmail.com> From: Gao Xiang In-Reply-To: <20260619135800.1594811-1-michael.bommarito@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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@vger.kernel.org > Signed-off-by: Michael Bommarito > 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