linux-kernel - Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes for v6.9]

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: Thu, 14 Mar 2024 10:03:55 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: "Russell King (Oracle)" <linux@...linux.org.uk>, Florian Fainelli
 <f.fainelli@...il.com>
Cc: Joel Fernandes <joel@...lfernandes.org>, Boqun Feng
 <boqun.feng@...il.com>, Anna-Maria Behnsen <anna-maria@...utronix.de>,
 Linus Torvalds <torvalds@...ux-foundation.org>,
 linux-kernel@...r.kernel.org, kernel-team@...a.com, paulmck@...nel.org,
 mingo@...nel.org, rcu@...r.kernel.org, neeraj.upadhyay@....com,
 urezki@...il.com, qiang.zhang1211@...il.com, frederic@...nel.org,
 bigeasy@...utronix.de, chenzhongjin@...wei.com, yangjihong1@...wei.com,
 rostedt@...dmis.org, Justin Chen <justin.chen@...adcom.com>
Subject: Re: Unexplained long boot delays [Was Re: [GIT PULL] RCU changes
 for v6.9]

On Wed, Mar 13 2024 at 21:59, Russell King (Oracle) wrote:
> On Wed, Mar 13, 2024 at 02:30:43PM -0700, Florian Fainelli wrote:
> I haven't understood the code there yet, and how it would interact with
> arch code, but one thing that immediately jumps out to me is this:
>
> "    As long as a CPU is busy it expires both local and global timers. When a
>     CPU goes idle it arms for the first expiring local timer."
>
> So are local timers "armed" when they are enqueued while the cpu is
> "busy" during initialisation, and will they expire, and will that
> expiry be delivered in a timely manner?

The local timers are timers which are pinned on a CPU. Global ones do
not care about the CPU they expire on.

So if the CPU goes idle then it arms for the first local timer. If the
first global timer expires after the first local, nothing to see. If it
expires before then that timer is queued in the migration hierarchy and
some other busy CPU will take care of it. If the last CPU goes idle then
it has to arm for the first timer (it's own local, global and the
hierarchy). So it's all covered in theory, but there seems to be an
issue somewhere. We'll figure it out.

Thanks,

        tglx