Re: erofs pointer corruption and kernel crash

[Gao Xiang <hsiangkao@linux.alibaba.com>]

On 2026/4/11 23:10, Arseniy Krasnov wrote:
> 
> 
> 10.04.2026 18:41, Gao Xiang пишет:
>> Hi Arseniy,
>>
>> On 2026/4/10 21:27, Arseniy Krasnov wrote:
>>>
>>>
>>> 10.04.2026 15:20, Gao Xiang пишет:
>>>>
>>>>
>>>> On 2026/4/10 19:37, Arseniy Krasnov wrote:
>>>>
>>>> (drop unrelated folks since they all subscribed erofs mailing list)
>>>>
>>>>>
>>>>>
>>>>> 10.04.2026 11:31, Gao Xiang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 2026/4/10 16:13, Arseniy Krasnov wrote:

...

>>>>>>
>>>>>> I need more informations to find some clues.
>>>>>
>>>>>
>>>>>
>>>>> So reproduced again with this debug patch which adds magic to 'struct z_erofs_pcluster' and prints 'struct folio'
>>>>> when pointer in 'private' is passed to 'erofs_onlinefolio_end()'. In short - 'private' points to 'struct z_erofs_pcluster'.
>>>> First, erofs-utils 1.8.10 doesn't support `-E48bit`:
>>>> only erofs-utils 1.9+ ship it as an experimental
>>>> feature, see Changelog; so I think you're using
>>>> modified erofs-utils 1.8.10:
>>>> https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git/tree/ChangeLog
>>>>
>>>> ```
>>>> erofs-utils 1.9
>>>>
>>>>    * This release includes the following updates:
>>>>      - Add 48-bit layout support for larger filesystems (EXPERIMENTAL);
>>>> ```
>>>>
>>>> Second, I'm pretty sure this issue is related to
>>>> experimenal `-E48bit`, and those information is
>>>> not enough for me to find the root cause, so I
>>>> need to find a way to reproduce myself: It may
>>>> take time; you could debug yourself but I don't
>>>> think it's an easy task if you don't quite familiar
>>>> with the EROFS codebase.
>>>>
>>>> Anyway I really suggest if you need a rush solution
>>>> for production, don't use `-E48bit + zstd` like
>>>> this for now: try to use other options like
>>>> `-zzstd -C65536 -Efragments` instead since those
>>>> are common production choices.
>>>
>>> Ok thanks for this advice! One more question: currently we use this options:
>>> "zstd,22 --max-extent-bytes 65536 -E48bit". Ok we remove "zstd,22" and "E48bit",
>>> but what about "--max-extent-bytes 65536" - is it considered stable option?
>>> Or it is better to use your version: "-zzstd -C65536 -Efragments" ?
>>
>> I'm not sure how you find this
>> "zstd,22 --max-extent-bytes 65536 -E48bit" combination.
>>
>> My suggestion based on production is that as long as
>> you don't use `-zzstd` ++ `-E48bit`, it should be fine.
>>
>> If you need smaller images, I suggest: `-zlzma,9 -C65536 -Efragments`
>> Or like Android, they all use `-zlz4hc`,
>> Or zstd, but don't add `-E48bit`.
>>
>> As for "--max-extent-bytes 65536", it can be dropped
>> since if `-E48bit` is not used, it only has negative
>> impacts.
>>
>> In short, `-E48bit` + `-zzstd` + `--max-extent-bytes`
>> enables new unaligned compression for zstd, but it's
>> a relatively new feature, I still still some time to
>> stablize it but my own time is limited and all things
>> are always prioritized.
> 
> Ok, thanks for this advice!

FYI, I can reproduce this issue locally with `-E48bit`
on in 600s.

I do think it's a `-E48bit` + zstd issue so
non-`-E48bit` won't be impacted and I will find time
to troubleshoot it this week.

Thanks,
Gao Xiang

> 
> Thanks
> 
>>
>> Thanks,
>> Gao Xiang
>>
>>>
>>> Thanks
>>>
>>>>
>>>> Thanks,
>>>> Gao Xiang
>>