Re: [PATCH] Default enable RCU list lockdep debugging with PROVE_RCU

From: Guenter Roeck
Date: Thu Mar 05 2020 - 13:58:25 EST


On Thu, Mar 05, 2020 at 11:09:54PM +0530, Madhuparna Bhowmik wrote:
> On Thu, Mar 05, 2020 at 07:52:38AM -0800, Guenter Roeck wrote:
> > On Fri, Feb 28, 2020 at 02:54:51PM +0530, madhuparnabhowmik10@xxxxxxxxx wrote:
> > > From: Madhuparna Bhowmik <madhuparnabhowmik10@xxxxxxxxx>
> > >
> > > This patch default enables CONFIG_PROVE_RCU_LIST option with
> > > CONFIG_PROVE_RCU for RCU list lockdep debugging.
> > >
> > > With this change, RCU list lockdep debugging will be default
> > > enabled in CONFIG_PROVE_RCU=y kernels.
> > >
> > > Most of the RCU users (in core kernel/, drivers/, and net/
> > > subsystem) have already been modified to include lockdep
> > > expressions hence RCU list debugging can be enabled by
> > > default.
> > >
> > > However, there are still chances of enountering
> > > false-positive lockdep splats because not everything is converted,
> > > in case RCU list primitives are used in non-RCU read-side critical
> > > section but under the protection of a lock. It would be okay to
> > > have a few false-positives, as long as bugs are identified, since this
> > > patch only affects debugging kernels.
> > >
> > > Co-developed-by: Amol Grover <frextrite@xxxxxxxxx>
> > > Signed-off-by: Amol Grover <frextrite@xxxxxxxxx>
> > > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@xxxxxxxxx>
> >
> > Who is going to fix the fallout ?
> >
> > fs/btrfs/block-group.c:2011 RCU-list traversed in non-reader section!!
> > kernel/kprobes.c:329 RCU-list traversed in non-reader section!!
> > net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
> >
> Hi,
> There is already a patch for fixing the warnings in kernel/kprobes.c :
> https://lore.kernel.org/lkml/157905963533.2268.4672153983131918123.stgit@devnote2/
>
> Same for net/ipv4/ipmr:
> https://lore.kernel.org/patchwork/patch/1198934/
>
> Can you please send the warning with the stack backtrace and locks held
> for btrfs/block-group.c, I will work on it.
>

See below. I think that should be easy to reproduce by mounting
a btrfs file system.

Guenter

---
[ 28.920119] BTRFS: device fsid afe7540f-98fe-4a5c-ba94-3fb85a5da345 devid 1 transid 6 /dev/root scanned by swapper/0 (1)
[ 28.961347] BTRFS info (device sda): disk space caching is enabled
[ 28.963199] BTRFS info (device sda): has skinny extents
[ 28.963427] BTRFS info (device sda): flagging fs with big metadata feature
[ 29.104392]
[ 29.104591] =============================
[ 29.104756] WARNING: suspicious RCU usage
[ 29.105046] 5.6.0-rc4-next-20200305 #1 Not tainted
[ 29.105231] -----------------------------
[ 29.105401] fs/btrfs/block-group.c:2011 RCU-list traversed in non-reader section!!
[ 29.105643]
[ 29.105643] other info that might help us debug this:
[ 29.105643]
[ 29.106344]
[ 29.106344] rcu_scheduler_active = 2, debug_locks = 1
[ 29.106590] 1 lock held by swapper/0/1:
[ 29.106776] #0: ffff0000199e90d8 (&type->s_umount_key#23/1){+.+.}, at: alloc_super+0xac/0x2c0
[ 29.107436]
[ 29.107436] stack backtrace:
[ 29.107784] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-20200305 #1
[ 29.107989] Hardware name: linux,dummy-virt (DT)
[ 29.108344] Call trace:
[ 29.108488] dump_backtrace+0x0/0x1a0
[ 29.108638] show_stack+0x14/0x20
[ 29.108784] dump_stack+0xe8/0x150
[ 29.108921] lockdep_rcu_suspicious+0xf8/0x108
[ 29.109071] btrfs_read_block_groups+0x754/0x860
[ 29.109222] open_ctree+0xe74/0x1580
[ 29.109359] btrfs_mount_root+0x3cc/0x4c0
[ 29.109514] legacy_get_tree+0x2c/0x60
[ 29.109653] vfs_get_tree+0x24/0xe8
[ 29.109872] fc_mount+0x14/0x50
[ 29.110010] vfs_kern_mount.part.41+0x68/0x98
[ 29.110158] vfs_kern_mount+0x10/0x20
[ 29.110297] btrfs_mount+0x158/0x4b0
[ 29.110434] legacy_get_tree+0x2c/0x60
[ 29.110573] vfs_get_tree+0x24/0xe8
[ 29.110709] do_mount+0x568/0x998
[ 29.110849] do_mount_root+0x8c/0x11c
[ 29.110990] mount_block_root+0x114/0x244
[ 29.111134] mount_root+0x124/0x154
[ 29.111272] prepare_namespace+0x128/0x164
[ 29.111417] kernel_init_freeable+0x298/0x2b8
[ 29.111569] kernel_init+0x10/0x100
[ 29.111710] ret_from_fork+0x10/0x18