Re: [PATCH 2/4] exec: inherit HWCAPs from the parent process

On Fri, Mar 20, 2026 at 2:15 AM Marek Szyprowski
<[email protected]> wrote:
>
> Hi,
>
> On 17.02.2026 19:01, Andrei Vagin wrote:
> > Introduces a mechanism to inherit hardware capabilities (AT_HWCAP,
> > AT_HWCAP2, etc.) from a parent process when they have been modified via
> > prctl.
> >
> > To support C/R operations (snapshots, live migration) in heterogeneous
> > clusters, we must ensure that processes utilize CPU features available
> > on all potential target nodes. To solve this, we need to advertise a
> > common feature set across the cluster.
> >
> > This patch adds a new mm flag MMF_USER_HWCAP, which is set when the
> > auxiliary vector is modified via prctl(PR_SET_MM, PR_SET_MM_AUXV).  When
> > execve() is called, if the current process has MMF_USER_HWCAP set, the
> > HWCAP values are extracted from the current auxiliary vector and stored
> > in the linux_binprm structure. These values are then used to populate
> > the auxiliary vector of the new process, effectively inheriting the
> > hardware capabilities.
> >
> > The inherited HWCAPs are masked with the hardware capabilities supported
> > by the current kernel to ensure that we don't report more features than
> > actually supported. This is important to avoid unexpected behavior,
> > especially for processes with additional privileges.
> >
> > Reviewed-by: Cyrill Gorcunov <[email protected]>
> > Reviewed-by: Alexander Mikhalitsyn <[email protected]>
> > Signed-off-by: Andrei Vagin <[email protected]>
>
> This patch landed in yesterday's linux-next as commit ac8c259ce0d5
> ("exec: inherit HWCAPs from the parent process"). In my tests I found
> that it causes regression on my Khadas VIM3L board, which is based
> on Amlogic Meson SM1 (S905D3) SoC
> (arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts). Running init
> process fails after this patch:
>
> Freeing unused kernel memory: 13696K
> Run /sbin/init as init process
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
> CPU: 1 UID: 0 PID: 1 Comm: init Not tainted 7.0.0-rc4-next-20260319
> #12369 PREEMPT
> Hardware name: Khadas VIM3L (DT)
>
> What is probably important here, this board (for some internal,
> historical reasons) uses armv7l rootfs, but other boards used in my
> tests, based on different SoCs, also use such rootfs and boot fine with
> yesterday's linux-next. Reverting ac8c259ce0d5 commit (together with
> 0ea77bbf3b98 due to dependencies) on top of next-20260319 fixes this issue.


Hi Marek.

Thank you for the report. I’ve sent a new version of this series here:
https://patchew.org/linux/[email protected]/.
The reported issue should be fixed in this version. Could you please
give it a try?

Thanks,
Andrei