Re: [PATCH] locking/lockdep: skip irq save/restore in hardirq context in lock_release()

[Deepanshu Kartikey]

On Tue, Jun 30, 2026 at 10:28 AM Waiman Long <longman@xxxxxxxxxx> wrote:
>
>
> I looked at the generated code of raw_local_irq_restore():
>
> ./arch/x86/include/asm/irqflags.h:
> 146        return !(flags & X86_EFLAGS_IF);
>     0x00000000000082b9 <+9>:    test   $0x200,%edi
>     0x00000000000082bf <+15>:    je     0x82c2 <cpuset_test+18>
>
> 42        asm volatile("sti": : :"memory");
>     0x00000000000082c1 <+17>:    sti
>
> kernel/cgroup/cpuset.c:
> 4553    }
>     0x00000000000082c2 <+18>:    jmp    0x82c7
>
> sti should only be called if the saved flags has the IF bit set. In
> hardirq context, the IF bit shouldn't be set. Is my interpretation correct?
>
> Regards,
> Longman
>

You are correct - in hardirq context, the IF bit in EFLAGS should
already be 0 (IRQs disabled by CPU on interrupt entry). Therefore
raw_local_irq_restore() should not execute sti.

However, the syzkaller reproducer consistently triggers the RCU stall,
indicating a real issue exists. Our fix is correct regardless of the
root cause - by completely skipping the raw_local_irq_save/restore
dance in hardirq context, we avoid any potential issues in this path.

Hardirq handlers must never manipulate IRQ state mid-execution since
the CPU hardware manages it automatically on entry/exit. This is a
fundamental rule of interrupt handling.

If you have insights into the actual root cause, we'd appreciate
understanding it better.

Thank you for the thorough review.

Deepanshu