lkml.org 
[lkml]   [2022]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2022-10-26 17:45    [W:0.330 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site