Re: [PATCH v4 1/2] compiler, atomics: Provide READ_ONCE_NOKSAN()

[Andrey Ryabinin]

On 10/16/2015 01:00 PM, Peter Zijlstra wrote:
> On Fri, Oct 16, 2015 at 12:44:53PM +0300, Andrey Ryabinin wrote:
>> Some code may perform racy by design memory reads. This could be
>> harmless, yet such code may produce KASAN warnings.
>>
>> To hide such accesses from KASAN this patch introduces
>> READ_ONCE_NOKSAN() macro. KASAN will not check the memory
>> accessed by READ_ONCE_NOKSAN(). The KernelThreadSanitizer (KTSAN)
>> is going to ignore it as well.
>>
>> This patch creates __read_once_size_noksan() a clone of
>> __read_once_size(). The only difference between them is
>> 'no_sanitized_address' attribute appended to '*_nokasan' function.
>> This attribute tells the compiler that instrumentation of memory
>> accesses should not be applied to that function. We declare it as
>> static '__maybe_unsed' because GCC is not capable to inline such
>> function: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67368
>>
>> With KASAN=n READ_ONCE_NOKSAN() is just a clone of READ_ONCE().
> 
> Would we need a similar annotation for things like
> mutex_spin_on_owner()'s dereference of owner, or is that considered safe
> by KASAN?
> 
> (its not actually safe; as I remember we have a problem with using
> rcu_read_lock for tasks like that)
> 

How exactly it's not safe? If we could dereference freed owner, I'd say we need to fix this,
but not hide.
I've seen use-after-free in mutex_spin_on_owner() once, but it was caused
by GPF in kernel which killed some task while it was holding mutex. So the next
time we tried to grab that mutex, lock->owner was already dead.
But normally we should release all locks before we able to kill task, so this won't happen.


--
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/