* [BUG] KASAN "INFO: trying to register non-static key"
@ 2024-01-09 14:02 Paul E. McKenney
2024-01-09 15:51 ` Liam R. Howlett
0 siblings, 1 reply; 6+ messages in thread
From: Paul E. McKenney @ 2024-01-09 14:02 UTC (permalink / raw)
To: andreyknvl, Liam.Howlett; +Cc: sfr, linux-next, kasan-dev
Hello!
I get the splat shown below when running rcutorture on next-20240108
(and some less-recent -next versions) on scenarios that run KASAN and
that also enable CONFIG_DEBUG_LOCK_ALLOC=y. I am running gcc 8.5.0.
Bisection fingers this commit:
a414d4286f34 ("kasan: handle concurrent kasan_record_aux_stack calls")
This commit does not appear to be trying to change the annotation
required of KASAN users, so I suspect that the commit is at fault. I am
including Liam in case Maple Tree is the bad guy, and should call_rcu()
need adjustment, here I am. ;-)
Thoughts?
Thanx, Paul
------------------------------------------------------------------------
[ 0.174878] INFO: trying to register non-static key.
[ 0.174879] The code is fine but needs lockdep annotation, or maybe
[ 0.174880] you didn't initialize this object before use?
[ 0.174881] turning off the locking correctness validator.
[ 0.174884] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc4-00331-ga414d4286f34 #39616
[ 0.174888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
[ 0.174891] Call Trace:
[ 0.174892] <TASK>
[ 0.174895] dump_stack_lvl+0x36/0x50
[ 0.174903] register_lock_class+0x1240/0x1880
[ 0.174910] ? kasan_save_stack+0x2e/0x40
[ 0.174916] ? kasan_save_stack+0x20/0x40
[ 0.174919] ? __kasan_record_aux_stack+0x91/0xe0
[ 0.174923] ? __call_rcu_common.constprop.84+0x99/0x740
[ 0.174927] ? mas_wr_node_store+0x8c6/0x1700
[ 0.174931] ? mas_wr_modify+0x274/0x2500
[ 0.174934] ? mas_wr_store_entry+0x3fa/0x1830
[ 0.174938] ? mas_store_gfp+0xaa/0x140
[ 0.174941] ? __pfx_register_lock_class+0x10/0x10
[ 0.174945] ? x86_64_start_reservations+0x18/0x30
[ 0.174952] ? x86_64_start_kernel+0x91/0xa0
[ 0.174956] ? secondary_startup_64_no_verify+0x178/0x17b
[ 0.174961] ? __pfx_lock_release+0x10/0x10
[ 0.174965] ? do_raw_spin_lock+0x125/0x290
[ 0.174968] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 0.174971] __lock_acquire.isra.27+0x81/0x10d0
[ 0.174976] ? _raw_spin_unlock_irqrestore+0x22/0x50
[ 0.174982] ? debug_object_active_state+0x2e7/0x430
[ 0.174988] lock_acquire+0x11e/0x280
[ 0.174992] ? __kasan_record_aux_stack+0xa1/0xe0
[ 0.174996] _raw_spin_lock_irqsave+0x2f/0x50
[ 0.175000] ? __kasan_record_aux_stack+0xa1/0xe0
[ 0.175003] __kasan_record_aux_stack+0xa1/0xe0
[ 0.175006] ? __pfx_mt_free_rcu+0x10/0x10
[ 0.175009] __call_rcu_common.constprop.84+0x99/0x740
[ 0.175012] ? mas_alloc_nodes+0x3e7/0x750
[ 0.175015] ? mas_pop_node+0x192/0x290
[ 0.175018] mas_wr_node_store+0x8c6/0x1700
[ 0.175022] ? __free_zapped_classes+0x2af/0x2f0
[ 0.175026] ? lock_release+0x1e3/0x660
[ 0.175030] ? __pfx_mas_wr_node_store+0x10/0x10
[ 0.175033] ? __pfx_lock_release+0x10/0x10
[ 0.175038] ? lock_acquire+0x11e/0x280
[ 0.175042] ? stack_depot_save_flags+0x148/0x650
[ 0.175047] ? find_held_lock+0x33/0x1c0
[ 0.175051] ? lock_release+0x1e3/0x660
[ 0.175054] ? pcpu_alloc+0x81d/0xa30
[ 0.175059] ? stack_depot_save_flags+0x1da/0x650
[ 0.175062] ? __pfx_lock_release+0x10/0x10
[ 0.175066] ? register_lock_class+0xc9/0x1880
[ 0.175070] ? pcpu_alloc+0x60e/0xa30
[ 0.175074] mas_wr_modify+0x274/0x2500
[ 0.175078] ? __mutex_unlock_slowpath+0x176/0x660
[ 0.175083] mas_wr_store_entry+0x3fa/0x1830
[ 0.175088] mas_store_gfp+0xaa/0x140
[ 0.175092] ? __pfx_mas_store_gfp+0x10/0x10
[ 0.175097] ? lockdep_init_map_type+0x2c8/0x7a0
[ 0.175101] irq_insert_desc+0xaf/0x100
[ 0.175107] ? __pfx_irq_insert_desc+0x10/0x10
[ 0.175110] ? kobject_init+0x68/0x1e0
[ 0.175115] ? kmem_cache_create_usercopy+0xce/0x240
[ 0.175119] early_irq_init+0x10f/0x140
[ 0.175125] start_kernel+0x177/0x3a0
[ 0.175129] x86_64_start_reservations+0x18/0x30
[ 0.175133] x86_64_start_kernel+0x91/0xa0
[ 0.175138] secondary_startup_64_no_verify+0x178/0x17b
[ 0.175143] </TASK>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] KASAN "INFO: trying to register non-static key"
2024-01-09 14:02 [BUG] KASAN "INFO: trying to register non-static key" Paul E. McKenney
@ 2024-01-09 15:51 ` Liam R. Howlett
2024-01-09 16:07 ` Paul E. McKenney
2024-01-09 16:07 ` Andrey Konovalov
0 siblings, 2 replies; 6+ messages in thread
From: Liam R. Howlett @ 2024-01-09 15:51 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: andreyknvl, sfr, linux-next, kasan-dev
* Paul E. McKenney <paulmck@kernel.org> [240109 09:04]:
> Hello!
>
> I get the splat shown below when running rcutorture on next-20240108
> (and some less-recent -next versions) on scenarios that run KASAN and
> that also enable CONFIG_DEBUG_LOCK_ALLOC=y. I am running gcc 8.5.0.
>
> Bisection fingers this commit:
>
> a414d4286f34 ("kasan: handle concurrent kasan_record_aux_stack calls")
>
> This commit does not appear to be trying to change the annotation
> required of KASAN users, so I suspect that the commit is at fault. I am
> including Liam in case Maple Tree is the bad guy, and should call_rcu()
> need adjustment, here I am. ;-)
>
> Thoughts?
I think this is ma_free_rcu() registering mt_free_rcu() in
lib/maple_tree.c.
The commit you point to saves and restores the irq state in
__kasan_record_aux_stack(), but the trace below shows it is called prior
to irqs being initialized. This isn't what lockdep is yelling about, so
what am I missing? Maybe it will be caught after this issue is
resolved?
I am also guessing maple tree shows up in the stack trace because it is
the very first rcu user at boot (just like the rcutiny issue last time).
I'm just keeping everyone honest/angry.
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> [ 0.174878] INFO: trying to register non-static key.
> [ 0.174879] The code is fine but needs lockdep annotation, or maybe
> [ 0.174880] you didn't initialize this object before use?
> [ 0.174881] turning off the locking correctness validator.
> [ 0.174884] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc4-00331-ga414d4286f34 #39616
> [ 0.174888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> [ 0.174891] Call Trace:
> [ 0.174892] <TASK>
> [ 0.174895] dump_stack_lvl+0x36/0x50
> [ 0.174903] register_lock_class+0x1240/0x1880
> [ 0.174910] ? kasan_save_stack+0x2e/0x40
> [ 0.174916] ? kasan_save_stack+0x20/0x40
> [ 0.174919] ? __kasan_record_aux_stack+0x91/0xe0
> [ 0.174923] ? __call_rcu_common.constprop.84+0x99/0x740
> [ 0.174927] ? mas_wr_node_store+0x8c6/0x1700
> [ 0.174931] ? mas_wr_modify+0x274/0x2500
> [ 0.174934] ? mas_wr_store_entry+0x3fa/0x1830
> [ 0.174938] ? mas_store_gfp+0xaa/0x140
> [ 0.174941] ? __pfx_register_lock_class+0x10/0x10
> [ 0.174945] ? x86_64_start_reservations+0x18/0x30
> [ 0.174952] ? x86_64_start_kernel+0x91/0xa0
> [ 0.174956] ? secondary_startup_64_no_verify+0x178/0x17b
> [ 0.174961] ? __pfx_lock_release+0x10/0x10
> [ 0.174965] ? do_raw_spin_lock+0x125/0x290
> [ 0.174968] ? __pfx_do_raw_spin_lock+0x10/0x10
> [ 0.174971] __lock_acquire.isra.27+0x81/0x10d0
> [ 0.174976] ? _raw_spin_unlock_irqrestore+0x22/0x50
> [ 0.174982] ? debug_object_active_state+0x2e7/0x430
> [ 0.174988] lock_acquire+0x11e/0x280
> [ 0.174992] ? __kasan_record_aux_stack+0xa1/0xe0
> [ 0.174996] _raw_spin_lock_irqsave+0x2f/0x50
> [ 0.175000] ? __kasan_record_aux_stack+0xa1/0xe0
> [ 0.175003] __kasan_record_aux_stack+0xa1/0xe0
> [ 0.175006] ? __pfx_mt_free_rcu+0x10/0x10
> [ 0.175009] __call_rcu_common.constprop.84+0x99/0x740
> [ 0.175012] ? mas_alloc_nodes+0x3e7/0x750
> [ 0.175015] ? mas_pop_node+0x192/0x290
> [ 0.175018] mas_wr_node_store+0x8c6/0x1700
> [ 0.175022] ? __free_zapped_classes+0x2af/0x2f0
> [ 0.175026] ? lock_release+0x1e3/0x660
> [ 0.175030] ? __pfx_mas_wr_node_store+0x10/0x10
> [ 0.175033] ? __pfx_lock_release+0x10/0x10
> [ 0.175038] ? lock_acquire+0x11e/0x280
> [ 0.175042] ? stack_depot_save_flags+0x148/0x650
> [ 0.175047] ? find_held_lock+0x33/0x1c0
> [ 0.175051] ? lock_release+0x1e3/0x660
> [ 0.175054] ? pcpu_alloc+0x81d/0xa30
> [ 0.175059] ? stack_depot_save_flags+0x1da/0x650
> [ 0.175062] ? __pfx_lock_release+0x10/0x10
> [ 0.175066] ? register_lock_class+0xc9/0x1880
> [ 0.175070] ? pcpu_alloc+0x60e/0xa30
> [ 0.175074] mas_wr_modify+0x274/0x2500
> [ 0.175078] ? __mutex_unlock_slowpath+0x176/0x660
> [ 0.175083] mas_wr_store_entry+0x3fa/0x1830
> [ 0.175088] mas_store_gfp+0xaa/0x140
> [ 0.175092] ? __pfx_mas_store_gfp+0x10/0x10
> [ 0.175097] ? lockdep_init_map_type+0x2c8/0x7a0
> [ 0.175101] irq_insert_desc+0xaf/0x100
> [ 0.175107] ? __pfx_irq_insert_desc+0x10/0x10
> [ 0.175110] ? kobject_init+0x68/0x1e0
> [ 0.175115] ? kmem_cache_create_usercopy+0xce/0x240
> [ 0.175119] early_irq_init+0x10f/0x140
IRQs are not enabled at this point.
> [ 0.175125] start_kernel+0x177/0x3a0
> [ 0.175129] x86_64_start_reservations+0x18/0x30
> [ 0.175133] x86_64_start_kernel+0x91/0xa0
> [ 0.175138] secondary_startup_64_no_verify+0x178/0x17b
> [ 0.175143] </TASK>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] KASAN "INFO: trying to register non-static key"
2024-01-09 15:51 ` Liam R. Howlett
@ 2024-01-09 16:07 ` Paul E. McKenney
2024-01-09 16:07 ` Andrey Konovalov
1 sibling, 0 replies; 6+ messages in thread
From: Paul E. McKenney @ 2024-01-09 16:07 UTC (permalink / raw)
To: Liam R. Howlett; +Cc: andreyknvl, sfr, linux-next, kasan-dev
On Tue, Jan 09, 2024 at 10:51:27AM -0500, Liam R. Howlett wrote:
> * Paul E. McKenney <paulmck@kernel.org> [240109 09:04]:
> > Hello!
> >
> > I get the splat shown below when running rcutorture on next-20240108
> > (and some less-recent -next versions) on scenarios that run KASAN and
> > that also enable CONFIG_DEBUG_LOCK_ALLOC=y. I am running gcc 8.5.0.
> >
> > Bisection fingers this commit:
> >
> > a414d4286f34 ("kasan: handle concurrent kasan_record_aux_stack calls")
> >
> > This commit does not appear to be trying to change the annotation
> > required of KASAN users, so I suspect that the commit is at fault. I am
> > including Liam in case Maple Tree is the bad guy, and should call_rcu()
> > need adjustment, here I am. ;-)
> >
> > Thoughts?
>
>
> I think this is ma_free_rcu() registering mt_free_rcu() in
> lib/maple_tree.c.
>
> The commit you point to saves and restores the irq state in
> __kasan_record_aux_stack(), but the trace below shows it is called prior
> to irqs being initialized. This isn't what lockdep is yelling about, so
> what am I missing? Maybe it will be caught after this issue is
> resolved?
>
> I am also guessing maple tree shows up in the stack trace because it is
> the very first rcu user at boot (just like the rcutiny issue last time).
> I'm just keeping everyone honest/angry.
That is my guess as well, but I wouldn't want you to feel left out. ;-)
Thanx, Paul
> > ------------------------------------------------------------------------
> >
> > [ 0.174878] INFO: trying to register non-static key.
> > [ 0.174879] The code is fine but needs lockdep annotation, or maybe
> > [ 0.174880] you didn't initialize this object before use?
> > [ 0.174881] turning off the locking correctness validator.
> > [ 0.174884] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-rc4-00331-ga414d4286f34 #39616
> > [ 0.174888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
> > [ 0.174891] Call Trace:
> > [ 0.174892] <TASK>
> > [ 0.174895] dump_stack_lvl+0x36/0x50
> > [ 0.174903] register_lock_class+0x1240/0x1880
> > [ 0.174910] ? kasan_save_stack+0x2e/0x40
> > [ 0.174916] ? kasan_save_stack+0x20/0x40
> > [ 0.174919] ? __kasan_record_aux_stack+0x91/0xe0
> > [ 0.174923] ? __call_rcu_common.constprop.84+0x99/0x740
> > [ 0.174927] ? mas_wr_node_store+0x8c6/0x1700
> > [ 0.174931] ? mas_wr_modify+0x274/0x2500
> > [ 0.174934] ? mas_wr_store_entry+0x3fa/0x1830
> > [ 0.174938] ? mas_store_gfp+0xaa/0x140
> > [ 0.174941] ? __pfx_register_lock_class+0x10/0x10
> > [ 0.174945] ? x86_64_start_reservations+0x18/0x30
> > [ 0.174952] ? x86_64_start_kernel+0x91/0xa0
> > [ 0.174956] ? secondary_startup_64_no_verify+0x178/0x17b
> > [ 0.174961] ? __pfx_lock_release+0x10/0x10
> > [ 0.174965] ? do_raw_spin_lock+0x125/0x290
> > [ 0.174968] ? __pfx_do_raw_spin_lock+0x10/0x10
> > [ 0.174971] __lock_acquire.isra.27+0x81/0x10d0
> > [ 0.174976] ? _raw_spin_unlock_irqrestore+0x22/0x50
> > [ 0.174982] ? debug_object_active_state+0x2e7/0x430
> > [ 0.174988] lock_acquire+0x11e/0x280
> > [ 0.174992] ? __kasan_record_aux_stack+0xa1/0xe0
> > [ 0.174996] _raw_spin_lock_irqsave+0x2f/0x50
> > [ 0.175000] ? __kasan_record_aux_stack+0xa1/0xe0
> > [ 0.175003] __kasan_record_aux_stack+0xa1/0xe0
> > [ 0.175006] ? __pfx_mt_free_rcu+0x10/0x10
> > [ 0.175009] __call_rcu_common.constprop.84+0x99/0x740
> > [ 0.175012] ? mas_alloc_nodes+0x3e7/0x750
> > [ 0.175015] ? mas_pop_node+0x192/0x290
> > [ 0.175018] mas_wr_node_store+0x8c6/0x1700
> > [ 0.175022] ? __free_zapped_classes+0x2af/0x2f0
> > [ 0.175026] ? lock_release+0x1e3/0x660
> > [ 0.175030] ? __pfx_mas_wr_node_store+0x10/0x10
> > [ 0.175033] ? __pfx_lock_release+0x10/0x10
> > [ 0.175038] ? lock_acquire+0x11e/0x280
> > [ 0.175042] ? stack_depot_save_flags+0x148/0x650
> > [ 0.175047] ? find_held_lock+0x33/0x1c0
> > [ 0.175051] ? lock_release+0x1e3/0x660
> > [ 0.175054] ? pcpu_alloc+0x81d/0xa30
> > [ 0.175059] ? stack_depot_save_flags+0x1da/0x650
> > [ 0.175062] ? __pfx_lock_release+0x10/0x10
> > [ 0.175066] ? register_lock_class+0xc9/0x1880
> > [ 0.175070] ? pcpu_alloc+0x60e/0xa30
> > [ 0.175074] mas_wr_modify+0x274/0x2500
> > [ 0.175078] ? __mutex_unlock_slowpath+0x176/0x660
> > [ 0.175083] mas_wr_store_entry+0x3fa/0x1830
> > [ 0.175088] mas_store_gfp+0xaa/0x140
> > [ 0.175092] ? __pfx_mas_store_gfp+0x10/0x10
> > [ 0.175097] ? lockdep_init_map_type+0x2c8/0x7a0
> > [ 0.175101] irq_insert_desc+0xaf/0x100
> > [ 0.175107] ? __pfx_irq_insert_desc+0x10/0x10
> > [ 0.175110] ? kobject_init+0x68/0x1e0
> > [ 0.175115] ? kmem_cache_create_usercopy+0xce/0x240
> > [ 0.175119] early_irq_init+0x10f/0x140
>
> IRQs are not enabled at this point.
>
> > [ 0.175125] start_kernel+0x177/0x3a0
> > [ 0.175129] x86_64_start_reservations+0x18/0x30
> > [ 0.175133] x86_64_start_kernel+0x91/0xa0
> > [ 0.175138] secondary_startup_64_no_verify+0x178/0x17b
> > [ 0.175143] </TASK>
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] KASAN "INFO: trying to register non-static key"
2024-01-09 15:51 ` Liam R. Howlett
2024-01-09 16:07 ` Paul E. McKenney
@ 2024-01-09 16:07 ` Andrey Konovalov
2024-01-09 17:20 ` Paul E. McKenney
1 sibling, 1 reply; 6+ messages in thread
From: Andrey Konovalov @ 2024-01-09 16:07 UTC (permalink / raw)
To: Liam R. Howlett, Paul E. McKenney; +Cc: sfr, linux-next, kasan-dev
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
On Tue, Jan 9, 2024 at 4:51 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * Paul E. McKenney <paulmck@kernel.org> [240109 09:04]:
> > Hello!
> >
> > I get the splat shown below when running rcutorture on next-20240108
> > (and some less-recent -next versions) on scenarios that run KASAN and
> > that also enable CONFIG_DEBUG_LOCK_ALLOC=y. I am running gcc 8.5.0.
> >
> > Bisection fingers this commit:
> >
> > a414d4286f34 ("kasan: handle concurrent kasan_record_aux_stack calls")
> >
> > This commit does not appear to be trying to change the annotation
> > required of KASAN users, so I suspect that the commit is at fault. I am
> > including Liam in case Maple Tree is the bad guy, and should call_rcu()
> > need adjustment, here I am. ;-)
> >
> > Thoughts?
>
>
> I think this is ma_free_rcu() registering mt_free_rcu() in
> lib/maple_tree.c.
>
> The commit you point to saves and restores the irq state in
> __kasan_record_aux_stack(), but the trace below shows it is called prior
> to irqs being initialized. This isn't what lockdep is yelling about, so
> what am I missing? Maybe it will be caught after this issue is
> resolved?
Hm, I see a discrepancy in the KASAN code related to the guilty
commit. I believed it to be harmless, but perhaps it is not.
Paul, could you check if the attached patch fixes the issue for you?
This is rather a quick fix than a proper one, but let's see if this
one works.
Thanks!
[-- Attachment #2: kasan_record_aux_stack-fix.patch --]
[-- Type: text/x-patch, Size: 968 bytes --]
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 223af53d4338..0143c1b82004 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -208,10 +208,6 @@ static inline u8 assign_tag(struct kmem_cache *cache,
void * __must_check __kasan_init_slab_obj(struct kmem_cache *cache,
const void *object)
{
- /* Initialize per-object metadata if it is present. */
- if (kasan_requires_meta())
- kasan_init_object_meta(cache, object);
-
/* Tag is ignored in set_tag() without CONFIG_KASAN_SW/HW_TAGS */
object = set_tag(object, assign_tag(cache, object, true));
@@ -338,6 +334,10 @@ void * __must_check __kasan_slab_alloc(struct kmem_cache *cache,
if (is_kfence_address(object))
return (void *)object;
+ /* Initialize per-object metadata if it is present. */
+ if (kasan_requires_meta())
+ kasan_init_object_meta(cache, object);
+
/*
* Generate and assign random tag for tag-based modes.
* Tag is ignored in set_tag() for the generic mode.
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [BUG] KASAN "INFO: trying to register non-static key"
2024-01-09 16:07 ` Andrey Konovalov
@ 2024-01-09 17:20 ` Paul E. McKenney
2024-01-09 22:16 ` Andrey Konovalov
0 siblings, 1 reply; 6+ messages in thread
From: Paul E. McKenney @ 2024-01-09 17:20 UTC (permalink / raw)
To: Andrey Konovalov; +Cc: Liam R. Howlett, sfr, linux-next, kasan-dev
On Tue, Jan 09, 2024 at 05:07:54PM +0100, Andrey Konovalov wrote:
> On Tue, Jan 9, 2024 at 4:51 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> >
> > * Paul E. McKenney <paulmck@kernel.org> [240109 09:04]:
> > > Hello!
> > >
> > > I get the splat shown below when running rcutorture on next-20240108
> > > (and some less-recent -next versions) on scenarios that run KASAN and
> > > that also enable CONFIG_DEBUG_LOCK_ALLOC=y. I am running gcc 8.5.0.
> > >
> > > Bisection fingers this commit:
> > >
> > > a414d4286f34 ("kasan: handle concurrent kasan_record_aux_stack calls")
> > >
> > > This commit does not appear to be trying to change the annotation
> > > required of KASAN users, so I suspect that the commit is at fault. I am
> > > including Liam in case Maple Tree is the bad guy, and should call_rcu()
> > > need adjustment, here I am. ;-)
> > >
> > > Thoughts?
> >
> >
> > I think this is ma_free_rcu() registering mt_free_rcu() in
> > lib/maple_tree.c.
> >
> > The commit you point to saves and restores the irq state in
> > __kasan_record_aux_stack(), but the trace below shows it is called prior
> > to irqs being initialized. This isn't what lockdep is yelling about, so
> > what am I missing? Maybe it will be caught after this issue is
> > resolved?
>
> Hm, I see a discrepancy in the KASAN code related to the guilty
> commit. I believed it to be harmless, but perhaps it is not.
>
> Paul, could you check if the attached patch fixes the issue for you?
> This is rather a quick fix than a proper one, but let's see if this
> one works.
>
> Thanks!
> diff --git a/mm/kasan/common.c b/mm/kasan/common.c
> index 223af53d4338..0143c1b82004 100644
> --- a/mm/kasan/common.c
> +++ b/mm/kasan/common.c
> @@ -208,10 +208,6 @@ static inline u8 assign_tag(struct kmem_cache *cache,
> void * __must_check __kasan_init_slab_obj(struct kmem_cache *cache,
> const void *object)
> {
> - /* Initialize per-object metadata if it is present. */
> - if (kasan_requires_meta())
> - kasan_init_object_meta(cache, object);
> -
> /* Tag is ignored in set_tag() without CONFIG_KASAN_SW/HW_TAGS */
> object = set_tag(object, assign_tag(cache, object, true));
>
> @@ -338,6 +334,10 @@ void * __must_check __kasan_slab_alloc(struct kmem_cache *cache,
> if (is_kfence_address(object))
> return (void *)object;
>
> + /* Initialize per-object metadata if it is present. */
> + if (kasan_requires_meta())
> + kasan_init_object_meta(cache, object);
> +
> /*
> * Generate and assign random tag for tag-based modes.
> * Tag is ignored in set_tag() for the generic mode.
Thank you!
But no joy, please see below.
Thanx, Paul
------------------------------------------------------------------------
[ 0.131589] INFO: trying to register non-static key.
[ 0.131590] The code is fine but needs lockdep annotation, or maybe
[ 0.131591] you didn't initialize this object before use?
[ 0.131592] turning off the locking correctness validator.
[ 0.131594] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.7.0-next-20240108-00001-g1dac0fe718dd #24
[ 0.131597] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014
[ 0.131599] Call Trace:
[ 0.131601] <TASK>
[ 0.131603] dump_stack_lvl+0x37/0x50
[ 0.131608] register_lock_class+0xba4/0xf30
[ 0.131612] ? x86_64_start_kernel+0xcf/0xe0
[ 0.131615] ? secondary_startup_64_no_verify+0x16d/0x17b
[ 0.131618] ? lock_release+0x1e1/0x690
[ 0.131621] ? __pfx_register_lock_class+0x10/0x10
[ 0.131624] ? lock_acquire+0x11f/0x290
[ 0.131626] ? debug_object_active_state+0x144/0x3e0
[ 0.131631] __lock_acquire.constprop.0+0x7e/0xe80
[ 0.131634] ? __pfx_lock_release+0x10/0x10
[ 0.131637] lock_acquire+0x11f/0x290
[ 0.131639] ? __kasan_record_aux_stack+0xa1/0xe0
[ 0.131644] _raw_spin_lock_irqsave+0x31/0x50
[ 0.131648] ? __kasan_record_aux_stack+0xa1/0xe0
[ 0.131651] __kasan_record_aux_stack+0xa1/0xe0
[ 0.131653] ? __pfx_mt_free_rcu+0x10/0x10
[ 0.131656] __call_rcu_common.constprop.0+0x99/0x750
[ 0.131659] ? mas_pop_node+0x12a/0x280
[ 0.131662] mas_wr_node_store+0x8c1/0x17e0
[ 0.131666] ? __pfx_register_lock_class+0x10/0x10
[ 0.131669] ? __pfx_mas_wr_node_store+0x10/0x10
[ 0.131671] ? pcpu_alloc+0x8c9/0xb10
[ 0.131676] ? find_held_lock+0x2c/0x110
[ 0.131678] ? __debug_object_init+0x2f7/0x450
[ 0.131681] ? lock_release+0x1e1/0x690
[ 0.131684] ? __pfx_lock_release+0x10/0x10
[ 0.131686] ? __pfx_do_raw_spin_lock+0x10/0x10
[ 0.131690] ? do_raw_spin_unlock+0x53/0x220
[ 0.131693] ? _raw_spin_unlock_irqrestore+0x22/0x50
[ 0.131697] mas_wr_store_entry.isra.0+0x40e/0x1480
[ 0.131700] ? __pfx___debug_object_init+0x10/0x10
[ 0.131704] mas_store_gfp+0xc2/0x1d0
[ 0.131707] ? __pfx_mas_store_gfp+0x10/0x10
[ 0.131712] ? alloc_desc+0x69b/0x990
[ 0.131715] early_irq_init+0x1c7/0x270
[ 0.131719] ? __pfx_early_irq_init+0x10/0x10
[ 0.131722] ? tracepoint_probe_register+0xaf/0xf0
[ 0.131727] ? kmem_cache_create_usercopy+0xce/0x230
[ 0.131731] start_kernel+0x162/0x390
[ 0.131734] x86_64_start_reservations+0x18/0x30
[ 0.131736] x86_64_start_kernel+0xcf/0xe0
[ 0.131738] secondary_startup_64_no_verify+0x16d/0x17b
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [BUG] KASAN "INFO: trying to register non-static key"
2024-01-09 17:20 ` Paul E. McKenney
@ 2024-01-09 22:16 ` Andrey Konovalov
0 siblings, 0 replies; 6+ messages in thread
From: Andrey Konovalov @ 2024-01-09 22:16 UTC (permalink / raw)
To: paulmck; +Cc: Liam R. Howlett, sfr, linux-next, kasan-dev
On Tue, Jan 9, 2024 at 6:20 PM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Thank you!
>
> But no joy, please see below.
I reproduced the issue and just sent the patch that fixes it for me.
Please let me know if the patch doesn't work for you.
Thank you for the report!
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-01-09 22:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-09 14:02 [BUG] KASAN "INFO: trying to register non-static key" Paul E. McKenney
2024-01-09 15:51 ` Liam R. Howlett
2024-01-09 16:07 ` Paul E. McKenney
2024-01-09 16:07 ` Andrey Konovalov
2024-01-09 17:20 ` Paul E. McKenney
2024-01-09 22:16 ` Andrey Konovalov
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.