On Tue, Dec 30, 2025 at 10:08:04PM +0100, Arnd Bergmann wrote: > On Tue, Dec 30, 2025, at 08:10, Thomas Weißschuh wrote: > > > > /* entries in ARCH_DLINFO: */ > > -#if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64) > > +#if defined(__KERNEL__) && (defined(CONFIG_IA32_EMULATION) || > > !defined(CONFIG_X86_64)) > > # define AT_VECTOR_SIZE_ARCH 3 > > #else /* else it's non-compat x86-64 */ > > # define AT_VECTOR_SIZE_ARCH 2 > > While this patch clearly keeps the current behavior, I think it's > wrong, and 32-bit userspace should see a '3' instead of '2' here. > > It can probably just be '3' unconditionally, or we can > make it more complex and have a userspace definition based > on __x86_64__ being defined.
Does userspace even need to see this definition at all? This value only makes sense in combination with AT_VECTOR_SIZE_BASE which itself is not part of the UAPI. Debian codesearch did not bring up a user for it. Not even CRIU, as they use their own definitions. The value is wrong today on x86 and nobody seems to have noticed. (Based on both the kconfig variables and the vDSO cmdline switches). Also UML shares the same UAPI headers but in the kernel has its own ARCH_DLINFO, so the values is "wrong" there, too. > I also wonder if there is a problem with the third > x86-64 entry being zero rather than AT_IGNORE. I see that > some architectures do it like this, to keep the number constant > even if some entries are missing: > > if (likely(signal_minsigstksz)) \ > NEW_AUX_ENT(AT_MINSIGSTKSZ, signal_minsigstksz); \ > else \ > NEW_AUX_ENT(AT_IGNORE, 0); \ > > Arnd The whole AUX_ENT handling seems brittle and slighly broken. Many changes to AT_VECTOR_SIZE_BASE are done as fixes, as they were forgotten in the original changes to the process setup code. The addition of AT_HWCAP3/AT_HWCAP4 is still not reflected in AT_VECTOR_SIZE_BASE. (AT_HWCAP4 is never used anyways) Then the same logic is duplicated between binfmt_elf.c and binfmt_elf_fdpic.c, except that it is slightly different and the latter is missing some fields. We should deduplicate this code and find a way add a static assertion. Also space is wasted as more entries than possible are allocated in many cases. For example AT_BASE_PLATFORM and AT_RSEQ_*. And those are not stubbed out with AT_IGNORE either. So I'd like to keep my current patch as is, to reach my current goal of getting rid of kconfig leaks in the UAPI headers. In parallel we can remove AT_VECTOR_SIZE_ARCH from the UAPI and fix the auxiliary vector handling in two different patch series. Thomas _______________________________________________ linux-snps-arc mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-snps-arc
