Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 6 Oct 2015 11:11:08 -0700 | Subject | Re: [PATCH] x86/process: Silence KASAN warnings in get_wchan() |
| |
On Tue, Oct 6, 2015 at 12:26 AM, Ingo Molnar <mingo@kernel.org> wrote: > > * Andrey Ryabinin <aryabinin@virtuozzo.com> wrote: > >> On 10/05/2015 07:39 PM, Andi Kleen wrote: >> >> But, I think I have the solution. >> >> We could have some blacklist - list of function names which we should be ignored. >> >> In kasan_report() we could resolve return address to function name and compare it with name in list. >> >> If name in list -> ignore report. >> > >> > I think annotating statements is cleaner than functions, even if it >> > is more code. Much better documentation >> > >> >> I agree with that, that's why I suggested to add READ_ONCE_NOCHECK(): >> READ_ONCE_NOCHECK() >> { >> kasan_disable_current(); >> READ_ONCE(); >> kasan_enable_current(); >> } >> >> Anywone objects? > > Sounds good to me! As long as it's hidden from plain .c files I'm a happy camper. > > This should probably also be faster for KASAN than triggering a warning and having > to parse a blacklist, right? > >> > If disabling with an attribute doesn't work, you could put it into a special >> > section with __attribute__((section ...)) and check the start/end symbol >> > before reporting. That's how kprobes solves similar issues. It also has the >> > advantage that it stops inlining. >> >> Yes, it might be better. Although, because of broken -fconserve-stack, this may >> not work in some cases - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63533 >> Function splitter may split original function into two parts and it always puts >> one split part in default .text section. > > We do a _ton_ of such section tricks in the kernel (all of exception handling is > based on that) - if that's broken by -fconserve-stack then the kernel is broken > much more widely. > > So unless KASAN wants to do something special here you can rely on sections just > fine.
Kprobes is moving away from a section approach for some reason (not sure why), but the kprobe approach should work, too.
But what's wrong with the GCC attribute mechanism? Surely GCC ought to be able to generate the code, at least in the simple cases, and the attribute already exists. The attribute and READ_ONCE_NOCHECK seem like the least messy in the C code.
--Andy
| |