Messages in this thread | | | Date | Wed, 26 Oct 2022 17:43:59 +0200 | From | "Arnd Bergmann" <> | Subject | Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks |
| |
On Tue, Oct 25, 2022, at 18:28, Maciej W. Rozycki wrote: > On Sun, 23 Oct 2022, Linus Torvalds wrote: > >> In fact, I don't understand how current kernels work on an i486 at >> all, since it looks like >> >> exit_to_user_mode_prepare -> >> arch_exit_to_user_mode_prepare >> >> ends up having an unconditional 'rdtsc' instruction in it. >> > > The fix here is obviously and trivially: > > select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET if !M486SX && !M486
I think that would be "if X86_TSC", otherwise you still include the TSC-less 586-class (5x86, 6x86, Elan, Winchip C6, MediaGX, ...)
> So what's the actual burden from keeping this support around? Would my > proposal to emulate CMPXCHG8B (and possibly RDTSC) in #UD handler help?
That sounds worse to me than the current use of runtime alternatives for picking between cmpxchg8b_emu and the native instruction.
For arm32, we have a combination of two other approaches:
- On the oldest processors that never had SMP support (ARMv5 and earlier), it is not possible to enable support for SMP at all. Using a Kconfig 'depends on X86_CMPXCHG64' for CONFIG_SMP would still allow building 486 kernels, but completely avoid the problem of trying to make the same kernel work on later SMP machines.
- For the special case of early ARMv6 hardware that has 32-bit atomics but not 64-bit ones, the kernel just falls back to CONFIG_GENERIC_ATOMIC64 and no cmpxchg64(). The same should work for an i486+SMP kernel. It's obviously slower, but most users can trivially avoid this by either running an i686 SMP kernel or an i486 UP kernel.
Arnd
| |