linux-kernel - RE: [PATCH] rcu: record kasan stack before enter local_irq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <PH0PR11MB5880465752E5D5F37C4FF1D0DA409@PH0PR11MB5880.namprd11.prod.outlook.com>
Date:   Sat, 25 Dec 2021 10:48:02 +0000
From:   "Zhang, Qiang1" <qiang1.zhang@...el.com>
To:     Marco Elver <elver@...gle.com>
CC:     "paulmck@...nel.org" <paulmck@...nel.org>,
        "ryabinin.a.a@...il.com" <ryabinin.a.a@...il.com>,
        "urezki@...il.com" <urezki@...il.com>,
        "Miao, Jun" <jun.miao@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] rcu: record kasan stack before enter
 local_irq_save()/restore() critical area


>> Hi Marco, Are the following modifications clear to you?

>>I understood now that the contention you're talking about is from depot_lock, which wasn't clear before (I thought you ?intended to reduce contention by shortening some other critical section).

Sorry, I didn't explain clearly before.

> Subject: [PATCH] rcu: Reduce the consumption time of
>  local_irq_save()/restore() critical area

>>Subject: rcu, kasan: Record work creation stack trace with interrupts enabled

> In non-production KASAN kernel, a large number of call stacks are 
> recorded, it takes some time to acquire the global 
> spinlock(depot_lock) inside kasan_record_aux_stack_noalloc(), 
> increased interrupts disable time,
> kasan_record_aux_stack_noalloc() doesn't care if interrupts are 
> enabled or not when called, so move it outside the critical area.

>>I think this might be clearer:

>>"Recording the work creation stack trace for KASAN reports in
>>call_rcu() is expensive, due to unwinding the stack, but also due to acquiring depot_lock inside stackdepot (which may be contended).
>>Because calling kasan_record_aux_stack_noalloc() does not require interrupts to already be disabled, this may unnecessarily extend the time with interrupts disabled.
>>
>>, move calling kasan_record_aux_stack() before the section with interrupts disabled."


Thanks Marco, your description is clearer, I will resend it.


> Signed-off-by: Zqiang <qiang1.zhang@...el.com>

>>Acked-by: Marco Elver <elver@...gle.com>

> ---
>  kernel/rcu/tree.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 
> 9b58bae0527a..36bd3f9e57b3 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -3068,8 +3068,8 @@ void call_rcu(struct rcu_head *head, rcu_callback_t func)
>         }
>         head->func = func;
>         head->next = NULL;
> -       local_irq_save(flags);
>         kasan_record_aux_stack_noalloc(head);
> +       local_irq_save(flags);
>         rdp = this_cpu_ptr(&rcu_data);
>
> Thanks,
> Zqiang