On Thu, Jun 30, 2022 at 2:54 PM Vincent Whitchurch
<vincent.whitchurch@xxxxxxxx> wrote:
>
> On Thu, Jun 30, 2022 at 11:41:04AM +0200, Dmitry Vyukov wrote:
> > On Thu, 30 Jun 2022 at 10:08, David Gow <davidgow@xxxxxxxxxx> wrote:
> > > diff --git a/arch/um/kernel/Makefile b/arch/um/kernel/Makefile
> > > index 1c2d4b29a3d4..a089217e2f0e 100644
> > > --- a/arch/um/kernel/Makefile
> > > +++ b/arch/um/kernel/Makefile
> > > @@ -27,6 +27,9 @@ obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
> > > obj-$(CONFIG_STACKTRACE) += stacktrace.o
> > > obj-$(CONFIG_GENERIC_PCI_IOMAP) += ioport.o
> > >
> > > +KASAN_SANITIZE_stacktrace.o := n
> > > +KASAN_SANITIZE_sysrq.o := n
> >
> > Why are these needed?
> > It's helpful to leave some comments for any of *_SANITIZE:=n.
> > Otherwise later it's unclear if it's due to some latent bugs, some
> > inherent incompatibility, something that can be fixed, etc.
>
> I believe I saw the stacktrace code itself triggering KASAN splats and
> causing recursion when sanitization was not disabled on it. I noticed
> that other architectures disabled sanitization of their stacktrace code,
> eg. ARM in commit 4d576cab16f57e1f87978f ("ARM: 9028/1: disable KASAN in
> call stack capturing routines"), so I did not investigate it further.
>
> (Note that despite the name, sysrq.c is also just stacktrace code.)
Stack trace collection code might trigger KASAN splats when walking
stack frames, but this can be resolved by using unchecked accesses.
The main reason to disable instrumentation here is for performance
reasons, see the upcoming patch for arm64 [1] for some details.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=802b91118d11
