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

Michal Koutný <[email protected]> Wed, 14 Jan 2026 22:25:11 +0100
Newsgroups dev.linux.lists.criu,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <sp5yxpqi62ymfhjysggmuvxxcwsxtz5kthu64h6kr2poymesbd@3tjqlq7z372p>
On Mon, Jan 12, 2026 at 02:18:18PM -0800, Andrei Vagin <[email protected]> wrote:
> It is true for all existing arch-es. I can't imagine why we would want to
> define ELF_HWCAP{n+1} without having ELF_HWCAP{n}. If you think we need
> to handle this case, I can address it in the next version.
> 
> It is just a small optimization to stop iterating after handling all
> entries. The code will work correctly even when HWCAP n+1 exists but n
> doesn't.

Indeed (I accidentally ignored the AT_VECTOR_SIZE condition), it turns
out no big deal then.
I like that it's not needlessly searched (and copied altogether).

> The inherit_hwcap function is only called if MMF_USER_HWCAP is set (auxv was
> modified via prctl). However, even if mm->saved_auxv hasn't been
> modified, it still contains valid values.

Hm, bprm_mm_init/mm_alloc/mm_init would tranfser the flag from
current, I'm still unclear whether it is necessary here. (It should make
no harm though.)

saved_auxv validity seems OK then.

One more thing came up to my mind -- synchronization between prctl'ing
and exec'ing threads (I see de_thread() is relatively late after
bprm__mm_init()).

Thanks,
Michal