linux-kernel - Re: [PATCH] x86/platform/uv: Dont use smp_processor

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]

Message-ID: <SJ1PR84MB3044E3A5C90662C2EF91A799E7D99@SJ1PR84MB3044.NAMPRD84.PROD.OUTLOOK.COM>
Date:   Thu, 26 May 2022 22:53:38 +0000
From:   "Travis, Mike" <mike.travis@....com>
To:     Dave Hansen <dave.hansen@...el.com>,
        Borislav Petkov <bp@...en8.de>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Wahl, Steve" <steve.wahl@....com>,
        "x86@...nel.org" <x86@...nel.org>
CC:     "Sivanich, Dimitri" <dimitri.sivanich@....com>,
        Andy Shevchenko <andy@...radead.org>,
        Darren Hart <dvhart@...radead.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Anderson, Russ" <russ.anderson@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>,
        "Travis, Mike" <mike.travis@....com>
Subject: Re: [PATCH] x86/platform/uv: Dont use smp_processor_id while
 preemptable

Dave Hansen <dave.hansen@...el.com> wrote:
  On 5/20/22 13:37, Mike Travis wrote:
  > To avoid a "BUG: using smp_processor_id() in preemptible" debug
  > warning message, disable preemption around use of the processor id.

>I'm sure this gets rid of the warning.  But, could you please take a
>quick look at the callers and ensure that they can handle if this read
>comes from another CPU?
>
>In other words, what would actually go wrong if uv_read_rtc() got
>preempted in this region?  What would this actually fix?

I talked with the author of this driver and among the preemption scenarios it always returns the same system time.  And due to the round robin aspect of the request scheduling, getting an earlier time when a second CPU reads it's time is not possible.  So getting rid of the debug warning message seems to be the only benefit from this patch.