On Tue, Oct 11, 2022 at 11:44:46AM -0700, Josh Poimboeuf wrote: > On Tue, Oct 11, 2022 at 10:24:27AM +0200, Peter Zijlstra wrote: > > On Mon, Oct 10, 2022 at 06:20:00PM -0700, Linus Torvalds wrote: > > > The other thing I notice from just doing a build is that I now get > > > > > > vmlinux.o: warning: objtool: kasan_report+0x12: call to > > > stackleak_track_stack() with UACCESS enabled > > > > So kasan_report() is already marked as being special; and it does the > > mandatory user_access_save() / user_access_restore() things to fix it > > up. > > > > But it looks like kasan code itself is now getting instrumented by the > > stackleak stuff and that inserts a call outside of the > > user_access_save()/restore() thing, and *that* is getting flagged. > > > > Looking at mm/kasan/Makefile it disables a lot of the instrumentation, > > but perhaps not enough? > > I can recreate, but weirdly the below doesn't seem to fix it. Duh, because kmsan != stackleak, obviously... > > diff --git a/mm/kasan/Makefile b/mm/kasan/Makefile > index d4837bff3b60..a41cf1235032 100644 > --- a/mm/kasan/Makefile > +++ b/mm/kasan/Makefile > @@ -1,5 +1,6 @@ > # SPDX-License-Identifier: GPL-2.0 > KASAN_SANITIZE := n > +KMSAN_SANITIZE := n > UBSAN_SANITIZE := n > KCOV_INSTRUMENT := n > > -- Josh
