Re: WARNING: bad unlock balance in rcu_core

[Bart Van Assche]

On 2020-02-27 07:18, Dmitry Vyukov wrote:
> On Wed, Oct 16, 2019 at 11:58 AM Gao Xiang <gaoxiang25@xxxxxxxxxx> wrote:
>>
>> Hi,
>>
>> On Wed, Oct 16, 2019 at 02:27:07AM -0700, syzbot wrote:
>>> syzbot has found a reproducer for the following crash on:
>>>
>>> HEAD commit:    0e9d28bc Add linux-next specific files for 20191015
>>> git tree:       linux-next
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=11745608e00000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=3d84ca04228b0bf4
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=36baa6c2180e959e19b1
>>> compiler:       gcc (GCC) 9.0.0 20181231 (experimental)
>>> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=159d297f600000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16289b30e00000
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+36baa6c2180e959e19b1@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>
>>> =====================================
>>> WARNING: bad unlock balance detected!
>>> 5.4.0-rc3-next-20191015 #0 Not tainted
>>> -------------------------------------
>>> syz-executor276/8897 is trying to release lock (rcu_callback) at:
>>> [<ffffffff8160e7a4>] __write_once_size include/linux/compiler.h:226 [inline]
>>> [<ffffffff8160e7a4>] __rcu_reclaim kernel/rcu/rcu.h:221 [inline]
>>> [<ffffffff8160e7a4>] rcu_do_batch kernel/rcu/tree.c:2157 [inline]
>>> [<ffffffff8160e7a4>] rcu_core+0x574/0x1560 kernel/rcu/tree.c:2377
>>> but there are no more locks to release!
>>>
>>> other info that might help us debug this:
>>> 1 lock held by syz-executor276/8897:
>>>  #0: ffff88809a3cc0d8 (&type->s_umount_key#40/1){+.+.}, at:
>>> alloc_super+0x158/0x910 fs/super.c:229
>>>
>>> stack backtrace:
>>> CPU: 0 PID: 8897 Comm: syz-executor276 Not tainted 5.4.0-rc3-next-20191015
>>> #0
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>>  <IRQ>
>>>  __dump_stack lib/dump_stack.c:77 [inline]
>>>  dump_stack+0x172/0x1f0 lib/dump_stack.c:113
>>>  print_unlock_imbalance_bug kernel/locking/lockdep.c:4008 [inline]
>>>  print_unlock_imbalance_bug.cold+0x114/0x123 kernel/locking/lockdep.c:3984
>>>  __lock_release kernel/locking/lockdep.c:4244 [inline]
>>>  lock_release+0x5f2/0x960 kernel/locking/lockdep.c:4505
>>>  rcu_lock_release include/linux/rcupdate.h:213 [inline]
>>>  __rcu_reclaim kernel/rcu/rcu.h:223 [inline]
>>
>> I have little knowledge about this kind of stuff, but after seeing
>> the dashboard https://syzkaller.appspot.com/bug?extid=36baa6c2180e959e19b1
>>
>> I guess this is highly related with ntfs, and in ntfs_fill_super, it
>> has lockdep_off() in ntfs_fill_super...
>>
>> In detail, commit 90c1cba2b3b3 ("locking/lockdep: Zap lock classes even
>> with lock debugging disabled") [1], and free_zapped_rcu....
>>
>> static void free_zapped_rcu(struct rcu_head *ch)
>> {
>>         struct pending_free *pf;
>>         unsigned long flags;
>>
>>         if (WARN_ON_ONCE(ch != &delayed_free.rcu_head))
>>                 return;
>>
>>         raw_local_irq_save(flags);
>>         arch_spin_lock(&lockdep_lock);
>>         current->lockdep_recursion = 1;   <--- here
>>
>>         /* closed head */
>>         pf = delayed_free.pf + (delayed_free.index ^ 1);
>>         __free_zapped_classes(pf);
>>         delayed_free.scheduled = false;
>>
>>         /*
>>          * If there's anything on the open list, close and start a new callback.
>>          */
>>         call_rcu_zapped(delayed_free.pf + delayed_free.index);
>>
>>         current->lockdep_recursion = 0;
>>         arch_spin_unlock(&lockdep_lock);
>>         raw_local_irq_restore(flags);
>> }
>>
>> Completely guess and untest since I am not familar with that,
>> but in case of that, Cc related people...
>> If I'm wrong, ignore my comments and unintentional noise....
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90c1cba2b3b3851c151229f61801919b2904d437
>>
>> Thanks,
>> Gao Xiang
> 
> 
> Still happens a lot for the past 10 months:
> https://syzkaller.appspot.com/bug?id=0d5bdaf028e4283ad7404609d17e5077f48ff26d

Unless one of the NTFS maintainers steps in, should NTFS perhaps be
excluded from testing with lockdep enabled? This is what I found in the
git log of NTFS:

commit 59345374742ee6673c2d04b0fa8c888e881b7209
Author: Ingo Molnar <mingo@xxxxxxx>
Date:   Mon Jul 3 00:25:18 2006 -0700

    [PATCH] lockdep: annotate NTFS locking rules

    NTFS uses lots of type-opaque objects which acquire their true
    identity runtime - so the lock validator needs to be helped in a
    couple of places to figure out object types.

    Many thanks to Anton Altaparmakov for giving lots of explanations
    about NTFS locking rules.

    Has no effect on non-lockdep kernels.

Thanks,

Bart.