netdev - Re: [PATCH v3 1/2] timer: add a function to adjust timeouts to be upper bound

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

Message-ID: <8735iolbjz.ffs@tglx>
Date:   Fri, 08 Apr 2022 01:26:56 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Artem Savkov <asavkov@...hat.com>
Cc:     Anna-Maria Behnsen <anna-maria@...utronix.de>,
        netdev@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        davem@...emloft.net, yoshfuji@...ux-ipv6.org, dsahern@...nel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/2] timer: add a function to adjust timeouts to be
 upper bound

On Wed, Apr 06 2022 at 11:52, Artem Savkov wrote:

> On Tue, Apr 05, 2022 at 05:33:23PM +0200, Thomas Gleixner wrote:
>> On Sat, Apr 02 2022 at 08:55, Artem Savkov wrote:
>> > Is it possible to determine the upper limit of error margin here? My
>> > assumption is it shouldn't be very big, so maybe it would be enough to
>> > account for this when adjusting timeout at the edge of a level.
>> > I know this doesn't sound good but I am running out of ideas here.
>> 
>> Let's just take a step back.
>> 
>> So we know, that the maximal error margin in the wheel is 12.5%, right?
>> That means, if you take your relative timeout and subtract 12.5% then
>> you are in the right ballpark and the earliest expiry will not be before
>> that point obviously, but it's also guaranteed not to expire later than
>> the original timeout. Obviously this will converge towards the early
>> expiry the longer the timeouts are, but it's bound.
>
> Ok, I was trying to avoid a "hole" where any timeout < LVL_GRAN(lvl)
> would be always substantially (LVL_GRAN(lvl) - LVL_GRAN(lvl - 1)) early
> but looks like this is unavoidable with this approach.

Right, but where is the problem you are trying to solve? Does it matter
whether the keepalive timer fires after 28 minutes or after 30 minutes?

Not really. All you are about that it does not fire 2 minutes late. So
what?

>> Also due to the properties of the wheel, the lag of base::clk will
>> obviously only affect those levels where lag >= LVL_GRAN(level).
>
> Is this true? Won't it be enough for the lag to be just
> lag >= (LVL_START(lvl) - adjusted_timeout) for the cases when we cross
> level boundary on adjustment?

The corner case is at the next boundary level. The resulting worst case
there is one jiffy, which is below noise level :)

Thanks,

        tglx