linux-kernel - Re: [clocksource] 8901ecc231: stress-ng.lockbus.ops_per

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]

Date:   Thu, 27 May 2021 12:19:23 -0700
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Andi Kleen <ak@...ux.intel.com>
Cc:     Feng Tang <feng.tang@...el.com>,
        kernel test robot <oliver.sang@...el.com>,
        John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Jonathan Corbet <corbet@....net>,
        Mark Rutland <Mark.Rutland@....com>,
        Marc Zyngier <maz@...nel.org>,
        Xing Zhengjun <zhengjun.xing@...ux.intel.com>,
        Chris Mason <clm@...com>, LKML <linux-kernel@...r.kernel.org>,
        Linux Memory Management List <linux-mm@...ck.org>,
        lkp@...ts.01.org, lkp@...el.com, ying.huang@...el.com,
        zhengjun.xing@...el.com
Subject: Re: [clocksource] 8901ecc231: stress-ng.lockbus.ops_per_sec -9.5%
 regression

On Thu, May 27, 2021 at 12:01:23PM -0700, Andi Kleen wrote:
> 
> >      Nevertheless, it is quite possible that real-world use will result in
> >      some situation requiring that high-stress workloads run on hardware
> >      not designed to accommodate them, and also requiring that the kernel
> >      refrain from marking clocksources unstable.
> >      Therefore, provide an out-of-tree patch that reacts to this situation
> 
> out-of-tree means it will not be submitted?
> 
> I think it would make sense upstream, but perhaps guarded with some option.

The reason I do not intend to immediately upstream this patch is that
it increases the probability that a real clocksource read-latency issue
will be ignored, for example, during hardware bringup.  Furthermore,
the only known need from it comes from hardware that is, in the words
of the stress-ng man page, "poorly designed".  And the timing of this
email thread leads me to believe that such hardware is not easy to obtain.

Adding an option would increase complexity, but I agree that such an
option would address some of the patch's downsides.  On the other hand,
there has been some pushback to such options.

My thought is therefore to keep this patch out of tree for now.
If it becomes clear that long-latency clocksource reads really are
a significant issue in their own right (as opposed to merely being a
symptom of a hardware or firmware bug), then this patch is available to
immediately respond to that issue.

And there would then be strong evidence in favor of me biting the bullet,
adding the complexity and the additional option (with your Suggested-by),
and getting that upstream and into -stable.

Seem reasonable?

							Thanx, Paul