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: <ede5405d-55f4-e1ea-23ef-56303cbfa411@redhat.com>
Date:   Wed, 17 Nov 2021 16:55:45 -0500
From:   Waiman Long <longman@...hat.com>
To:     paulmck@...nel.org
Cc:     John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        Feng Tang <feng.tang@...el.com>, linux-kernel@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Cassio Neri <cassio.neri@...il.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Frederic Weisbecker <frederic@...nel.org>
Subject: Re: [PATCH v2 0/4] clocksource: Avoid incorrect hpet fallback


On 11/17/21 16:25, Paul E. McKenney wrote:
> On Wed, Nov 17, 2021 at 01:51:51PM -0500, Waiman Long wrote:
>> On 11/17/21 11:54, Paul E. McKenney wrote:
>>> On Tue, Nov 16, 2021 at 06:44:22PM -0500, Waiman Long wrote:
>>> A few questions:
>>>
>>> 1.	Once you have all the patches in place, is the increase in
>>> 	WATCHDOG_MAX_SKEW from 50us to 100us necessary?
>> I think so. Using Feng's reproducer, I was able to cause a hpet-hpet delay
>> of more than 90us on a 1-socket system. With a default 50us
>> WATCHDOG_MAX_SKEW, the chance of a warning showing up will be much higher.
>> Trying to minimize the chance that a warning may appear is my primary reason
>> to increase WATCHDOG_MAX_SKEW.
> Should we downgrade the "had to retry read" complain to pr_info(),
> and make the only real warning be the case where a large number of
> consecutive read attempts fail?  I believe that Heiner Kallweit was
> looking for something like this.
Sure. I will downgrade it to pr_info().
>
>>> 2.	The reason for having cs->uncertainty_margin set to
>>> 	2*WATCHDOG_MAX_SKEW was to allow for worst-case skew from both
>>> 	the previous and the current reading.  Are you sure that
>>> 	dropping back to WATCHDOG_MAX_SKEW avoids false positives?
>> I can remove the hunk of changing cs->uncertainty_margin. It is critical for
>> this patch.
> Assuming "not critical", good!

Yes, it is "not critical". Somehow I missed the "not" :-)

Cheers,
Longman

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ