Re: [tip:locking/urgent] compiler, atomics: Provide READ_ONCE_NOCHECK ()

[Dmitry Vyukov]

On Wed, Oct 14, 2015 at 6:01 PM, Paul E. McKenney
<paulmck@xxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Oct 14, 2015 at 05:50:34PM +0200, Dmitry Vyukov wrote:
>> On Wed, Oct 14, 2015 at 5:45 PM, Paul E. McKenney
>> <paulmck@xxxxxxxxxxxxxxxxxx> wrote:
>> > On Wed, Oct 14, 2015 at 08:28:43AM -0700, tip-bot for Andrey Ryabinin wrote:
>> >> Commit-ID:  4115ffdf4d6f8986a7abe1dd522c163f599bc0e6
>> >> Gitweb:     http://git.kernel.org/tip/4115ffdf4d6f8986a7abe1dd522c163f599bc0e6
>> >> Author:     Andrey Ryabinin <aryabinin@xxxxxxxxxxxxx>
>> >> AuthorDate: Tue, 13 Oct 2015 18:28:07 +0300
>> >> Committer:  Ingo Molnar <mingo@xxxxxxxxxx>
>> >> CommitDate: Wed, 14 Oct 2015 16:44:06 +0200
>> >>
>> >> compiler, atomics: Provide READ_ONCE_NOCHECK()
>> >>
>> >> 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_NOCHECK() macro. KASAN will not check the memory
>> >> accessed by READ_ONCE_NOCHECK().
>> >>
>> >> This patch creates __read_once_size_nocheck() a clone of
>> >> __read_once_size_check() (renamed __read_once_size()).
>> >> The only difference between them is 'no_sanitized_address'
>> >> attribute appended to '*_nocheck' 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_NOCHECK() is just a clone of READ_ONCE().
>> >
>> > So I add READ_ONCE_NOCHECK() for accesses for which the compiler cannot
>> > prove safe address for KASAN's benefit, but READ_ONCE() suffices for
>> > the data-race-detection logic in KTSAN, correct?
>>
>> KTSAN also needs READ_ONCE_NOCHECK() here. KTSAN will flag races
>> between get_wchan() and the thread accesses to own stack even more
>> aggressively than KASAN, because KTSAN won't like get_wchan() accesses
>> even to non-poisoned areas of other thread stack.
>
> So to keep KTSAN happy, any read from some other thread's stack requires
> READ_ONCE_NOCHECK()?  What if the access is via a locking primitive or
> read-modify-write atomic operation?
>
> This is of some interest in RCU, which implements synchronous grace
> periods using completions that are allocated on the calling task's stack
> and manipulated by RCU callbacks that are likely executing elsewhere.


KTSAN does not have any special logic for stacks. It just generally
flags pairs of accesses when (1) at least one access is not atomic,
(2) at least one access is a write and (3) these accesses are not
synchronized by means of other synchronization.
There is a bunch of cases when kernel code allocates objects on stack
and then passes them to other threads, but as far as there is proper
synchronization it is OK.

For the record, KTSAN is this:
https://github.com/google/ktsan
https://github.com/google/ktsan/wiki/Found-Bugs
--
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/