All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao Xiang <hsiangkao@linux.alibaba.com>
To: Jan Kiszka <jan.kiszka@siemens.com>, Gao Xiang <xiang@kernel.org>,
	Chao Yu <chao@kernel.org>,
	linux-erofs@lists.ozlabs.org
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Executable loading issues with erofs on arm?
Date: Tue, 8 Jul 2025 23:36:57 +0800	[thread overview]
Message-ID: <2bfd263e-d6f7-4dcd-adf5-2518ba34c36b@linux.alibaba.com> (raw)
In-Reply-To: <6216008a-dc0c-4f90-a67c-36bead99d7f2@linux.alibaba.com>



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?

Thanks,
Gao Xiang


  reply	other threads:[~2025-07-08 15:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08 12:41 Executable loading issues with erofs on arm? Jan Kiszka
2025-07-08 12:43 ` Jan Kiszka
2025-07-08 15:12   ` Gao Xiang
2025-07-08 15:22     ` Jan Kiszka
2025-07-08 15:32       ` Gao Xiang
2025-07-08 15:36         ` Gao Xiang [this message]
2025-07-08 15:57           ` Gao Xiang
2025-07-08 16:39             ` Jan Kiszka
2025-07-08 17:01               ` Jan Kiszka
2025-07-08 17:09                 ` Gao Xiang
2025-07-08 17:24                   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2bfd263e-d6f7-4dcd-adf5-2518ba34c36b@linux.alibaba.com \
    --to=hsiangkao@linux.alibaba.com \
    --cc=chao@kernel.org \
    --cc=jan.kiszka@siemens.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiang@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.