linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	catalin.marinas@arm.com, linux-kernel@vger.kernel.org,
	Ard Biesheuvel <ardb@kernel.org>, Mark Brown <broonie@kernel.org>,
	Dave Martin <Dave.Martin@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V3] arm64/cpuinfo: Define HWCAP name arrays per their actual bit definitions
Date: Tue, 8 Sep 2020 13:41:46 +0530	[thread overview]
Message-ID: <2daa3ea9-b9f0-3549-6458-158410576dff@arm.com> (raw)
In-Reply-To: <20200908074059.GA14790@willie-the-truck>



On 09/08/2020 01:11 PM, Will Deacon wrote:
> 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@arm.com>
>>>> Cc: Will Deacon <will@kernel.org>
>>>> Cc: Mark Brown <broonie@kernel.org>
>>>> Cc: Dave Martin <Dave.Martin@arm.com>
>>>> Cc: Ard Biesheuvel <ardb@kernel.org>
>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>>>> Cc: linux-arm-kernel@lists.infradead.org
>>>> Cc: linux-kernel@vger.kernel.org
>>>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.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?

Unlike the new compat macros i.e COMPAT_KERNEL_HWCAP[2] in this patch,
KERNEL_HWCAP_XXX macros are already defined and are getting used else
where (arch/arm64/kernel/cpufeature.c) as well. [KERNEL_HWCAP_##c] can
only be used here, if the input string is in upper case. Otherwise all
these existing macros need to be changed first, which will result in
too much code churn.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

      reply	other threads:[~2020-09-08  8:13 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17 12:04 [PATCH V3] arm64/cpuinfo: Define HWCAP name arrays per their actual bit definitions Anshuman Khandual
2020-09-07 12:16 ` Will Deacon
2020-09-08  5:13   ` Anshuman Khandual
2020-09-08  7:41     ` Will Deacon
2020-09-08  8:11       ` Anshuman Khandual [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2daa3ea9-b9f0-3549-6458-158410576dff@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=Dave.Martin@arm.com \
    --cc=ardb@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).