linux-kernel - Re: [PATCH v2 1/2] RISC-V: hwprobe: Add MISALIGNED

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] [day] [month] [year] [list]

Date: Wed, 26 Jun 2024 08:55:33 -0700
From: Evan Green <evan@...osinc.com>
To: Conor Dooley <conor@...nel.org>
Cc: Palmer Dabbelt <palmer@...belt.com>, Yangyu Chen <cyy@...self.name>, 
	Charlie Jenkins <charlie@...osinc.com>, Andrew Jones <ajones@...tanamicro.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Andy Chiu <andy.chiu@...ive.com>, 
	Clément Léger <cleger@...osinc.com>, 
	Conor Dooley <conor.dooley@...rochip.com>, Costa Shulyupin <costa.shul@...hat.com>, 
	Jonathan Corbet <corbet@....net>, Paul Walmsley <paul.walmsley@...ive.com>, linux-doc@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 1/2] RISC-V: hwprobe: Add MISALIGNED_PERF key

On Wed, Jun 26, 2024 at 7:36 AM Conor Dooley <conor@...nel.org> wrote:
>
> On Tue, Jun 25, 2024 at 09:51:20AM -0700, Evan Green wrote:
> > RISCV_HWPROBE_KEY_CPUPERF_0 was mistakenly flagged as a bitmask in
> > hwprobe_key_is_bitmask(), when in reality it was an enum value. This
> > causes problems when used in conjunction with RISCV_HWPROBE_WHICH_CPUS,
> > since SLOW, FAST, and EMULATED have values whose bits overlap with
> > each other. If the caller asked for the set of CPUs that was SLOW or
> > EMULATED, the returned set would also include CPUs that were FAST.
> >
> > Introduce a new hwprobe key, RISCV_HWPROBE_KEY_MISALIGNED_PERF, which
> > returns the same values in response to a direct query (with no flags),
> > but is properly handled as an enumerated value. As a result, SLOW,
> > FAST, and EMULATED are all correctly treated as distinct values under
> > the new key when queried with the WHICH_CPUS flag.
> >
> > Leave the old key in place to avoid disturbing applications which may
> > have already come to rely on the key, with or without its broken
> > behavior with respect to the WHICH_CPUS flag.
> >
> > Fixes: e178bf146e4b ("RISC-V: hwprobe: Introduce which-cpus flag")
> > Signed-off-by: Evan Green <evan@...osinc.com>
> > Reviewed-by: Charlie Jenkins <charlie@...osinc.com>
> > Reviewed-by: Andrew Jones <ajones@...tanamicro.com>
> >
> > ---
> >
> > Changes in v2:
> >  - Clarified the distinction of slow and fast refers to misaligned word
> >    accesses. Previously it just said misaligned accesses, leaving it
> >    ambiguous as to which type of access was measured.
>
> I think if we are gonna be specific, we should be exactly specific as to
> what we have tested and say 32-bit if that's what we're probing/testing
> with. That'd be consistent with jesse's proposed wording for vector.

Sure. In this case it's really native word sized accesses. So something like:

* :c:macro:`RISCV_HWPROBE_KEY_MISALIGNED_SCALAR_PERF`: An enum value describing
the performance of misaligned scalar native word accesses on the selected set
of processors.

...

* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_SLOW`: Misaligned native word
sized accesses are slower than the equivalent quantity of byte accesses.
Misaligned accesses may be supported directly in hardware, or trapped and
emulated by software.

* :c:macro:`RISCV_HWPROBE_MISALIGNED_SCALAR_FAST`: Misaligned native word
sized accesses are faster than the equivalent quantity of byte accesses.

I'm planning to leave the qualifiers off of UNKNOWN, EMULATED, and
UNSUPPORTED, as those likely apply to misaligned accesses of any size.
Let me know if you think we should tweak it further.
-Evan