| Message ID | mhng-81c83c19-6f5d-4ed1-a0bb-26accf4b7d3a@palmerdabbelt-glaptop1 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [GIT,PULL] RISC-V Fixes for 5.7-rc5 | expand |
On Fri, May 8, 2020 at 11:47 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > * Adding a note to the VDSO so glibc can check the kernel's version without a > uname(). Eww. I realize other architectures do this, but why add it to new architectures? glibc depending on kernel version is WRONG. It's bogus. You can't do feature detection based on kernel version, it's fundamentally broken. So I really would prefer to see glibc fixed not to do that stupid thing, instead of adding pointless vdso notes to the kernel. Andreas? Why does glibc care about that ELF note? Linus
The pull request you sent on Fri, 08 May 2020 11:47:13 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv-for-linus-5.7-rc5
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e28f3b13a41b8a7d36a73ddf4bb41972a9c1dd9
Thank you!
On Mai 09 2020, Linus Torvalds wrote: > glibc depending on kernel version is WRONG. It's bogus. You can't do > feature detection based on kernel version, it's fundamentally broken. > > So I really would prefer to see glibc fixed not to do that stupid > thing, instead of adding pointless vdso notes to the kernel. I'm not aware of any discussion or bug report on this issue. Any pointer? Andreas.
On Mon, May 11, 2020 at 1:13 AM Andreas Schwab <schwab@suse.de> wrote: > > On Mai 09 2020, Linus Torvalds wrote: > > > glibc depending on kernel version is WRONG. It's bogus. You can't do > > feature detection based on kernel version, it's fundamentally broken. > > > > So I really would prefer to see glibc fixed not to do that stupid > > thing, instead of adding pointless vdso notes to the kernel. > > I'm not aware of any discussion or bug report on this issue. Any > pointer? We've discussed it informally several times, but that really is just "I remember mentioning this before" than anything else. Basically, testing kernel versions is pretty much always a bug. You _will_ get it wrong, sometimes spectacularly (we've had programs literally break when the major number changed, because they only checked the minor number). Other times you'll get it wrong in subtler ways - testing for features by version number is wrong, if that feature is then disabled by a config option (a lot of new kernel features work that way). Or, the already mentioned "distros often port back features to their older kernels". The latest example of that is Wireguard being ported back to Ubuntu 20.04 - using kernel version 5.4, even though WG was actually upstreamed in 5.6. So the whole "look at kernel version to determine if it does X" is simply fundamentally wrong. Why is glibc doing it in the first place? Is it some historical thing that is simply irrelevant on RISC-V simply because RISC-V doesn't have that kind of history, perhaps? Linus
On Mon, 11 May 2020 12:04:09 PDT (-0700), Linus Torvalds wrote: > On Mon, May 11, 2020 at 1:13 AM Andreas Schwab <schwab@suse.de> wrote: >> >> On Mai 09 2020, Linus Torvalds wrote: >> >> > glibc depending on kernel version is WRONG. It's bogus. You can't do >> > feature detection based on kernel version, it's fundamentally broken. >> > >> > So I really would prefer to see glibc fixed not to do that stupid >> > thing, instead of adding pointless vdso notes to the kernel. >> >> I'm not aware of any discussion or bug report on this issue. Any >> pointer? > > We've discussed it informally several times, but that really is just > "I remember mentioning this before" than anything else. > > Basically, testing kernel versions is pretty much always a bug. You > _will_ get it wrong, sometimes spectacularly (we've had programs > literally break when the major number changed, because they only > checked the minor number). > > Other times you'll get it wrong in subtler ways - testing for features > by version number is wrong, if that feature is then disabled by a > config option (a lot of new kernel features work that way). > > Or, the already mentioned "distros often port back features to their > older kernels". The latest example of that is Wireguard being ported > back to Ubuntu 20.04 - using kernel version 5.4, even though WG was > actually upstreamed in 5.6. > > So the whole "look at kernel version to determine if it does X" is > simply fundamentally wrong. > > Why is glibc doing it in the first place? Is it some historical thing > that is simply irrelevant on RISC-V simply because RISC-V doesn't have > that kind of history, perhaps? I don't know if Andreas had something else in mind, but there's actually a RISC-V specific reason we _do_ need this: the 64-bit time_t conversion. Essentially what happened is that I screwed up by merging the rv32 Linux port before the rv32 glibc port. As part of the rv32 upstreaming process we realized that it would be better in the long term to just drop the 32-bit time_t support from the kernel, but at that point we already had the Linux UABI defined. We ended up changing the user ABI on 32-bit systems as of d4c08b9776b3 ("riscv: Use latest system call ABI"). We didn't have any rv32 userspace at that time (and we still don't have glibc or any Linux capable hardware), so we figured it would be OK to break the rules and change the ABI. The obvious result is that 32-bit userspace won't work with old kernels, so I'd assumed this was being used to quickly sanity check the kernel. Andreas would know better than I do, though, as I don't really do much glibc stuff any more. > > Linus
On Mai 11 2020, Linus Torvalds wrote: > Why is glibc doing it in the first place? Is it some historical thing > that is simply irrelevant on RISC-V simply because RISC-V doesn't have > that kind of history, perhaps? It is completely generic. Even new architectures become old over time and accumulate cruft. The idea is that if you configure glibc with --enable-kernel=VERSION, it assumes that all syscalls from kernel VERSION are guaranteed to exist, and drops the fallbacks for those syscalls, or uses them in the first place (if no useful fallback existed). From time to time the absolute minimum supported kernel version is increased (this happend the last time in 2017, when x86 and x86_64 moved the mininum from 2.6.32 to 3.2, after all other architectures did that step in 2016), which allows removing the fallback code that becomes obsolete. Andreas.
merged tag 'riscv-for-linus-5.7-rc4' The following changes since commit 1d2cc5ac6f6668cc15216d51051103c61467d7e8: Merge tag 'riscv-for-linus-5.7-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux (2020-04-29 09:25:32 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git tags/riscv-for-linus-5.7-rc5 for you to fetch changes up to 73cb8e2a5863ccc5215660f5123db621bd57dff7: RISC-V: Remove unused code from STRICT_KERNEL_RWX (2020-05-05 17:02:14 -0700) ---------------------------------------------------------------- RISC-V Fixes for 5.7-rc5 This contains a smattering of fixes and cleanups that I'd like to target for 5.7: * Dead code removal. * Exporting riscv_cpuid_to_hartid_mask for modules. * Per-CPU tracking of ISA features. * Setting max_pfn correctly when probing memory. * Adding a note to the VDSO so glibc can check the kernel's version without a uname(). * A fix to force the bootloader to initialize the boot spin tables, which still get used as a fallback when SBI-0.1 is enabled. ---------------------------------------------------------------- Andreas Schwab (1): riscv: add Linux note to vdso Anup Patel (3): RISC-V: Export riscv_cpuid_to_hartid_mask() API RISC-V: Add bitmap reprensenting ISA features common across CPUs RISC-V: Remove N-extension related defines Atish Patra (1): RISC-V: Remove unused code from STRICT_KERNEL_RWX Vincent Chen (1): riscv: set max_pfn to the PFN of the last page Zong Li (1): riscv: force __cpu_up_ variables to put in data section arch/riscv/include/asm/csr.h | 3 -- arch/riscv/include/asm/hwcap.h | 22 ++++++++++ arch/riscv/include/asm/set_memory.h | 8 ---- arch/riscv/kernel/cpu_ops.c | 4 +- arch/riscv/kernel/cpufeature.c | 83 +++++++++++++++++++++++++++++++++++-- arch/riscv/kernel/smp.c | 2 + arch/riscv/kernel/vdso/Makefile | 2 +- arch/riscv/kernel/vdso/note.S | 12 ++++++ arch/riscv/mm/init.c | 19 +-------- 9 files changed, 121 insertions(+), 34 deletions(-) create mode 100644 arch/riscv/kernel/vdso/note.S