"locking/lockdep: Consolidate lock usage bit initialization" is buggy

From: Qian Cai
Date: Thu Jun 06 2019 - 17:19:04 EST


The linux-next commit "locking/lockdep: Consolidate lock usage bit
initialization" [1] will always generate a warning below. Looking through the
commit that when mark_irqflags() returns 1 and check = 1, it will do one less
mark_lock() call than it used to.

[1] https://lore.kernel.org/lkml/tip-091806515124b20f8cff7927b4b7ff399483b109@gi
t.kernel.org/

# cat /proc/lockdep_stats,

[ 7410.877772] DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) !=
nr_unused)
[ 7410.877798] WARNING: CPU: 58 PID: 126655 at kernel/locking/lockdep_proc.c:249
lockdep_stats_show+0xe44/0x11e0
[ 7410.877841] Modules linked in: brd ext4 crc16 mbcache jbd2 loop i2c_opal
i2c_core ip_tables x_tables xfs sd_mod bnx2x ahci mdio libahci tg3 libphy libata
firmware_class dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
dummy_del_mod]
[ 7410.877954] CPU: 58 PID: 126655 Comm: proc01 Tainted:
GÂÂÂÂÂÂÂÂWÂÂOÂÂÂÂÂÂ5.2.0-rc3-next-20190606+ #2
[ 7410.877987] NIP:ÂÂc0000000001a4ae4 LR: c0000000001a4ae0 CTR: c0000000008afa30
[ 7410.878027] REGS: c00000176c5af8e0 TRAP: 0700ÂÂÂTainted:
GÂÂÂÂÂÂÂÂWÂÂOÂÂÂÂÂÂÂ(5.2.0-rc3-next-20190606+)
[ 7410.878059] MSR:ÂÂ9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE>ÂÂCR:
28888402ÂÂXER: 20040000
[ 7410.878101] CFAR: c000000000118c44 IRQMASK: 0Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR00: c0000000001a4ae0 c00000176c5afb70 c0000000016e5400
0000000000000044Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR04: c00000000171c250 c0000000001b44e8 4e5241575f534b43
75626564284e4f5fÂ
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR08: 0000001ffdf50000 0000000000000000 0000000000000000
212029736b636f6cÂ
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR12: 756e755f726e203d c000001ffffcfe00 0000000000000000
c0000000015ad1d0Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR16: 0000000000000000 0000000000000000 0000000000000000
0000000000000dd7Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR20: 0000000000000000 0000000000000000 0000000000000000
0000000000000000Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR24: 0000000000000000 0000000000000000 0000000000000000
c00000079dd0e158Â
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂGPR28: 0000000000000000 c00000000171c270 c00000000171c4c4
c00000000171ba18Â
[ 7410.878371] NIP [c0000000001a4ae4] lockdep_stats_show+0xe44/0x11e0
[ 7410.878406] LR [c0000000001a4ae0] lockdep_stats_show+0xe40/0x11e0
[ 7410.878443] Call Trace:
[ 7410.878468] [c00000176c5afb70] [c0000000001a4ae0]
lockdep_stats_show+0xe40/0x11e0 (unreliable)
[ 7410.878529] [c00000176c5afca0] [c000000000489c34] seq_read+0x1d4/0x620
[ 7410.878581] [c00000176c5afd30] [c00000000050cd40] proc_reg_read+0x90/0x130
[ 7410.878622] [c00000176c5afd60] [c00000000044b1cc] __vfs_read+0x3c/0x70
[ 7410.878653] [c00000176c5afd80] [c00000000044b2bc] vfs_read+0xbc/0x1a0
[ 7410.878680] [c00000176c5afdd0] [c00000000044b74c] ksys_read+0x7c/0x140
[ 7410.878722] [c00000176c5afe20] [c00000000000b108] system_call+0x5c/0x70
[ 7410.878773] Instruction dump:
[ 7410.878798] 419ef3b0 3d220004 3929abfc 81290000 2f890000 409ef39c 3c82ff33
3c62ff33Â
[ 7410.878843] 38840a98 3863f8a8 4bf74101 60000000 <0fe00000> 4bfff37c 60000000
39200000Â
[ 7410.878887] ---[ end trace 6a712a083aa01d23 ]---