7.3.0-rc4: DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())

7.3.0-rc4: DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())

[Sebastian Andrzej Siewior]

Hi,

I've seen similar reports such as
	https://lore.kernel.org/all/b44aefc5-e066-478b-8d34-50d2d0deab6b@linux.ibm.com/

but nothing on recent one. I am not sure if this is the same issue or
something different. This happens during boot:

| ------------[ cut here ]------------
| DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())
| WARNING: kernel/locking/lockdep.c:4448 at lockdep_hardirqs_on_prepare+0x22c/0x2e0, CPU#0: swapper/0/0
| Modules linked in:
| CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc4 #6 PREEMPT(lazy)
| Hardware name: IBM pSeries (emulated by qemu) Power11 (architected) 0x821200 0xf000007 of:SLOF,HEAD pSeries
| NIP:  c0000000001ec72c LR: c0000000001ec728 CTR: c000000000e1ab70
| REGS: c0000000017531e0 TRAP: 0700   Not tainted  (7.3.0-rc4)
| MSR:  8000000002021033 <SF,VEC,ME,IR,DR,RI,LE>  CR: 48028228  XER: 00000000
| CFAR: c00000000011ee84 IRQMASK: 3
| GPR00: c0000000001ec728 c000000001753480 c000000001248000 000000000000002e
| GPR04: c0000000015ee8d8 c0000000015ee9c8 0000000000000001 0000000000000080
| GPR08: c0000000015ee7b8 0000000001000003 c000000001581400 0000000048028228
| GPR12: c000000001788228 c000000002340000 c0000000005bbd50 c000000000ea30f0
| GPR16: c0000000016cec98 c0000000011a1518 c000000003327658 0000000000000001
| GPR20: c0000000016c9620 c0000000015e3c80 c0000000016c9670 0000000000000000
| GPR24: 0000000000000000 0000000000000001 0000000000000000 c000000001788228
| GPR28: c000000001380580 c000000000027644 0000000000000000 c000000001387160
| NIP [c0000000001ec72c] lockdep_hardirqs_on_prepare+0x22c/0x2e0
| LR [c0000000001ec728] lockdep_hardirqs_on_prepare+0x228/0x2e0
| Call Trace:
| [c000000001753480] [c0000000001ec728] lockdep_hardirqs_on_prepare+0x228/0x2e0 (unreliable)
| [c000000001753500] [c000000000331c90] trace_hardirqs_on+0x90/0x130
| [c000000001753540] [c000000000e257f4] irqentry_exit+0x554/0x10b0
| [c000000001753600] [c000000000027644] timer_interrupt+0x254/0x5c0
| [c0000000017536c0] [c00000000003a2c0] __replay_soft_interrupts+0x140/0x390
| [c000000001753880] [c00000000003a614] arch_local_irq_restore+0x104/0x1f0
| [c0000000017538b0] [c0000000001eed9c] lock_acquire+0x19c/0x440
| [c0000000017539b0] [c000000000541024] __kmalloc_cache_noprof+0x114/0x630
| [c000000001753a90] [c0000000004970c8] shrinker_alloc+0x38/0xe0
| [c000000001753ac0] [c0000000005bf374] sget_fc+0x364/0x940
| [c000000001753c00] [c0000000005bfd78] get_tree_nodev+0x38/0xf0
| [c000000001753c40] [c000000000649060] nullfs_fs_get_tree+0x20/0x40
| [c000000001753c60] [c0000000005ba01c] vfs_get_tree+0x3c/0x110
| [c000000001753ce0] [c0000000006043a0] fc_mount+0x20/0xc0
| [c000000001753d20] [c000000000604544] vfs_kern_mount.part.0+0x104/0x120
| [c000000001753d80] [c0000000006045bc] kern_mount+0x2c/0x60
| [c000000001753da0] [c000000001296f20] mnt_init+0x3c8/0x50c
| [c000000001753e80] [c000000001296610] vfs_caches_init+0x100/0x144
| [c000000001753f30] [c00000000125442c] start_kernel+0xa4c/0xabc
| [c000000001753fe0] [c00000000000d688] start_here_common+0x1c/0x20
| Code: 4182ff80 3d220054 3929106c 81290000 2c090000 4082ff6c 3c82ffe7 3c62ffe7 38846858 3863dfd8 4bf32645 60000000 <0fe00000> 4bffff4c 60000000 60000000
| irq event stamp: 472
| hardirqs last  enabled at (471): [<c000000000e39034>] _raw_spin_unlock_irqrestore+0xa4/0xb0
| hardirqs last disabled at (472): [<c00000000003a5b8>] arch_local_irq_restore+0xa8/0x1f0
| softirqs last  enabled at (10): [<c00000000012db60>] handle_softirqs+0x670/0x6d0
| softirqs last disabled at (3): [<c000000000016f88>] do_softirq_own_stack+0x38/0x50
| ---[ end trace 0000000000000000 ]---

Sebastian

Re: 7.3.0-rc4: DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())

[Shrikanth Hegde]

Hi Sebastian.

Thanks for the report.

+cc mukesh

On 9/22/26 8:36 PM, Sebastian Andrzej Siewior wrote:
> Hi,
> 
> I've seen similar reports such as
> 	https://lore.kernel.org/all/b44aefc5-e066-478b-8d34-50d2d0deab6b@linux.ibm.com/
> 

Yes, we had taken a look at them. There is work being done, but patches
haven't been posted since we were burning cycles to fix the functional issues
even without lockdep on generic entry.

> but nothing on recent one. I am not sure if this is the same issue or

What do you mean nothing on recent one? You don't see the lockdep warning?

> something different. This happens during boot:
> 
> | ------------[ cut here ]------------
> | DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())
> | WARNING: kernel/locking/lockdep.c:4448 at lockdep_hardirqs_on_prepare+0x22c/0x2e0, CPU#0: swapper/0/0
> | Modules linked in:
> | CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.3.0-rc4 #6 PREEMPT(lazy)
> | Hardware name: IBM pSeries (emulated by qemu) Power11 (architected) 0x821200 0xf000007 of:SLOF,HEAD pSeries
> | NIP:  c0000000001ec72c LR: c0000000001ec728 CTR: c000000000e1ab70
> | REGS: c0000000017531e0 TRAP: 0700   Not tainted  (7.3.0-rc4)
> | MSR:  8000000002021033 <SF,VEC,ME,IR,DR,RI,LE>  CR: 48028228  XER: 00000000
> | CFAR: c00000000011ee84 IRQMASK: 3
> | GPR00: c0000000001ec728 c000000001753480 c000000001248000 000000000000002e
> | GPR04: c0000000015ee8d8 c0000000015ee9c8 0000000000000001 0000000000000080
> | GPR08: c0000000015ee7b8 0000000001000003 c000000001581400 0000000048028228
> | GPR12: c000000001788228 c000000002340000 c0000000005bbd50 c000000000ea30f0
> | GPR16: c0000000016cec98 c0000000011a1518 c000000003327658 0000000000000001
> | GPR20: c0000000016c9620 c0000000015e3c80 c0000000016c9670 0000000000000000
> | GPR24: 0000000000000000 0000000000000001 0000000000000000 c000000001788228
> | GPR28: c000000001380580 c000000000027644 0000000000000000 c000000001387160
> | NIP [c0000000001ec72c] lockdep_hardirqs_on_prepare+0x22c/0x2e0
> | LR [c0000000001ec728] lockdep_hardirqs_on_prepare+0x228/0x2e0
> | Call Trace:
> | [c000000001753480] [c0000000001ec728] lockdep_hardirqs_on_prepare+0x228/0x2e0 (unreliable)
> | [c000000001753500] [c000000000331c90] trace_hardirqs_on+0x90/0x130
> | [c000000001753540] [c000000000e257f4] irqentry_exit+0x554/0x10b0
> | [c000000001753600] [c000000000027644] timer_interrupt+0x254/0x5c0
> | [c0000000017536c0] [c00000000003a2c0] __replay_soft_interrupts+0x140/0x390
> | [c000000001753880] [c00000000003a614] arch_local_irq_restore+0x104/0x1f0
> | [c0000000017538b0] [c0000000001eed9c] lock_acquire+0x19c/0x440
> | [c0000000017539b0] [c000000000541024] __kmalloc_cache_noprof+0x114/0x630
> | [c000000001753a90] [c0000000004970c8] shrinker_alloc+0x38/0xe0
> | [c000000001753ac0] [c0000000005bf374] sget_fc+0x364/0x940
> | [c000000001753c00] [c0000000005bfd78] get_tree_nodev+0x38/0xf0
> | [c000000001753c40] [c000000000649060] nullfs_fs_get_tree+0x20/0x40
> | [c000000001753c60] [c0000000005ba01c] vfs_get_tree+0x3c/0x110
> | [c000000001753ce0] [c0000000006043a0] fc_mount+0x20/0xc0
> | [c000000001753d20] [c000000000604544] vfs_kern_mount.part.0+0x104/0x120
> | [c000000001753d80] [c0000000006045bc] kern_mount+0x2c/0x60
> | [c000000001753da0] [c000000001296f20] mnt_init+0x3c8/0x50c
> | [c000000001753e80] [c000000001296610] vfs_caches_init+0x100/0x144
> | [c000000001753f30] [c00000000125442c] start_kernel+0xa4c/0xabc
> | [c000000001753fe0] [c00000000000d688] start_here_common+0x1c/0x20
> | Code: 4182ff80 3d220054 3929106c 81290000 2c090000 4082ff6c 3c82ffe7 3c62ffe7 38846858 3863dfd8 4bf32645 60000000 <0fe00000> 4bffff4c 60000000 60000000
> | irq event stamp: 472
> | hardirqs last  enabled at (471): [<c000000000e39034>] _raw_spin_unlock_irqrestore+0xa4/0xb0
> | hardirqs last disabled at (472): [<c00000000003a5b8>] arch_local_irq_restore+0xa8/0x1f0
> | softirqs last  enabled at (10): [<c00000000012db60>] handle_softirqs+0x670/0x6d0
> | softirqs last disabled at (3): [<c000000000016f88>] do_softirq_own_stack+0x38/0x50
> | ---[ end trace 0000000000000000 ]---
> 
> Sebastian

IIRC, it is tricky to fix since softreplay is a unique thing on its own
and tracking right context gets tricky.

Mukesh had spent some time on it. Lets wait to hear from him.

Plus we had some more lockdep warnings too. There is effort ongoing to fix
them. Hopefully soon.

Re: 7.3.0-rc4: DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())

[Sebastian Andrzej Siewior]

On 2026-09-22 20:43:14 [+0530], Shrikanth Hegde wrote:
> Hi Sebastian.
Hi Shrikanth,

> What do you mean nothing on recent one? You don't see the lockdep warning?

I do as seen below. I wasn't sure if this new that nobody triggered or
the same thing in different shape (and a new report isn't needed).

…
> IIRC, it is tricky to fix since softreplay is a unique thing on its own
> and tracking right context gets tricky.
> 
> Mukesh had spent some time on it. Lets wait to hear from him.
> 
> Plus we had some more lockdep warnings too. There is effort ongoing to fix
> them. Hopefully soon.

I see. In that case I lay low. Thanks.

Sebastian

Re: 7.3.0-rc4: DEBUG_LOCKS_WARN_ON(lockdep_hardirq_context())

[Mukesh Kumar Chaurasiya]

On Tue, Sep 22, 2026 at 05:19:46PM +0200, Sebastian Andrzej Siewior wrote:
> On 2026-09-22 20:43:14 [+0530], Shrikanth Hegde wrote:
> > Hi Sebastian.
> Hi Shrikanth,
> 
> > What do you mean nothing on recent one? You don't see the lockdep warning?
> 
> I do as seen below. I wasn't sure if this new that nobody triggered or
> the same thing in different shape (and a new report isn't needed).
> 
> …
> > IIRC, it is tricky to fix since softreplay is a unique thing on its own
> > and tracking right context gets tricky.
> > 
> > Mukesh had spent some time on it. Lets wait to hear from him.
> > 
> > Plus we had some more lockdep warnings too. There is effort ongoing to fix
> > them. Hopefully soon.
> 
> I see. In that case I lay low. Thanks.
> 
> Sebastian
> 
Hey Sebastian,

It's really tricky to fix due to soft replay mechanism as we go into a
nested interrupt context during replay. As of now I don't have a fix for
this. I am working towards this. Hopefully we'll have some solution
soon.

Regards,
Mukesh