* [PATCH] lockdep: fix warning in case of no_validate lock
@ 2016-07-13 3:06 Ming Lei
2016-08-09 11:17 ` Ming Lei
2016-08-09 12:53 ` Peter Zijlstra
0 siblings, 2 replies; 3+ messages in thread
From: Ming Lei @ 2016-07-13 3:06 UTC (permalink / raw)
To: linux-kernel; +Cc: Ming Lei, Peter Zijlstra, Ingo Molnar
Now there are several locks which are marked as
no_validate, so name of the lock class can be
different with the no_validate lock.
This patch avoids this warning for this case, and
fix the following warning:
[ 14.413292] ------------[ cut here ]------------
[ 14.413297] WARNING: CPU: 1 PID: 1434 at kernel/locking/lockdep.c:704
register_lock_class+0x44a/0x4f0
[ 14.413298] Modules linked in: bcache raid1 psmouse dax_pmem dax nd_pmem
serio_raw nvme nd_btt nvme_core floppy null_blk configs autofs4
[ 14.413309] CPU: 1 PID: 1434 Comm: bcache-register Tainted: G
W 4.7.0-rc6-next-20160708+ #2069
[ 14.413310] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
rel-1.9.0-0-g01a84be-prebuilt.qemu-project.org 04/01/2014
[ 14.413311] 0000000000000000 ffff880076973900 ffffffffba459dec 0000000000000000
[ 14.413313] 0000000000000000 ffff880076973940 ffffffffba08af71 000002c0ba1312a2
[ 14.413316] ffffffffbb9fd1e0 0000000000000000 0000000000000000 ffff880074d078d0
[ 14.413318] Call Trace:
[ 14.413321] [<ffffffffba459dec>] dump_stack+0x85/0xc9
[ 14.413323] [<ffffffffba08af71>] __warn+0xd1/0xf0
[ 14.413324] [<ffffffffba08b05d>] warn_slowpath_null+0x1d/0x20
[ 14.413326] [<ffffffffba0e5b8a>] register_lock_class+0x44a/0x4f0
[ 14.413328] [<ffffffffba0e81a5>] __lock_acquire+0x85/0x1920
[ 14.413330] [<ffffffffba06c893>] ? kvm_clock_read+0x23/0x40
[ 14.413332] [<ffffffffba03ebc9>] ? sched_clock+0x9/0x10
[ 14.413334] [<ffffffffba0c5568>] ? sched_clock_local+0x18/0x80
[ 14.413336] [<ffffffffba0ea0c4>] lock_acquire+0xd4/0x240
[ 14.413342] [<ffffffffc02f29b4>] ? mca_reap+0x54/0x180 [bcache]
[ 14.413343] [<ffffffffba0e3937>] down_write_trylock+0x67/0x80
[ 14.413347] [<ffffffffc02f29b4>] ? mca_reap+0x54/0x180 [bcache]
[ 14.413351] [<ffffffffc02f29b4>] mca_reap+0x54/0x180 [bcache]
[ 14.413354] [<ffffffffc02f2e62>] mca_alloc+0xc2/0x5a0 [bcache]
[ 14.413358] [<ffffffffc02f39f3>] bch_btree_node_get+0x143/0x290 [bcache]
[ 14.413364] [<ffffffffc0305939>] run_cache_set+0x239/0x8f0 [bcache]
[ 14.413368] [<ffffffffc0307c12>] register_bcache+0x14d2/0x1a30 [bcache]
[ 14.413370] [<ffffffffba80191b>] ? mutex_lock_nested+0x2db/0x460
[ 14.413372] [<ffffffffba45c52f>] kobj_attr_store+0xf/0x20
[ 14.413374] [<ffffffffba2f5f44>] sysfs_kf_write+0x44/0x60
[ 14.413376] [<ffffffffba2f54d4>] kernfs_fop_write+0x144/0x1e0
[ 14.413378] [<ffffffffba265728>] __vfs_write+0x28/0x120
[ 14.413380] [<ffffffffba0e3bd7>] ? percpu_down_read+0x57/0x90
[ 14.413381] [<ffffffffba26910a>] ? __sb_start_write+0xca/0xe0
[ 14.413382] [<ffffffffba26910a>] ? __sb_start_write+0xca/0xe0
[ 14.413383] [<ffffffffba265e35>] vfs_write+0xb5/0x1b0
[ 14.413385] [<ffffffffba0e7ccf>] ? trace_hardirqs_on_caller+0xef/0x210
[ 14.413386] [<ffffffffba2671c9>] SyS_write+0x49/0xa0
[ 14.413388] [<ffffffffba806ec0>] entry_SYSCALL_64_fastpath+0x23/0xc1
[ 14.413391] [<ffffffffba478c93>] ? __this_cpu_preempt_check+0x13/0x20
[ 14.413392] ---[ end trace 16710c495b4dbf2f ]---
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
---
kernel/locking/lockdep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 589d763..cf071ec 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -701,7 +701,8 @@ look_up_lock_class(struct lockdep_map *lock, unsigned int subclass)
* Huh! same key, different name? Did someone trample
* on some memory? We're most confused.
*/
- WARN_ON_ONCE(class->name != lock->name);
+ WARN_ON_ONCE(lock->key != &__lockdep_no_validate__ &&
+ class->name != lock->name);
return class;
}
}
--
1.9.1
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] lockdep: fix warning in case of no_validate lock
2016-07-13 3:06 [PATCH] lockdep: fix warning in case of no_validate lock Ming Lei
@ 2016-08-09 11:17 ` Ming Lei
2016-08-09 12:53 ` Peter Zijlstra
1 sibling, 0 replies; 3+ messages in thread
From: Ming Lei @ 2016-08-09 11:17 UTC (permalink / raw)
To: Linux Kernel Mailing List; +Cc: Ming Lei, Peter Zijlstra, Ingo Molnar
Hello,
Ping...
Thanks,
On Wed, Jul 13, 2016 at 11:06 AM, Ming Lei <tom.leiming@gmail.com> wrote:
> Now there are several locks which are marked as
> no_validate, so name of the lock class can be
> different with the no_validate lock.
>
> This patch avoids this warning for this case, and
> fix the following warning:
>
> [ 14.413292] ------------[ cut here ]------------
> [ 14.413297] WARNING: CPU: 1 PID: 1434 at kernel/locking/lockdep.c:704
> register_lock_class+0x44a/0x4f0
> [ 14.413298] Modules linked in: bcache raid1 psmouse dax_pmem dax nd_pmem
> serio_raw nvme nd_btt nvme_core floppy null_blk configs autofs4
> [ 14.413309] CPU: 1 PID: 1434 Comm: bcache-register Tainted: G
> W 4.7.0-rc6-next-20160708+ #2069
> [ 14.413310] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
> rel-1.9.0-0-g01a84be-prebuilt.qemu-project.org 04/01/2014
> [ 14.413311] 0000000000000000 ffff880076973900 ffffffffba459dec 0000000000000000
> [ 14.413313] 0000000000000000 ffff880076973940 ffffffffba08af71 000002c0ba1312a2
> [ 14.413316] ffffffffbb9fd1e0 0000000000000000 0000000000000000 ffff880074d078d0
> [ 14.413318] Call Trace:
> [ 14.413321] [<ffffffffba459dec>] dump_stack+0x85/0xc9
> [ 14.413323] [<ffffffffba08af71>] __warn+0xd1/0xf0
> [ 14.413324] [<ffffffffba08b05d>] warn_slowpath_null+0x1d/0x20
> [ 14.413326] [<ffffffffba0e5b8a>] register_lock_class+0x44a/0x4f0
> [ 14.413328] [<ffffffffba0e81a5>] __lock_acquire+0x85/0x1920
> [ 14.413330] [<ffffffffba06c893>] ? kvm_clock_read+0x23/0x40
> [ 14.413332] [<ffffffffba03ebc9>] ? sched_clock+0x9/0x10
> [ 14.413334] [<ffffffffba0c5568>] ? sched_clock_local+0x18/0x80
> [ 14.413336] [<ffffffffba0ea0c4>] lock_acquire+0xd4/0x240
> [ 14.413342] [<ffffffffc02f29b4>] ? mca_reap+0x54/0x180 [bcache]
> [ 14.413343] [<ffffffffba0e3937>] down_write_trylock+0x67/0x80
> [ 14.413347] [<ffffffffc02f29b4>] ? mca_reap+0x54/0x180 [bcache]
> [ 14.413351] [<ffffffffc02f29b4>] mca_reap+0x54/0x180 [bcache]
> [ 14.413354] [<ffffffffc02f2e62>] mca_alloc+0xc2/0x5a0 [bcache]
> [ 14.413358] [<ffffffffc02f39f3>] bch_btree_node_get+0x143/0x290 [bcache]
> [ 14.413364] [<ffffffffc0305939>] run_cache_set+0x239/0x8f0 [bcache]
> [ 14.413368] [<ffffffffc0307c12>] register_bcache+0x14d2/0x1a30 [bcache]
> [ 14.413370] [<ffffffffba80191b>] ? mutex_lock_nested+0x2db/0x460
> [ 14.413372] [<ffffffffba45c52f>] kobj_attr_store+0xf/0x20
> [ 14.413374] [<ffffffffba2f5f44>] sysfs_kf_write+0x44/0x60
> [ 14.413376] [<ffffffffba2f54d4>] kernfs_fop_write+0x144/0x1e0
> [ 14.413378] [<ffffffffba265728>] __vfs_write+0x28/0x120
> [ 14.413380] [<ffffffffba0e3bd7>] ? percpu_down_read+0x57/0x90
> [ 14.413381] [<ffffffffba26910a>] ? __sb_start_write+0xca/0xe0
> [ 14.413382] [<ffffffffba26910a>] ? __sb_start_write+0xca/0xe0
> [ 14.413383] [<ffffffffba265e35>] vfs_write+0xb5/0x1b0
> [ 14.413385] [<ffffffffba0e7ccf>] ? trace_hardirqs_on_caller+0xef/0x210
> [ 14.413386] [<ffffffffba2671c9>] SyS_write+0x49/0xa0
> [ 14.413388] [<ffffffffba806ec0>] entry_SYSCALL_64_fastpath+0x23/0xc1
> [ 14.413391] [<ffffffffba478c93>] ? __this_cpu_preempt_check+0x13/0x20
> [ 14.413392] ---[ end trace 16710c495b4dbf2f ]---
>
> Signed-off-by: Ming Lei <tom.leiming@gmail.com>
> ---
> kernel/locking/lockdep.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 589d763..cf071ec 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -701,7 +701,8 @@ look_up_lock_class(struct lockdep_map *lock, unsigned int subclass)
> * Huh! same key, different name? Did someone trample
> * on some memory? We're most confused.
> */
> - WARN_ON_ONCE(class->name != lock->name);
> + WARN_ON_ONCE(lock->key != &__lockdep_no_validate__ &&
> + class->name != lock->name);
> return class;
> }
> }
> --
> 1.9.1
>
--
Ming Lei
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] lockdep: fix warning in case of no_validate lock
2016-07-13 3:06 [PATCH] lockdep: fix warning in case of no_validate lock Ming Lei
2016-08-09 11:17 ` Ming Lei
@ 2016-08-09 12:53 ` Peter Zijlstra
1 sibling, 0 replies; 3+ messages in thread
From: Peter Zijlstra @ 2016-08-09 12:53 UTC (permalink / raw)
To: Ming Lei; +Cc: linux-kernel, Ingo Molnar
On Wed, Jul 13, 2016 at 11:06:36AM +0800, Ming Lei wrote:
> Now there are several locks which are marked as
> no_validate, so name of the lock class can be
> different with the no_validate lock.
Hurgh, how did that happen? See checkpatch saying:
scripts/checkpatch.pl: "lockdep_no_validate class is reserved for device->mutex.\n" . $herecurr);
> This patch avoids this warning for this case, and
> fix the following warning:
I'm not sure we want that.. given we should strive for less no_validate
usage, not more.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-08-09 12:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-13 3:06 [PATCH] lockdep: fix warning in case of no_validate lock Ming Lei
2016-08-09 11:17 ` Ming Lei
2016-08-09 12:53 ` Peter Zijlstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome