From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753514AbeAQOEr (ORCPT + 1 other); Wed, 17 Jan 2018 09:04:47 -0500 Received: from foss.arm.com ([217.140.101.70]:40998 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753051AbeAQOEp (ORCPT ); Wed, 17 Jan 2018 09:04:45 -0500 Subject: Re: [PATCH] arm64: Run enable method for errata work arounds on late CPUs To: Robin Murphy , Dave Martin Cc: Mark Rutland , catalin.marinas@arm.com, will.deacon@arm.com, linux-kernel@vger.kernel.org, Andre Przywara , linux-arm-kernel@lists.infradead.org References: <20180117100556.29270-1-suzuki.poulose@arm.com> <20180117122548.GE22781@e103592.cambridge.arm.com> <29147833-b47f-3ad9-e2d8-295551c43900@arm.com> From: Suzuki K Poulose Message-ID: <5d51dd4a-d985-22e5-6583-bcc4bfdf8e6f@arm.com> Date: Wed, 17 Jan 2018 14:04:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 17/01/18 13:43, Robin Murphy wrote: > On 17/01/18 13:31, Suzuki K Poulose wrote: >> On 17/01/18 13:20, Robin Murphy wrote: >>> On 17/01/18 12:25, Dave Martin wrote: >>>> On Wed, Jan 17, 2018 at 10:05:56AM +0000, Suzuki K Poulose wrote: >>>>> When a CPU is brought up after we have finalised the system >>>>> wide capabilities (i.e, features and errata), we make sure the >>>>> new CPU doesn't need a new errata work around which has not been >>>>> detected already. However we don't run enable() method on the new >>>>> CPU for the errata work arounds already detected. This could >>>>> cause the new CPU running without potential work arounds. >>>>> It is upto the "enable()" method to decide if this CPU should >>>>> do something about the errata. >>>>> >>>>> Fixes: commit 6a6efbb45b7d95c84 ("arm64: Verify CPU errata work arounds on hotplugged CPU") >>>>> Cc: Will Deacon >>>>> Cc: Mark Rutland >>>>> Cc: Andre Przywara >>>>> Cc: Catalin Marinas >>>>> Cc: Dave Martin >>>>> Signed-off-by: Suzuki K Poulose >>>>> --- >>>>>   arch/arm64/kernel/cpu_errata.c | 9 ++++++--- >>>>>   1 file changed, 6 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c >>>>> index 90a9e465339c..54e41dfe41f6 100644 >>>>> --- a/arch/arm64/kernel/cpu_errata.c >>>>> +++ b/arch/arm64/kernel/cpu_errata.c >>>>> @@ -373,15 +373,18 @@ void verify_local_cpu_errata_workarounds(void) >>>>>   { >>>>>       const struct arm64_cpu_capabilities *caps = arm64_errata; >>>>> -    for (; caps->matches; caps++) >>>>> -        if (!cpus_have_cap(caps->capability) && >>>>> -            caps->matches(caps, SCOPE_LOCAL_CPU)) { >>>>> +    for (; caps->matches; caps++) { >>>>> +        if (cpus_have_cap(caps->capability)) { >>>>> +            if (caps->enable) >>>>> +                caps->enable((void *)caps); >>>> >>>> Do we really need this cast? >>> >>> Seems to me like the prototype for .enable needs updating. If any existing callback was actually using the (non-const) void* for some purpose (thankfully nothing seems to be), then passing the capability pointer into that would be unlikely to end well anyway. >> >> I agree. This was initially written such that we could call it via on_each_cpu(). >> But then we later switched to stop_machine(). And we weren't using the argument until >> very recently with the introduction of multiple entries for the same capability. >> >> I will try to clean this up in a separate series, which would involve cleaning up >> all the enable(), quite invasive. I would like this to go in for 4.16, as it is>> needed for things like KPTI and some of the existing caps. Correction, s/KPTI/bp hardening/ > > OK, sounds good. For the sake of the immediate fix, perhaps it's cleaner to just pass NULL here if the current callbacks ignore it? As I said above, we have some users at the moment, so we cant do that. Suzuki