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

On Wed, Jan 14, 2026 at 1:25 PM Michal Koutný <[email protected]> wrote:
>
> 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.)

It is just another optimization. Without this flag, we would need to
parse mm->saved_auxv even when it hasn't been changed.

>
> 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()).


Currently, it is a user responsibility to synchronize these calls.
The comment in prctl_set_mm_map states:
  Note this update of @saved_auxv is lockless thus
  if someone reads this member in procfs while we're
  updating -- it may get partly updated results. It's
  known and acceptable trade off: we leave it as is to
  not introduce additional locks here making the kernel
  more complex.

Without synchronization between threads calling prctl() and execve(), a
new process could be executed with inconsistent HWCAPs. However, this
would not trigger any issues within the kernel. If we decide to
synchronize access to saved_auxv, we can use mm->arg_lock for that
purpose.

Thanks,
Andrei