linux-kernel - RE: [PATCH v2] RISC-V: Probe misaligned access speed in parallel

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]

Message-ID: <a94490f6b1dd43d5985a8b14aa93bd27@AcuMS.aculab.com>
Date:   Thu, 21 Sep 2023 10:22:21 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Evan Green' <evan@...osinc.com>,
        Atish Patra <atishp@...shpatra.org>
CC:     Conor Dooley <conor@...nel.org>,
        Anup Patel <apatel@...tanamicro.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Heiko Stuebner <heiko@...ech.de>,
        "Marc Zyngier" <maz@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Palmer Dabbelt <palmer@...osinc.com>,
        "Conor Dooley" <conor.dooley@...rochip.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Jisheng Zhang <jszhang@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Greentime Hu <greentime.hu@...ive.com>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Andrew Jones <ajones@...tanamicro.com>
Subject: RE: [PATCH v2] RISC-V: Probe misaligned access speed in parallel

...
> > For probing alignment speed, you just care about running it on that
> > cpu. Correct ?
> 
> For this we care both about not migrating to other CPUs, and also
> secondarily minimizing disturbances while the test is being run.
> Usually I equate pre-emption with migration, but in this case I think
> the worker threads are bound to that CPU. So I'll keep the
> preempt_disable/enable where it is, since it's harmless for CPUs other
> than 0, but useful for 0. I also like it for readability as it
> highlights the critical section (as a reader, "is preemption disabled"
> would be one of my first questions when studying this).

You need to disable pre-emption to get any kind of meaningful answer.

But why do you need to run the test on more than the boot cpu?
If you've a heterogenous mix of cpu any code that looks at the answer
is going to behave incorrectly unless it has also disabled pre-emption
or is bound to a cpu.

One obvious use of the result is to setup some static branches.
But that assumes all cpu are the same.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)