On Wed, Oct 14, 2015 at 6:19 PM, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > > > On 10/14/2015 06:50 PM, Dmitry Vyukov wrote: >> On Wed, Oct 14, 2015 at 5:45 PM, Paul E. McKenney >> <paul...@linux.vnet.ibm.com> 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 <aryabi...@virtuozzo.com> >>>> AuthorDate: Tue, 13 Oct 2015 18:28:07 +0300 >>>> Committer: Ingo Molnar <mi...@kernel.org> >>>> 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. > > Does it? What's the difference between READ_ONCE_NOCHECK() and READ_ONCE() > with KTSAN=y? > AFAIK READ_ONCE() is sufficient to hide race from KTSAN. It doesn't *require* > READ_ONCE_NOCHECK(), right?
For not there is no difference, because you just added READ_ONCE_NOCHECK and we have not yet supported it. But my plan is to completely ignore accessed from READ_ONCE_NOCHECK in KTSAN so that they never lead to race reports. READ_ONCE in get_wchan still can lead to a data race report, because it is READ_ONCE in get_wchan versus a normal write to stack in the other thread. That is not atomic and not generally safe. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
