linux-kernel - Upper bound mode for kernel timers

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-next>] [day] [month] [year] [list]

Message-ID: <20210302001054.4qgrvnkltvkgikzr@treble>
Date:   Mon, 1 Mar 2021 18:10:54 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Artem Savkov <asavkov@...hat.com>, linux-kernel@...r.kernel.org,
        Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Upper bound mode for kernel timers

Hi Thomas,

As discussed on IRC:

We had a report of a regression in the TCP keepalive timer.  The user
had a 3600s keepalive timer for preventing firewall disconnects (on a
3650s interval).  They observed keepalive timers coming in up to four
minutes late, causing unexpected disconnects.

The regression was observed to have come from the timer wheel rewrite
from almost five years ago:

  500462a9de65 ("timers: Switch to a non-cascading wheel")

As you mentioned, with a HZ of 1000, the granularity for a one-hour
timer is four minutes, which matches the seen behavior.

To "fix" it, the user can just lower the timeout value by four minutes,
but that's a workaround, because the keepalive timer isn't working as
advertised.

One potential fix would be an "upper bound mode" in the timer, i.e. give
the user a way to specify that the given 'expires' value is an upper
bound rather than a lower bound.

As you graciously offered, if you or Anna-Maria can implement that new
interface, we (Artem or I) can write up a patch to use it for the
keepalive timer.

-- 
Josh