linux-kernel - Re: Executable loading issues with erofs on arm?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <eb879ced-600a-4dd3-a9d6-3c391b4460c2@siemens.com>
Date: Tue, 8 Jul 2025 19:01:42 +0200
From: Jan Kiszka <jan.kiszka@...mens.com>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>, Gao Xiang <xiang@...nel.org>,
 Chao Yu <chao@...nel.org>, linux-erofs@...ts.ozlabs.org
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Executable loading issues with erofs on arm?

On 08.07.25 18:39, Jan Kiszka wrote:
> On 08.07.25 17:57, Gao Xiang wrote:
>>
>>
>> On 2025/7/8 23:36, Gao Xiang wrote:
>>>
>>>
>>> On 2025/7/8 23:32, Gao Xiang wrote:
>>>>
>>>>
>>>> On 2025/7/8 23:22, Jan Kiszka wrote:
>>>>> On 08.07.25 17:12, Gao Xiang wrote:
>>>>>> Hi Jan,
>>>>>>
>>>>>> On 2025/7/8 20:43, Jan Kiszka wrote:
>>>>>>> On 08.07.25 14:41, Jan Kiszka wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> for some days, I'm trying to understand if we have an integration
>>>>>>>> issue
>>>>>>>> with erofs or rather some upstream bug. After playing with various
>>>>>>>> parameters, it rather looks like the latter:
>>>>>>>>
>>>>>>>> $ ls -l erofs-dir/
>>>>>>>> total 132
>>>>>>>> -rwxr-xr-x 1 1000 users 132868 Jul  8 10:50 dash
>>>>>>>> (from Debian bookworm)
>>>>>>>> $ mkfs.erofs -z lz4hc erofs.img erofs-dir/
>>>>>>>> mkfs.erofs 1.8.6 (trixie version, but same happens with bookworm
>>>>>>>> 1.5)
>>>>>>>> Build completed.
>>>>>>>> ------
>>>>>>>> Filesystem UUID: aae0b2f0-4ee4-4850-af49-3c1aad7fa30c
>>>>>>>> Filesystem total blocks: 17 (of 4096-byte blocks)
>>>>>>>> Filesystem total inodes: 2
>>>>>>>> Filesystem total metadata blocks: 1
>>>>>>>> Filesystem total deduplicated bytes (of source files): 0
>>>>>>>>
>>>>>>>> Now I have 6.15-rc5 and a defconfig-close setting for the 32-bit ARM
>>>>>>>> target BeagleBone Black. When booting into init=/bin/sh, then
>>>>>>>> running
>>>>>>>>
>>>>>>>> # mount -t erofs /dev/mmcblk0p1 /mnt
>>>>>>>> erofs (device mmcblk0p1): mounted with root inode @ nid 36.
>>>>>>>> # /mnt/dash
>>>>>>>> Segmentation fault
>>>
>>> Two extra quick questions:
>>>   - If the segfault happens, then if you run /mnt/dash again, does
>>>     segfault still happen?
>>>
>>>   - If the /mnt/dash segfault happens, then if you run
>>>       cat /mnt/dash > /dev/null
>>>       /mnt/dash
>>>     does segfault still happen?
>>
>> Oh, sorry I didn't read the full hints, could you check if
>> the following patch resolve the issue (space-damaged)?
>>
>> diff --git a/fs/erofs/data.c b/fs/erofs/data.c
>> index 6a329c329f43..701490b3ef7d 100644
>> --- a/fs/erofs/data.c
>> +++ b/fs/erofs/data.c
>> @@ -245,6 +245,7 @@ void erofs_onlinefolio_end(struct folio *folio, int
>> err)
>>         if (v & ~EROFS_ONLINEFOLIO_EIO)
>>                 return;
>>         folio->private = 0;
>> +       flush_dcache_folio(folio);
>>         folio_end_read(folio, !(v & EROFS_ONLINEFOLIO_EIO));
>>  }
>>
> 
> Yeah, indeed that seem to have helped with the minimal test. Will do the
> full scenario test (complete rootfs) next.
> 

And that looks good as! Thanks a lot for that quick fix - hoping that is
the real solution already.

BTW, that change does not look very specific to the armhf arch, rather
like we were lucky that it didn't hit elsewhere, right?

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center