linux-kernel - Re: [PATCH] LoongArch: Fix the !CONFIG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Aug 2022 07:56:33 +0100
From:   Marc Zyngier <maz@...nel.org>
To:     WANG Xuerui <kernel@...0n.name>
Cc:     Huacai Chen <chenhuacai@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Thomas Gleixner <tglx@...utronix.de>,
        loongarch@...ts.linux.dev, Xuefeng Li <lixuefeng@...ngson.cn>,
        Guo Ren <guoren@...nel.org>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] LoongArch: Fix the !CONFIG_SMP build for irqchip drivers

On Thu, 11 Aug 2022 01:58:15 +0100,
WANG Xuerui <kernel@...0n.name> wrote:
> 
> On 8/10/22 23:38, Huacai Chen wrote:
> 
> > Hi, Marc,
> > 
> > On Wed, Aug 10, 2022 at 7:01 PM Marc Zyngier <maz@...nel.org> wrote:
> >> On 2022-08-10 11:31, Huacai Chen wrote:
> >>> 1, Guard get_ipi_irq() in CONFIG_SMP;
> >>> 2, Define cpu_logical_map() for the EIOINTC driver;
> >>> 3, Make eiointc_set_irq_affinity() return early for !CONFIG_SMP.
> >>> 
> >>> Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> >> Frankly, the real question is why do you even bother? As far as
> >> I can tell, LoongArch has no UP system.
> >> 
> >> arm64 crossed that bridge a long time ago, and we never looked
> >> back, because these systems hardly exist.
> >> 
> >> I'd rather you simply have a CONFIG_SMP always set to 'y', and
> >> be done with it forever.
> > LoongArch also has low-end processors (even LoongArch64). Though we
> > haven't translate all documents at
> > https://loongson.github.io/LoongArch-Documentation/ in time, there are
> > currently 4 LoongArch64 processors: Loongson-2K500 (single-core),
> > Loongon-2K1000 (dual-core), Loongson-3A5000 (quad-core) and
> > Loongson-3C5000 (16-core). So we indeed need a UP configuration.
> > Thanks.
> 
> I remember seeing an alternatives mechanism in the works for
> LoongArch. If such alternatives mechanism is to be upstreamed in short
> order, why make SMP one more build-time time option that developers
> have to decide upon? It's not like SMP code would break, or run with
> unacceptable overhead, on UP systems AFAIK, so it's probably better to
> not preemptively support so many *possibilities* that haven't been
> realized so the *current* maintainability suffers. Practically one
> can't buy the LoongArch 2K line of products anywhere right now, and
> the few companies developing for it are likely not using upstream
> kernels anyway, so it's not like we can't wait either.

And that's exactly my point. Yes, it is always possible to build a UP
system. But is it worth *maintaining* a configuration option for this?
I seriously doubt it.

My advise is to stick to SMP only for now (it will run just fine on a
UP machine), and only if upstream users find it completely
unacceptable should a !SMP option be introduced, or make it a runtime
decision (32bit ARM has had SMP_ON_UP support for a long time).

	M.

-- 
Without deviation from the norm, progress is not possible.