linux-kernel - Re: [PATCH] genirq: Ensure flags in lock guard is consistently initialized

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: <61d1b49c-e2ef-4a43-942d-6e321d4be8c8@kernel.org>
Date: Tue, 13 May 2025 07:22:32 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: Nathan Chancellor <nathan@...nel.org>,
 Thomas Gleixner <tglx@...utronix.de>
Cc: Peter Zijlstra <peterz@...radead.org>, linux-kernel@...r.kernel.org,
 llvm@...ts.linux.dev
Subject: Re: [PATCH] genirq: Ensure flags in lock guard is consistently
 initialized

On 13. 05. 25, 0:16, Nathan Chancellor wrote:
> After the conversion to locking guards within the interrupt core code,
> several builds with clang show the "Interrupts were enabled early"
> WARN() in start_kernel() on boot.
> 
> In class_irqdesc_lock_constructor(), _t.flags is initialized via
> __irq_get_desc_lock() within the _t initializer list. However, the C11
> standard 6.7.9.23 states that the evaluation of the initialization list
> expressions are indeterminately sequenced relative to one another,
> meaning _t.flags could be initialized by __irq_get_desc_lock() then be
> initialized to zero due to flags being absent from the initializer list.
> 
> To ensure _t.flags is consistently initialized, move the call to
> __irq_get_desc_lock() and the assignment of its result to _t.lock out of
> the designated initializer.
> 
> Fixes: 0f70a49f3fa3 ("genirq: Provide conditional lock guards")
> Signed-off-by: Nathan Chancellor <nathan@...nel.org>

Reviewed-by: Jiri Slaby <jirislaby@...nel.org>

thanks,
-- 
js
suse labs