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: <alpine.DEB.2.21.2406210041140.43454@angie.orcam.me.uk>
Date: Fri, 21 Jun 2024 01:00:04 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Jiaxun Yang <jiaxun.yang@...goat.com>
cc: Thomas Bogendoerfer <tsbogend@...ha.franken.de>, 
    Jonas Gorski <jonas.gorski@...il.com>, linux-mips@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/4] MIPS: Introduce config options for LLSC
 availability

On Wed, 12 Jun 2024, Jiaxun Yang wrote:

> Introduce CPU_HAS_LLSC and CPU_MAY_HAVE_LLSC to determine availability
> of LLSC and Kconfig level.

 Taking the subsequent patches in this series into account this seems to 
create a parallel universe in which the availability of LL/SC for certain 
features is handled at the Kconfig level while in the other universe it's 
handled via <asm/mach-*/cpu-feature-overrides.h>.

 I think this ought not to be done in two places independently and the 
pieces in <asm/mach-*/cpu-feature-overrides.h> need to be removed, likely 
in the same change even, *however* not without double-checking whether 
there is not a case among them where a platform actually has LL/SC support 
disabled despite the CPU used there having architectural support for the 
feature.  Otherwise we may end up with a case where a platform has LL/SC 
support disabled via its <asm/mach-*/cpu-feature-overrides.h> setting and 
yet we enable ARCH_SUPPORTS_ATOMIC_RMW or ARCH_HAVE_NMI_SAFE_CMPXCHG for 
it via Kconfig.

 The note from <asm/mach-ip32/cpu-feature-overrides.h> seems a candidate 
to move to arch/mips/Kconfig at the relevant place on this occasion too.
There may be more such notes and they ought not to be lost.

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ