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