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] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Dec 2021 12:02:21 +0100
From:   Marco Elver <elver@...gle.com>
To:     "Zhang, Qiang1" <qiang1.zhang@...el.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

On Fri, 24 Dec 2021 at 04:23, Zhang, Qiang1 <qiang1.zhang@...el.com> wrote:
>
>
> On Wed, 22 Dec 2021 at 08:54, Zqiang <qiang1.zhang@...el.com> wrote:
> > The kasan_record_aux_stack_noalloc() only record stack, it doesn't
> > need to be called in local_irq_save()/restore() critical area, and the
> > global spinlock (depot_lock) will be acquired in this function, When
> > enable kasan stack, locking contention may increase the time in the critical area.
> >
> >I think the change itself is harmless, because
> >kasan_record_aux_stack_noalloc() doesn't care if interrupts are enabled or not when called, but the justification isn't clear to me.
> >
> >What "locking contention" are you speaking about? You're moving a
> >local_irq_save() which disables interrupts. Yes, it might be nice to reduce the time interrupts are disabled, but in this case the benefit (if any) isn't clear at all, also because this only benefits non-production KASAN kernels.
> >
> >Can you provide better justification? Did you encounter a specific problem, maybe together with data?
> >
>
> Thanks for reply, Yes, this only benefits non-production KASAN kernel.  In KASAN kernel,
> there may be a lot of call stack recorded, in addition to locking competition, the find_stack()  will
> also take a long time.

But there's no locking here, it's disabling interrupts. Yes, a lock is
taken inside kasan_record_aux_stack_noalloc(), but that's not one you
can do much about.

I don't mind this patch, but I think there might be some confusion. A
better explanation (in commit message or otherwise) would help make
sure we're not talking about different things.