linux-kernel - Re: [PATCH] timers: Fix get_next_timer

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]

Date:   Fri, 16 Jul 2021 18:38:37 +0200
From:   Nicolas Saenz Julienne <nsaenzju@...hat.com>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     He Zhe <zhe.he@...driver.com>, anna-maria@...utronix.de,
        linux-kernel@...r.kernel.org, tglx@...utronix.de
Subject: Re: [PATCH] timers: Fix get_next_timer_interrupt() with no timers
 pending

On Sat, 2021-07-10 at 02:52 +0200, Frederic Weisbecker wrote:
> I guess later we can turn this .timers_pending into
> .timers_count and that would spare us the costly call to
> __next_timer_interrupt() up to the last level after the last
> timer is dequeued.

I've been looking into this. AFAIU there is no limit to the number of timers
one might enqueue, so there is no fool proof way of selecting .timers_count's
size. That said, 'struct timer_list' size is 40 bytes (as per pahole), so in
order to overflow an u32 .timers_count you'd need to allocate ~160GB in 'struct
timer_list' which I think is safe to assume will never happen.

Also, I measured the costy call to __next_timer_interrupt() it's slightly less
than 1us on my test machine. Not a that big in the grand scheme of things, but
it's in the irq exit code path, so I think it's worth the extra complexity in
the timer code.

Any thoughs?

-- 
Nicolás Sáenz