Re: [PATCH 0/5] rcu: Record callback enqueue stacks and add torture tests

[Joel Fernandes <joelagnelf@nvidia.com>]

On 11/6/2026 9:39 AM, Kunwu Chan wrote:
> This series adds KASAN auxiliary stack recording for RCU Tasks
> callbacks, rcutorture coverage for duplicate-callback detection,
> and KASAN aux-stack verification tests across RCU and SRCU flavors.
> 
> This series is based on [1]. For testing, I also applied Joel
> Fernandes' fix for debugobjects tracking of barrier callbacks
> [2], which is needed for the barrier tests.
> 
> The changes:
> - Record the enqueueing stack in call_rcu_tasks_generic().
> - Enable duplicate-callback testing for the "tasks" and
>   "tasks-tracing" torture types.
> - Add a KASAN aux-stack verification test module with a Kconfig
>   choice for each supported flavor.
> - Add one rcutorture scenario per flavor for the verification
>   test.
> 
> Tested on x86_64:
> 
> - TASKS01, TASKS02, TASKS03, TRACE01, and TRACE02 completed
>   3-minute runs successfully.
> 
> - With CONFIG_DEBUG_OBJECTS_RCU_HEAD=y and
>   rcutorture.object_debug=1, duplicate-callback detection was
>   triggered as expected for both torture types.
> 
> - TRACE01 was run for 1 minute with
>   CONFIG_DEBUG_OBJECTS_RCU_HEAD=y and
>   rcutorture.object_debug=1. The test detected both duplicate
>   callback heads through the SRCU enqueue path:
> [    0.405836] rcutorture: WARN: Duplicate call_tasks-tracing() test starting.
> [    0.405852] ODEBUG: activate active (active state 1) object: 0000000020df980d object type: rcu_head hint: 0x0
> [    0.734724] rcu: __call_srcu(): Duplicate call_srcu() CB 0000000020df980d->rcu_torture_leak_cb+0x0/0x10()
> [    0.734780] ODEBUG: activate active (active state 1) object: 000000006634e8c9 object type: rcu_head hint: 0x0
> [    0.776688] rcu: __call_srcu(): Duplicate call_srcu() CB 000000006634e8c9->rcu_torture_leak_cb+0x0/0x10()
> [    0.779126] rcutorture: WARN: Duplicate call_tasks-tracing() test complete.
> [   65.411342] tasks-tracing-torture:--- End of test: SUCCESS: ...
> 
> Both duplicate callback heads (the stack-allocated rh2 and
> the kmalloc-allocated rhp) were rejected and neither was invoked.
> 
> - With CONFIG_DEBUG_OBJECTS_RCU_HEAD=y,
>   object_debug=1, and n_barrier_cbs=4, the TASKS01 barrier
>   test completed 630/630 rounds without barrier errors.
>   The only debugobjects warnings were the four intentional
>   warnings from the duplicate-callback test at startup.
> 
> - All five aux-stack scenarios (TASKSKASAN01, TREEKASAN01,
>   SRCUKASAN01, TINYKASAN01, and SRCUTINYKASAN01) produced the
>   expected KASAN use-after-free reports. Each report's
>   "Last potentially related work creation" entry showed the
>   expected enqueue helper:
> 
> ===== TASKSKASAN01 =====
> [    1.244567] BUG: KASAN: slab-use-after-free in aux_test_init+0x8d/0xb0
> [    1.244707] Last potentially related work creation:
> [    1.244716]  aux_test_call_rcu_tasks.constprop.0+0xc/0x20
> 
> ===== TREEKASAN01 =====
> [    0.670399] BUG: KASAN: slab-use-after-free in aux_test_init+0x8d/0xb0
> [    0.670561] Last potentially related work creation:
> [    0.670571]  aux_test_call_rcu_tree.constprop.0+0xc/0x20
> 
> ===== SRCUKASAN01 =====
> [    0.658679] BUG: KASAN: slab-use-after-free in aux_test_init+0x94/0xc0
> [    0.658919] Last potentially related work creation:
> [    0.658932]  aux_test_call_srcu.constprop.0+0x16/0x30
> 
> ===== TINYKASAN01 =====
> [    0.951503] BUG: KASAN: slab-use-after-free in aux_test_init+0x8d/0xb0
> [    0.951641] Last potentially related work creation:
> [    0.951650]  aux_test_call_rcu_tiny.constprop.0+0xc/0x20
> 
> ===== SRCUTINYKASAN01 =====
> [    1.009005] BUG: KASAN: slab-use-after-free in aux_test_init+0x94/0xc0
> [    1.009141] Last potentially related work creation:
> [    1.009150]  aux_test_call_srcu.constprop.0+0x16/0x30
> 
> 

I'm not feeling very excited about adding more configs just for KASAN. That
sounds like a maintenance burden. I believe Paul already has KASAN testing in
his scripts. Is it possible to activate this testing only when those are enabled?

Thanks.