[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CANpmjNP5=ZyrnueXnYJU-ZN7VUgwnG5w4GFVLja9oN1LfHFpjg@mail.gmail.com>
Date: Thu, 16 Jan 2020 20:00:22 +0100
From: Marco Elver <elver@...gle.com>
To: "Paul E. McKenney" <paulmck@...nel.org>
Cc: Andrey Konovalov <andreyknvl@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
kasan-dev <kasan-dev@...glegroups.com>,
LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Qian Cai <cai@....pw>
Subject: Re: [PATCH -rcu v2] kcsan: Make KCSAN compatible with lockdep
On Thu, 16 Jan 2020 at 18:43, Paul E. McKenney <paulmck@...nel.org> wrote:
>
> On Wed, Jan 15, 2020 at 05:25:12PM +0100, Marco Elver wrote:
> > We must avoid any recursion into lockdep if KCSAN is enabled on
> > utilities used by lockdep. One manifestation of this is corrupting
> > lockdep's IRQ trace state (if TRACE_IRQFLAGS). Fix this by:
> >
> > 1. Using raw_local_irq{save,restore} in kcsan_setup_watchpoint().
> > 2. Disabling lockdep in kcsan_report().
> >
> > Tested with:
> >
> > CONFIG_LOCKDEP=y
> > CONFIG_DEBUG_LOCKDEP=y
> > CONFIG_TRACE_IRQFLAGS=y
> >
> > Where previously, the following warning (and variants with different
> > stack traces) was consistently generated, with the fix introduced in
> > this patch, the warning cannot be reproduced.
Qian, thank you for testing!
> I added Vlad's ack and Qian's Tested-by and queued this. Thank you all!
Thank you, Paul!
-- Marco
Powered by blists - more mailing lists