Re: [PATCH] locking: Revert switching guards to _irq_{disable,enable}()

[Thomas Gleixner <tglx@kernel.org>]

On Sat, Aug 29 2026 at 10:05, Peter Zijlstra wrote:
> On Sat, Aug 29, 2026 at 01:11:56AM +0200, Thomas Gleixner wrote:
>> diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
>> index 57b074e0cfbb..dd55786768d1 100644
>> --- a/include/linux/irqflags.h
>> +++ b/include/linux/irqflags.h
>
>> +static __always_inline void raw_force_local_irq_disable(void)
>> +{
>> +	arch_local_irq_disable();
>> +	__preempt_count_add(HARDIRQ_DISABLE_OFFSET);
>> +}
>
> So this thing is on all sorts of don't care, we're going down paths. It
> needs to ensure IRQs really are off, and preempt_count has at least one
> DISABLE_OFFSET on.
>
> *However* if something like acpi_power_off() were to 'fail' to enter S5
> and continue on with the notifier, things are now unbalanced. Probably
> not a problem, since the next handler will likely do
> raw_force_load_irq_disable() again.
>
> At the least this wants a comment I suppose.

Right. That stuff needs some eyeballs.

>> diff --git a/init/main.c b/init/main.c
>> index 2613d3f9b3ce..fa84ce260b04 100644
>> --- a/init/main.c
>> +++ b/init/main.c
>> @@ -991,7 +991,6 @@ void start_kernel(void)
>>  
>>  	cgroup_init_early();
>>  
>> -	local_irq_disable();
>>  	early_boot_irqs_disabled = true;
>
> If we want to preserve the paranoia of having that statement in the
> first place, it could be replaced with something like:
>
> 	WARN_ON_ONCE(!irqs_disabled());

Right.

> I suppose (lockdep isn't available yet).

Good question.