linux-kernel - Re: Sv: Sv: [PATCH] hrtimer: Interrupt storm on clock

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: <87k0qrtexe.fsf@nanos.tec.linutronix.de>
Date:   Mon, 01 Mar 2021 10:13:17 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Mikael Beckius <mikael.beckius@...driver.com>,
        anna-maria@...utronix.de
Cc:     linux-kernel@...r.kernel.org, mikael.beckius@...driver.com
Subject: Re: Sv: Sv: [PATCH] hrtimer: Interrupt storm on clock_settime

Micke,

On Thu, Feb 25 2021 at 12:18, Mikael Beckius wrote:

>> The proposed change breaks the reprogramming logic. To keep it working
>> cpu_base::*expires_next is only updated by hrtimer_reprogram() and
>> hrtimer_interrupt(). I will send you a patch for testing in reply to this
>> thread. The patch is compile tested only.
>> 
> Ok. I kind of guessed that would be the response as I noticed a similar comment
> during the review of the original patch which introduced the softirq_expires_next
> logic. Anyway it seemed logical to update softirq_expires_next
> when updating softirq_next_timer.

yes it seems logical to do that, but unfortunately the logic there is a
bit twisted and could do with some deobfuscation.

Thanks,

        tglx