From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-97.freemail.mail.aliyun.com (out30-97.freemail.mail.aliyun.com [115.124.30.97]) (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 E25D4366569 for ; Mon, 13 Apr 2026 07:08:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.97 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776064109; cv=none; b=WLasmaty+O02XkEuClm9dk7Xj+LYPEMLWEWXqMToVIZFfJQeYiGeUZgGAm728hgiVS7EIZb6KWlP24Q0EEayabxE9jkoWcU45rmD3gPf/HPAXm/PkGRngfr+2Fyi7E/nkOvVgW3aW+RHN5gEhTlUyrNxEC7+FpQs5HddmNXXDEU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776064109; c=relaxed/simple; bh=RpXkXiUnUPE/idzoh9L+FoX6K+zdK5SzOrnqpTrvOAc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=nNOUOjPBz/S7mG8vnm6ftj1r1JYkBxFVvnbp5MKqoCxyWv515tkfyA8Ex72AbTNu7a5eF3IuDWLTp7FMGmUL0KVHvWv/i80FIf+UYdN+h3o6Er7fjQ/22h+gUsmpXYspfJAiwZ9KePKxpMH0HVaiw9a+25t3wBJutTVAHVfMicA= 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=aZyDaXKW; arc=none smtp.client-ip=115.124.30.97 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="aZyDaXKW" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1776064097; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=Myd6heIPYY5oZbZGObWNmzfsPoo7eCmh/psW9L72t5A=; b=aZyDaXKW3vg27s8krzE2z3kaEOd4ALxQHFXYfAWinUNBEx0vOiHru2fsQNepMcv9Emp3Xwqq9tVqC8BKtd8uBiasFmx4zjvPTQpYBL69v5VaHwsNP5t1pd8i4cPulqJg36b5fTfDiRCx6VJuMOtbdxlyg7NXWgeo2ICXwXeadck= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R791e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=6;SR=0;TI=SMTPD_---0X0tSL6c_1776064096; Received: from 30.221.131.170(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X0tSL6c_1776064096 cluster:ay36) by smtp.aliyun-inc.com; Mon, 13 Apr 2026 15:08:16 +0800 Message-ID: <36cddf44-3e08-4a19-82ed-04ca178ffab5@linux.alibaba.com> Date: Mon, 13 Apr 2026 15:08:15 +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: erofs pointer corruption and kernel crash To: Arseniy Krasnov Cc: oxffffaa@gmail.com, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org, kernel@salutedevices.com, Gao Xiang References: <4a2f3801-fac1-42fe-ae75-da315822e088@salutedevices.com> <2e916997-0557-45e7-831a-b436c07c5ba4@salutedevices.com> <97ca00c7-822d-4b57-9dc0-9b396049adc9@salutedevices.com> <8c0bdfab-dbf2-4f1e-8e2a-ce18f166d841@linux.alibaba.com> <2ca3c8c6-f3ed-40ca-8f5c-1b43df479ad7@salutedevices.com> From: Gao Xiang In-Reply-To: <2ca3c8c6-f3ed-40ca-8f5c-1b43df479ad7@salutedevices.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 >>