From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753768AbbJPL7N (ORCPT ); Fri, 16 Oct 2015 07:59:13 -0400 Received: from mx2.parallels.com ([199.115.105.18]:44276 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752088AbbJPL7M (ORCPT ); Fri, 16 Oct 2015 07:59:12 -0400 Subject: Re: [PATCH v4 1/2] compiler, atomics: Provide READ_ONCE_NOKSAN() To: Borislav Petkov , Ingo Molnar References: <1444739750-29241-1-git-send-email-aryabinin@virtuozzo.com> <1444988694-26043-1-git-send-email-aryabinin@virtuozzo.com> <1444988694-26043-2-git-send-email-aryabinin@virtuozzo.com> <20151016103338.GE31612@pd.tnic> CC: , Thomas Gleixner , "H. Peter Anvin" , , Andrew Morton , Andy Lutomirski , Andrey Konovalov , Kostya Serebryany , Alexander Potapenko , kasan-dev , Denys Vlasenko , Andi Kleen , Dmitry Vyukov , Sasha Levin , Wolfram Gloger , "Paul E. McKenney" , Peter Zijlstra From: Andrey Ryabinin Message-ID: <5620E66F.6050406@virtuozzo.com> Date: Fri, 16 Oct 2015 14:58:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151016103338.GE31612@pd.tnic> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To US-EXCH.sw.swsoft.com (10.255.249.47) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/16/2015 01:33 PM, Borislav Petkov 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. > > Frankly, the "NOKSAN" suffix is too specific. I know, I know, I'm > bikeshedding but what happens if yet another tool wants to be disabled > from checking there and that tool is not *SAN? We rename again? > > So the "NOCHECK" suffix made much more sense, even if it was generic. > IMNSVHO. > Sounds reasonable. Ingo, what do you think? > Thanks. >