[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200908074059.GA14790@willie-the-truck>
Date: Tue, 8 Sep 2020 08:41:01 +0100
From: Will Deacon <will@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org, catalin.marinas@....com,
Mark Brown <broonie@...nel.org>,
Dave Martin <Dave.Martin@....com>,
Ard Biesheuvel <ardb@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Suzuki K Poulose <suzuki.poulose@....com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3] arm64/cpuinfo: Define HWCAP name arrays per their
actual bit definitions
On Tue, Sep 08, 2020 at 10:43:12AM +0530, Anshuman Khandual wrote:
>
>
> On 09/07/2020 05:46 PM, Will Deacon wrote:
> > On Mon, Aug 17, 2020 at 05:34:23PM +0530, Anshuman Khandual wrote:
> >> HWCAP name arrays (hwcap_str, compat_hwcap_str, compat_hwcap2_str) that are
> >> scanned for /proc/cpuinfo are detached from their bit definitions making it
> >> vulnerable and difficult to correlate. It is also bit problematic because
> >> during /proc/cpuinfo dump these arrays get traversed sequentially assuming
> >> they reflect and match actual HWCAP bit sequence, to test various features
> >> for a given CPU. This redefines name arrays per their HWCAP bit definitions
> >> . It also warns after detecting any feature which is not expected on arm64.
> >>
> >> Cc: Catalin Marinas <catalin.marinas@....com>
> >> Cc: Will Deacon <will@...nel.org>
> >> Cc: Mark Brown <broonie@...nel.org>
> >> Cc: Dave Martin <Dave.Martin@....com>
> >> Cc: Ard Biesheuvel <ardb@...nel.org>
> >> Cc: Mark Rutland <mark.rutland@....com>
> >> Cc: Suzuki K Poulose <suzuki.poulose@....com>
> >> Cc: linux-arm-kernel@...ts.infradead.org
> >> Cc: linux-kernel@...r.kernel.org
> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@....com>
> >> ---
> >> This applies on 5.9-rc1
> >>
> >> Mark, since the patch has changed I have dropped your Acked-by: tag. Are you
> >> happy to give a new one ?
> >>
> >> Changes in V3:
> >>
> >> - Moved name arrays to (arch/arm64/kernel/cpuinfo.c) to prevent a build warning
> >> - Replaced string values with NULL for all compat features not possible on arm64
> >> - Changed compat_hwcap_str[] iteration on size as some NULL values are expected
> >> - Warn once after detecting any feature on arm64 that is not expected
> >>
> >> Changes in V2: (https://patchwork.kernel.org/patch/11533755/)
> >>
> >> - Defined COMPAT_KERNEL_HWCAP[2] and updated the name arrays per Mark
> >> - Updated the commit message as required
> >>
> >> Changes in V1: (https://patchwork.kernel.org/patch/11532945/)
> >>
> >> arch/arm64/include/asm/hwcap.h | 9 +++
> >> arch/arm64/kernel/cpuinfo.c | 172 ++++++++++++++++++++++-------------------
> >> 2 files changed, 100 insertions(+), 81 deletions(-)
> >
> > [...]
> >
> >> + [KERNEL_HWCAP_FP] = "fp",
> >> + [KERNEL_HWCAP_ASIMD] = "asimd",
> >> + [KERNEL_HWCAP_EVTSTRM] = "evtstrm",
> >> + [KERNEL_HWCAP_AES] = "aes",
> >
> > It would be nice if the cap and the string were generated by the same
> > macro, along the lines of:
> >
> > #define KERNEL_HWCAP(c) [KERNEL_HWCAP_##c] = #c,
> >
> > Does making the constants mixed case break anything, or is it just really
> > churny to do?
>
> Currently all existing HWCAP feature strings are lower case, above change
> will make them into upper case instead. I could not find a method to force
> convert #c into lower case constant strings in the macro definition. Would
> not changing the HWCAP string case here, break user interface ?
Yes, we can't change the user-visible strings, but what's wrong with
having e.g. KERNEL_HWCAP_fp instead of KERNEL_HWCAP_FP?
Will
Powered by blists - more mailing lists