Messages in this thread | | | From | Dmitry Vyukov <> | Date | Wed, 6 Mar 2019 15:41:27 +0100 | Subject | Re: [PATCH 1/8] kasan,x86: Frob kasan_report() in an exception |
| |
On Wed, Mar 6, 2019 at 3:40 PM Dmitry Vyukov <dvyukov@google.com> wrote: > > On Wed, Mar 6, 2019 at 3:34 PM Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Wed, Mar 06, 2019 at 03:12:37PM +0100, Peter Zijlstra wrote: > > > On Wed, Mar 06, 2019 at 03:01:33PM +0100, Dmitry Vyukov wrote: > > > > On Wed, Mar 6, 2019 at 2:57 PM Peter Zijlstra <peterz@infradead.org> wrote: > > > > > > > > I've not found callers of __asan_report_load* with AC=1 in the kernel > > > > > yet. Under what condtions does GCC emit calls to these functions? > > > > > > > > CONFIG_KASAN_INLINE=y > > > > Then compiler inlines fast path into generated code and only calls > > > > into runtime to report errors (also, faster, this should be a default > > > > for anything other than tiny ROM controllers). > > > > > > *sigh*, clearly I've not build enough kernels yet... Lemme go try that. > > > > mm/kasan/generic_report.o: warning: objtool: __asan_report_load1_noabort()+0x0: call to __fentry__() with UACCESS enabled > > > > You want to do: > > > > CFLAGS_REMOVE_f= -pg > > > > like generic.o has? > > This should not matter for KASAN itself. > KASAN will call into function tracer, and function tracer will call > into KASAN, but unless function tracer is badly broken and causes a > KASAN report on every invocation, the recursion will end (function > tracer will get to the _report_ function). So we only disabled -pg for
tracer will _not_ get to the _report_ function
> fast paths. > But if it makes things simpler for the objtool, then I think we can > disable function tracer for generic_report.c too.
| |