linux-kernel - Re: [PATCH v3 3/4] clocksource: Dynamically increase watchdog_max

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]

Message-ID: <e0a41ba0-59d6-d320-02b0-37534f9e66a5@redhat.com>
Date:   Mon, 22 Nov 2021 13:27:25 -0500
From:   Waiman Long <longman@...hat.com>
To:     Feng Tang <feng.tang@...el.com>
Cc:     John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        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 v3 3/4] clocksource: Dynamically increase
 watchdog_max_skew


On 11/22/21 00:02, Feng Tang wrote:
> On Thu, Nov 18, 2021 at 02:14:38PM -0500, Waiman Long wrote:
>> It is possible that a long-lasting intensive workload running on
>> a system may cause the clock skew test to be skipped for extended
>> period of time. One way to avoid this is to dynamically increase the
>> watchdog_max_skew used in the clock skew test.
>>
>> However, we also don't want watchdog_max_skew to be continuously increased
>> without bound. So we limit the increase up to 10*WATCHDOG_MAX_SKEW. If
>> that happens, there is something wrong the current watchdog and we are
>> going to mark it as unstable and select a new watchdog, if possible.
>   
> For reselecting watchdog, in these cases, I think it's the extreme system
> stress causing the MMIO read of hpet to be slow (plus some lock), fallback
> to other watchdog whose read is MMIO or ioport may not help much. I tried
> this patch, and when "acpi_pm" timer is used instead of "hpet", similar
> thing can still happen.

Yes, I am aware of that. Switching to acpi_pm, did not reduce the 
consecutive read delay. However, the current limit for this watchdog 
fallback is when the delay exceed 5*WATCHDOG_MAX_SKEW. With a default of 
100us, that mean 500us which is a really large delay that maybe there is 
something wrong with the hpet timer. Of course, the selection of this 
limit is kind of arbitrary. If you have concern about that, we can leave 
this patch out.

Cheers,
Longman