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: <CACRpkdZmax=QpwnfgOJOR-5P3wTyKegaDn=VvhVOYz_AChc7bw@mail.gmail.com>
Date:   Tue, 1 Mar 2022 13:19:34 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     linux-power <linux-power@...rohmeurope.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Anna-Maria Gleixner <anna-maria@...utronix.de>
Cc:     Sebastian Reichel <sre@...nel.org>,
        Code Kipper <codekipper@...il.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Lee Jones <lee.jones@...aro.org>
Subject: Question on expiring HRtimer in-kernel

I have a problem with a premature expiring HRtimer.

The HRtimer hrtimer_set_expires_range() is used in two places in
the upstream kernel:
kernel/futex/core.c
drivers/power/supply/ab8500_chargalg.c

Now I am testing the code in the latter, and it has seen some
bitrot since merged in 2012. Maybe it was correct at one point.
The timer is started like this:

    hrtimer_init(&di->safety_timer, CLOCK_REALTIME, HRTIMER_MODE_ABS);
(...)
    hrtimer_set_expires_range(&di->safety_timer,
        ktime_set(timer_expiration * ONE_HOUR_IN_SECONDS, 0),
        ktime_set(FIVE_MINUTES_IN_SECONDS, 0));
    hrtimer_start_expires(&di->safety_timer, HRTIMER_MODE_REL);

What the author wanted to achieve is a very definitive callback in one
hour relative to now +/- 5 min, and that is one hour later in the
physical world,
as this deals with battery charging.

However sometimes this fires almost immediately rather than in an hour.

My first thought is to pass HRTIMER_MODE_REL also to init as
hrtimer_set_expires_range() could make things happen immediately
if we have ABS set, but this is all just intuitive.

Any hints? Better ways to create a definitive event in one hour?

Yours,
Linus Walleij

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ