Re: [PATCH v2 03/19] maple_tree: Add write lock checking with lockdep sequence numbers

[Liam R. Howlett (Oracle)]

 On 26/07/20 09:04AM, Breno Leitao wrote:
> On Mon, Jul 20, 2026 at 10:03:51AM -0400, Liam R. Howlett (Oracle) wrote:
> > On 26/07/08 08:44AM, Breno Leitao wrote:
> > > Hello Liam,
> > 
> > Hello!
> > 
> > > 
> > > On Tue, Jun 30, 2026 at 03:08:27PM -0400, Liam R. Howlett (Oracle) wrote:
> > > > +#ifdef CONFIG_RCU_STRICT_GRACE_PERIOD
> > > >  	if (!mt_locked(mas->tree)) {
> > > >  		if (mt_in_rcu(mas->tree))
> > > >  			WARN_ON_ONCE(poll_state_synchronize_rcu(mas->rcu_gp));
> > > 
> > > Testing next-20260706 on arm64 under a stress-ng + fork/exit/mprotect workload,
> > > I'm hitting the new maple_tree write-lock sequence check:
> > > 
> > >     WARNING: lib/maple_tree.c:1188 at mas_store_prealloc+0x2a8/0xac0
> > 
> > No, this is not expected and I didn't know about it.  Does it still
> > happen in next?  I'll start looking at this while I wait to hear from
> > your side.
> 
> Yes, I see it on my everyday's test.
> 
> > 
> > That's very odd.  Does anything show up with a lockdep build?
> 
> Yes, but not sure if this is related. This is happening twice, thus, the
> messy kernel message
> 
>  01:37:12  perf: interrupt took too long (3127 > 3126), lowering kernel.perf_event_max_sample_rate to 63000
>  01:37:38  
>            ------------[ cut here ]------------
>            WARNING: lib/maple_tree.c:1188 at mas_find+0x620/0x810, CPU#45: stress-ng-sysfs/419993  [warn]
>            Modules linked in: md4(E) vhost_vsock(E) vfio_iommu_type1(E) vfio(E) act_gact(E) tcp_diag(E) inet_diag(E)
>            ------------[ cut here ]------------
>             cls_bpf(E)
>             evdev(E) ipmi_devintf(E) ipmi_msghandler(E) spi_nor(E) button(E) sch_fq_codel(E) vhost_net(E) tap(E) tun(E)
>            WARNING: lib/maple_tree.c:1188 at mas_store+0x2a8/0x678, CPU#7: stress-ng-sysfs/419987  [warn]
>             mpls_iptunnel(E) vhost(E) tls(E)
>            Modules linked in:
>             vhost_iotlb(E) mpls_gso(E)
>             md4(E)
>             mpls_router(E)
>             vhost_vsock(E)
>             loop(E)
>             vfio_iommu_type1(E)
>             fou(E)
>             vfio(E)
>             efivarfs(E)
>             act_gact(E)
>             autofs4(E)
>             tcp_diag(E)
>             [last unloaded: test_bpf(E)]
>             inet_diag(E)
>            
>             cls_bpf(E) evdev(E) ipmi_devintf(E) ipmi_msghandler(E) spi_nor(E) button(E) sch_fq_codel(E) vhost_net(E)
>            CPU: 45 UID: 0 PID: 419993 Comm: stress-ng-sysfs Kdump: loaded Tainted: G            E       7.2.0-rc2-next-20260710upstream-baseline #19 PREEMPT(full) 
>             tap(E) tun(E) mpls_iptunnel(E)
>            Tainted: [E]=UNSIGNED_MODULE
>             vhost(E)
>             tls(E)
>             vhost_iotlb(E) mpls_gso(E) mpls_router(E)
>            pstate: 03401009 (nzcv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)
>             loop(E) fou(E)
>            pc : mas_find+0x620/0x810
>             efivarfs(E) autofs4(E) [last unloaded: test_bpf(E)]
>            lr : mas_find+0x1c8/0x810
>            
>            sp : ffff80011fa579e0
>            x29: ffff80011fa579e0
>            CPU: 7 UID: 0 PID: 419987 Comm: stress-ng-sysfs Kdump: loaded Tainted: G            E       7.2.0-rc2-next-20260710upstream-baseline #19 PREEMPT(full) 
>             x28: 1ffff00023f4af5d x27: 1ffff00023f4af62
>            Tainted: [E]=UNSIGNED_MODULE
>            x26: ffff0000b65379a0
>             x25: 00000000000000e7 x24: 1ffff00023f4af6f
>            pstate: 03401009 (nzcv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)
>            
>            x23: dfff800000000000 x22: ffff00011aa90e78
>            pc : mas_store+0x2a8/0x678
>             x21: fffffffffffffffe
>            x20: ffff80011fa57b30
>            lr : mas_store+0x2a0/0x678
>             x19: ffff80011fa57b78
>            sp : ffff80011e9c7810
>             x18: 0000000000000000
>            x29: ffff80011e9c7890
>            x17: ffff800082ef24c4
>             x28: 1fffe000507cf8f2
>             x16: 0000000000000068 x15: 0000000000000001
>             x27: dfff800000000000
>            
>            
>            x14: 1fffe001310d8da4
>            x26: ffff000283e7c790
>             x13: 0000000000000001
>             x25: 0000000000000097 x24: 1ffff00023d38f40
>             x12: 0000aaf4db60a000
>            
>            x11: ffff00015fb58bf0
>            x23: dfff800000000000 x22: ffff0009dd07f178
>             x10: 0000aaf4db60a000
>             x21: ffff000283e7c780
>             x9 : 0000000000000300
>            
>            
>            x20: ffff80011e9c7a00
>            x8 : 0000000000000000
>             x19: ffff80011e9c79b8 x18: 0000000000000118
>             x7 : ffff8000808bcf34
>            
>             x6 : 0000000000000000
>            x17: ffff800082ef24c4
>            
>            x5 : 0000000000000000
>             x16: 0000000000000068
>             x4 : 0000000000000001
>             x15: 000000000000000a
>             x3 : 0000aaf4db60a000
>            
>            x14: 1ffff00023d38f07
>            
>             x13: 0000000000000000
>            x2 : 0000000000000000
>             x12: 0000000000000000
>             x1 : 00000000ffffffff
>            
>             x0 : 00000000ffffffff
>            x11: ffff700023d38f11
>            
>             x10: dfff800000000000
>            Call trace:
>             x9 : 0000000000000300
>            x8 : 0000000000000000
>             mas_find+0x620/0x810 (P)
>             x7 : 0000000000000000 x6 : ffff8000808bf46c
>            x5 : 0000000000000000 x4 : 0000000000000008 x3 : 0000000000000000
>             unmap_vmas+0x180/0x320
>            x2 : 0000000000000008 x1 : 00000000ffffffff x0 : 00000000ffffffff
>            Call trace:
>             exit_mmap+0x134/0x8f8
>             mas_store+0x2a8/0x678 (P)
>             __mmput+0xb8/0x340
>             dup_mmap+0x698/0x1350
>             mmput+0x60/0x98
>             copy_mm+0xe4/0x3c8
>             do_exit+0x594/0x1a28
>             do_group_exit+0x180/0x220
>             copy_process+0x12f0/0x31e8
>             __arm64_sys_exit_group+0x50/0x58
>             kernel_clone+0x14c/0x768
>             __arm64_sys_clone+0x100/0x140
>             invoke_syscall+0x74/0x188
>             do_el0_svc+0x10c/0x198
>             invoke_syscall+0x74/0x188
>             do_el0_svc+0x10c/0x198
>             el0_svc+0x64/0x260
>             el0_svc+0x64/0x260
>             el0t_64_sync_handler+0x84/0x130
>             el0t_64_sync_handler+0x84/0x130
>             el0t_64_sync+0x198/0x1a0
>             el0t_64_sync+0x198/0x1a0
>            irq event stamp: 251
>            irq event stamp: 265
>            hardirqs last  enabled at (251): [<ffff800080911648>] seqcount_lockdep_reader_access+0x68/0xc8
>            hardirqs last  enabled at (265): [<ffff800082da75ec>] _raw_spin_unlock_irqrestore+0x44/0xb0
>            hardirqs last disabled at (250): [<ffff80008091160c>] seqcount_lockdep_reader_access+0x2c/0xc8
>            hardirqs last disabled at (264): [<ffff800082da73c0>] _raw_spin_lock_irqsave+0x38/0x90
>            softirqs last  enabled at (136): [<ffff80008011dfb4>] handle_softirqs+0xd8c/0xf08
>            softirqs last disabled at (131): [<ffff8000800103d0>] __do_softirq+0x20/0x2c
>            softirqs last  enabled at (178): [<ffff800080092ed4>] fpsimd_save_and_flush_current_state+0xac/0x100
>            ---[ end trace 0000000000000000 ]---
>            softirqs last disabled at (176): [<ffff800080092e58>] fpsimd_save_and_flush_current_state+0x30/0x100
>            ---[ end trace 0000000000000000 ]---
>            ======================================================
>            WARNING: possible circular locking dependency detected  [lockdep]
>            7.2.0-rc2-next-20260710upstream-baseline #19 Tainted: G        W   E      
>            ------------------------------------------------------
>            stress-ng-sysfs/419983 is trying to acquire lock:
>            ffff000390315b78 (&mm->mmap_lock){++++}-{4:4}, at: mmap_read_lock_killable+0x20/0xe8
>            
> but task is already holding lock:
>            ffff0000a1747180 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_fop_readdir+0x1e8/0x720
>            
> which lock already depends on the new lock.
> 
>            
> the existing dependency chain (in reverse order) is:
>            
> -> #3 (&root->kernfs_rwsem){++++}-{4:4}:
>                   down_read+0x68/0x320
>                   kernfs_find_and_get_ns+0x3c/0xf8
>                   sysfs_notify+0x90/0xd0
>                   btrfs_exclop_finish+0x94/0xb8
>                   btrfs_swap_activate+0xedc/0x1900
>                   setup_swap_extents+0x13c/0x4a8
>                   __arm64_sys_swapon+0xb20/0x1490
>                   invoke_syscall+0x74/0x188
>                   do_el0_svc+0x10c/0x198
>                   el0_svc+0x64/0x260
>                   el0t_64_sync_handler+0x84/0x130
>                   el0t_64_sync+0x198/0x1a0
>            
> -> #2 (&ei->i_mmap_lock){++++}-{4:4}:
>                   down_read+0x68/0x320
>                   btrfs_page_mkwrite+0x414/0x1088
>                   do_page_mkwrite+0x124/0x258
>                   do_wp_page+0x52c/0x3270
>                   handle_mm_fault+0xa24/0x1bb0
>                   do_page_fault+0x2ac/0xa90
>                   do_mem_abort+0x78/0x198
>                   el0_da+0x78/0x258
>                   el0t_64_sync_handler+0x90/0x130
>                   el0t_64_sync+0x198/0x1a0
>            
> -> #1 (sb_pagefaults){.+.+}-{0:0}:
>                   btrfs_page_mkwrite+0x200/0x1088
>                   do_page_mkwrite+0x124/0x258
>                   do_pte_missing+0xa7c/0x2160
>                   handle_mm_fault+0x9c8/0x1bb0
>                   do_page_fault+0x35c/0xa90
>                   do_translation_fault+0x78/0x90
>                   do_mem_abort+0x78/0x198
>                   el0_da+0x78/0x258
>                   el0t_64_sync_handler+0x90/0x130
>                   el0t_64_sync+0x198/0x1a0
>            
> -> #0 (&mm->mmap_lock){++++}-{4:4}:
>                   __lock_acquire+0x1b58/0x3418
>                   lock_acquire+0x160/0x3a0
>                   down_read_killable+0x70/0x358
>                   mmap_read_lock_killable+0x20/0xe8
>                   lock_mm_and_find_vma+0x1e4/0x1f0
>                   do_page_fault+0x314/0xa90
>                   do_translation_fault+0x78/0x90
>                   do_mem_abort+0x78/0x198
>                   el1_abort+0x50/0x78
>                   el1h_64_sync_handler+0x50/0x100
>                   el1h_64_sync+0x6c/0x70
>                   filldir64+0x228/0x500
>                   kernfs_fop_readdir+0x444/0x720
>                   iterate_dir+0x1f4/0x370
>                   __arm64_sys_getdents64+0xc0/0x1e0
>                   invoke_syscall+0x74/0x188
>                   do_el0_svc+0x10c/0x198
>                   el0_svc+0x64/0x260
>                   el0t_64_sync_handler+0x84/0x130
>                   el0t_64_sync+0x198/0x1a0
>            
> other info that might help us debug this:
> 
>            Chain exists of:
>   &mm->mmap_lock --> &ei->i_mmap_lock --> &root->kernfs_rwsem
> 
>             Possible unsafe locking scenario:
> 
>                   CPU0                    CPU1
>                   ----                    ----
>              rlock(&root->kernfs_rwsem);
>                                           lock(&ei->i_mmap_lock);
>                                           lock(&root->kernfs_rwsem);
>              rlock(&mm->mmap_lock);
>            
>  *** DEADLOCK ***
> 
>            locks held by stress-ng-sysfs/419983: 3, last CPU#4:
>             #0: ffff0003919b1b30 (&f->f_pos_lock){+.+.}-{4:4}, at: fdget_pos+0x1b0/0x240
>             #1: ffff0000bfa8d200 (&type->i_mutex_dir_key#3){++++}-{4:4}, at: iterate_dir+0x164/0x370
>             #2: ffff0000a1747180 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_fop_readdir+0x1e8/0x720

This looks like a valid issue in btrfs.

>            
> stack backtrace:
>            CPU: 4 UID: 0 PID: 419983 Comm: stress-ng-sysfs Kdump: loaded Tainted: G        W   E       7.2.0-rc2-next-20260710upstream-baseline #19 PREEMPT(full) 
>            Tainted: [W]=WARN, [E]=UNSIGNED_MODULE
>            Call trace:
>             show_stack+0x24/0x38 (C)
>             __dump_stack+0x28/0x38
>             dump_stack_lvl+0x74/0xa8
>             dump_stack+0x18/0x24
>             print_circular_bug+0x328/0x330
>             check_noncircular+0x17c/0x1a0
>             __lock_acquire+0x1b58/0x3418
>             lock_acquire+0x160/0x3a0
>             down_read_killable+0x70/0x358
>             mmap_read_lock_killable+0x20/0xe8
>             lock_mm_and_find_vma+0x1e4/0x1f0
>             do_page_fault+0x314/0xa90
>             do_translation_fault+0x78/0x90
>             do_mem_abort+0x78/0x198
>             el1_abort+0x50/0x78
>             el1h_64_sync_handler+0x50/0x100
>             el1h_64_sync+0x6c/0x70
>             filldir64+0x228/0x500 (P)
>             kernfs_fop_readdir+0x444/0x720
>             iterate_dir+0x1f4/0x370
>             __arm64_sys_getdents64+0xc0/0x1e0
>             invoke_syscall+0x74/0x188
>             do_el0_svc+0x10c/0x198
>             el0_svc+0x64/0x260
>             el0t_64_sync_handler+0x84/0x130
>             el0t_64_sync+0x198/0x1a0
>  01:37:47  capability: warning: `stress-ng-cap' uses deprecated v2 capabilities in a way that may be insecure
> 
> > Your
> > trace comment leads me to believe there is a lot of these triggering
> > with CONFIG_RCU_STRICT_GRACE_PERIOD, is that correct?
> 
> I don't think this is set in the kernel I am seeing it Why do you think
> CONFIG_RCU_STRICT_GRACE_PERIOD is set?

I added more debug for strict grace period that is not being triggered,
I was wondering if this was contributing to the log mess, but I don't
think it is.

What is happening is that I have an issue that is flooding your logs
once the lock enters the invalid state.  lock_is_held() is returning -1
(unknown state) after lockdep sets debug_locks to 0.  This happens once
lockdep detects the valid deadlock state you have in your logs.

The logs are flooded because the reading of the sequence counter will
return UINT_MAX (return ~0), which then does not match the recorded
sequence counter.  This will happen rather frequently.

I have a working fix to disable the checking on seq == ~0, since it's
not possible to hit that value even when wrapping around (seqence
counter isn't 32bits in total).

If you could test the attached patch to see if it stops your log
flooding, I would appreciate it.

Unfortunately, the deadlock does look to be another issue in an area I
am not familiar with.

Thanks,
Liam