[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKwvOdnTzcG0DY9SScu1JuV4Q0Ka60qm9jdK2TjA1Cav8En-mQ@mail.gmail.com>
Date: Mon, 26 Jun 2023 10:24:55 -0700
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Lukas Bulwahn <lukas.bulwahn@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Marco Elver <elver@...gle.com>,
clang-built-linux <llvm@...ts.linux.dev>
Subject: Re: Thread-safety annotations for irq/rcu/atomic contexts
(minus old ML, plus new ML)
On Mon, Jun 26, 2023 at 10:21 AM 'Dmitry Vyukov' via Clang Built Linux
<clang-built-linux@...glegroups.com> wrote:
>
> Hi,
>
> Previous Lukas' attempt to apply clang thread-safety annotations to the kernel:
> https://clangbuiltlinux.github.io/CBL-meetup-2020-slides/lukas/tsa.pdf
>
> I am thinking if the annotations can be used to check for functions
> that must/must not be called from irq/atomic/rcu_read/etc contexts.
> Namely, we create global fake locks that denote these contexts, then
> annotate spin_lock_irqsave/irqrestore/etc as taking releasing these
> locks, and finally annotate functions are requiring/excluding these
> contexts:
>
> void foo() require(irq_context);
> void bar() exclude(irq_context);
> void baz() require(rcu_read_context);
>
> This may help to catch "suspicious RCU usage", "scheduling while
> atomic" and similar bug types statically. I suspect it may also be
> simpler (?) to do rather than annotating all normal locks.
>
> Does it make any sense?
>
> --
> You received this message because you are subscribed to the Google Groups "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to clang-built-linux+unsubscribe@...glegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/clang-built-linux/CACT4Y%2Bbif9Wek-g10F5y0aLbH%3DJbCcqryi2nOUAFxGFo0O2B9A%40mail.gmail.com.
--
Thanks,
~Nick Desaulniers
Powered by blists - more mailing lists