[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y5suEZgZn6JNIKxm@B-P7TQMD6M-0146.local>
Date: Thu, 15 Dec 2022 22:24:17 +0800
From: Gao Xiang <hsiangkao@...ux.alibaba.com>
To: Tudor Ambarus <tudor.ambarus@...aro.org>
Cc: linux-erofs@...ts.ozlabs.org, xiang@...nel.org, chao@...nel.org,
huyue2@...lpad.com, jefflexu@...ux.alibaba.com,
joneslee@...gle.com, linux-kernel@...r.kernel.org
Subject: Re: BUG: unable to handle kernel paging request in
z_erofs_decompress_queue
Hi Tudor,
On Thu, Dec 15, 2022 at 02:58:10PM +0200, Tudor Ambarus wrote:
> Hi, Gao, Chao, Yue, Jeffle, all,
>
> Syzbot reported a bug at [1] that is reproducible in upstream kernel
> since
> commit 47e4937a4a7c ("erofs: move erofs out of staging")
>
> and up to (inclusively)
> commit 2bfab9c0edac ("erofs: record the longest decompressed size in this
> round")
>
> The first commit that makes this bug go away is:
> commit 267f2492c8f7 ("erofs: introduce multi-reference pclusters
> (fully-referenced)")
> Although, this commit looks like new support and not like an explicit
> bug fix.
>
> I'd like to fix the lts kernels. I'm happy to try any suggestions or do
> some tests. Please let me know if the bug rings a bell.
Thanks for your report. I will try to seek time to look at this this
weekend. But just from your description, I guess that there could be
something wrong on several compressed extents pointing to the same
blocks (i.e. the same pcluster). But prior to commit 267f2492c8f7, such
image is always considered as corrupted images.
Anyway, I will look into that and see if there could be alternative ways
to fix this rather than backport the whole multi-reference pcluster
feature. Yet I think no need to worry since such image is pretty
crafted and should be used as normal images.
Thanks,
Gao Xiang
>
> Thanks,
> ta
>
> [1]
> https://syzkaller.appspot.com/bug?id=a9b56d324d0de9233ad80633826fac76836d792a
Powered by blists - more mailing lists