Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Feedback-ID: i56a14606:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-1087-g968661d8e1-fm-20221021.001-g968661d8
Mime-Version: 1.0
Message-Id: <d24a5273-1c66-4653-9730-4de31ffcf0e8@app.fastmail.com>
In-Reply-To: <alpine.DEB.2.21.2210240054280.50489@angie.orcam.me.uk>
References: <20220815071332.627393-1-yuzhao@google.com>
 <20220815071332.627393-9-yuzhao@google.com>
 <Y0go8wWtdcyH1+Ch@hirez.programming.kicks-ass.net>
 <CAOUHufa9+FTO3Pv-5jC-e3S5goPsUGu-5KcPVHa4bWb0X+d2ug@mail.gmail.com>
 <CAHk-=wj1rc2t5noMtVOgu8XXeTM4KiggEub9PdcexxeQrYPZvA@mail.gmail.com>
 <Y1FXpHdyvXjrjbLw@hirez.programming.kicks-ass.net>
 <CAHk-=whQchubuDpRGFabhmcZuzdt13OOF8wznXb+Dbi3GzBQhQ@mail.gmail.com>
 <Y1GZjPO+szk7X0wP@hirez.programming.kicks-ass.net>
 <CAHk-=wikUaRM5H_y1Bc+QyvGi40dKDL8fnCTyz7ECbwK7aHNPQ@mail.gmail.com>
 <Y1IUMDJFScAMrCS5@casper.infradead.org>
 <CAHk-=wjrpH1+6cQQjTO6p-96ndBMiOnNH098vhS2jLybxD+7gA@mail.gmail.com>
 <alpine.DEB.2.21.2210211911390.50489@angie.orcam.me.uk>
 <CAHk-=wgNZNNd4t004x0ehXm=DA+JmYY=0MgVNDXUtoV4ApyXvQ@mail.gmail.com>
 <alpine.DEB.2.21.2210240054280.50489@angie.orcam.me.uk>
Date:   Wed, 26 Oct 2022 17:43:59 +0200
From:   "Arnd Bergmann" <arnd@arndb.de>
To:     "Maciej W. Rozycki" <macro@orcam.me.uk>,
        "Linus Torvalds" <torvalds@linux-foundation.org>
Cc:     "Matthew Wilcox" <willy@infradead.org>,
        "Peter Zijlstra" <peterz@infradead.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        "Yu Zhao" <yuzhao@google.com>,
        "Andrew Morton" <akpm@linux-foundation.org>,
        "Andi Kleen" <ak@linux.intel.com>,
        "Aneesh Kumar" <aneesh.kumar@linux.ibm.com>,
        "Catalin Marinas" <catalin.marinas@arm.com>,
        "Dave Hansen" <dave.hansen@linux.intel.com>,
        "Hillf Danton" <hdanton@sina.com>, "Jens Axboe" <axboe@kernel.dk>,
        "Johannes Weiner" <hannes@cmpxchg.org>,
        "Jonathan Corbet" <corbet@lwn.net>, "Mel Gorman" <mgorman@suse.de>,
        "Michael Larabel" <Michael@michaellarabel.com>,
        "Michal Hocko" <mhocko@kernel.org>,
        "Mike Rapoport" <rppt@kernel.org>, "Tejun Heo" <tj@kernel.org>,
        "Vlastimil Babka" <vbabka@suse.cz>,
        "Will Deacon" <will@kernel.org>,
        linux-arm-kernel@lists.infradead.org, linux-doc@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-mm@kvack.org,
        page-reclaim@google.com, "Brian Geffon" <bgeffon@google.com>,
        "Jan Alexander Steffens" <heftig@archlinux.org>,
        "Oleksandr Natalenko" <oleksandr@natalenko.name>,
        "Steven Barrett" <steven@liquorix.net>,
        "Suleiman Souhlal" <suleiman@google.com>,
        "Daniel Byrne" <djbyrne@mtu.edu>,
        "Donald Carr" <d@chaos-reins.com>,
        =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= <holger@applied-asynchrony.com>,
        "Konstantin Kharlamov" <Hi-Angel@yandex.ru>,
        "Shuang Zhai" <szhai2@cs.rochester.edu>,
        "Sofia Trinh" <sofia.trinh@edi.works>,
        "Vaibhav Jain" <vaibhav@linux.ibm.com>
Subject: Re: [PATCH v14 08/14] mm: multi-gen LRU: support page table walks
Content-Type: text/plain
Precedence: bulk

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