Re: [PATCH] x86/process: Silence KASAN warnings in get_wchan()

[Andy Lutomirski]

On Tue, Oct 6, 2015 at 12:26 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
> * Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/