linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [GIT PULL] RISC-V Fixes for 5.7-rc5
@ 2020-05-08 18:47 Palmer Dabbelt
  2020-05-09 23:26 ` Linus Torvalds
  2020-05-09 23:30 ` pr-tracker-bot
  0 siblings, 2 replies; 7+ messages in thread
From: Palmer Dabbelt @ 2020-05-08 18:47 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: linux-riscv, linux-kernel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
  2020-05-08 18:47 [GIT PULL] RISC-V Fixes for 5.7-rc5 Palmer Dabbelt
@ 2020-05-09 23:26 ` Linus Torvalds
  2020-05-11  8:13   ` Andreas Schwab
  2020-05-09 23:30 ` pr-tracker-bot
  1 sibling, 1 reply; 7+ messages in thread
From: Linus Torvalds @ 2020-05-09 23:26 UTC (permalink / raw)
  To: Palmer Dabbelt, Andreas Schwab; +Cc: linux-riscv, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
  2020-05-08 18:47 [GIT PULL] RISC-V Fixes for 5.7-rc5 Palmer Dabbelt
  2020-05-09 23:26 ` Linus Torvalds
@ 2020-05-09 23:30 ` pr-tracker-bot
  1 sibling, 0 replies; 7+ messages in thread
From: pr-tracker-bot @ 2020-05-09 23:30 UTC (permalink / raw)
  To: Palmer Dabbelt; +Cc: Linus Torvalds, linux-riscv, linux-kernel

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!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
  2020-05-09 23:26 ` Linus Torvalds
@ 2020-05-11  8:13   ` Andreas Schwab
  2020-05-11 19:04     ` Linus Torvalds
  0 siblings, 1 reply; 7+ messages in thread
From: Andreas Schwab @ 2020-05-11  8:13 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Palmer Dabbelt, linux-riscv, Linux Kernel Mailing List

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.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
  2020-05-11  8:13   ` Andreas Schwab
@ 2020-05-11 19:04     ` Linus Torvalds
  2020-05-11 22:02       ` Palmer Dabbelt
  2020-05-12  8:53       ` Andreas Schwab
  0 siblings, 2 replies; 7+ messages in thread
From: Linus Torvalds @ 2020-05-11 19:04 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Palmer Dabbelt, linux-riscv, Linux Kernel Mailing List

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
  2020-05-11 19:04     ` Linus Torvalds
@ 2020-05-11 22:02       ` Palmer Dabbelt
  2020-05-12  8:53       ` Andreas Schwab
  1 sibling, 0 replies; 7+ messages in thread
From: Palmer Dabbelt @ 2020-05-11 22:02 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: schwab, linux-riscv, linux-kernel

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
  2020-05-11 19:04     ` Linus Torvalds
  2020-05-11 22:02       ` Palmer Dabbelt
@ 2020-05-12  8:53       ` Andreas Schwab
  1 sibling, 0 replies; 7+ messages in thread
From: Andreas Schwab @ 2020-05-12  8:53 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Palmer Dabbelt, linux-riscv, Linux Kernel Mailing List

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.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-05-12  8:53 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-08 18:47 [GIT PULL] RISC-V Fixes for 5.7-rc5 Palmer Dabbelt
2020-05-09 23:26 ` Linus Torvalds
2020-05-11  8:13   ` Andreas Schwab
2020-05-11 19:04     ` Linus Torvalds
2020-05-11 22:02       ` Palmer Dabbelt
2020-05-12  8:53       ` Andreas Schwab
2020-05-09 23:30 ` pr-tracker-bot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).