Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200121151503.2934-1-cai@lca.pw> <CANpmjNPR+mbadR0DDKGUhTkaXJi=vsHmhvq3+Rz0Hrx=E9V_Qg@mail.gmail.com>
 <20200121152853.GI7808@zn.tnic> <44A4276D-5530-4DAA-8FC7-753D03ADD2F3@lca.pw>
 <CANpmjNO7mTEMc6pvpVVXdu2r6cMg_N8QkRffEHHG-WNFXE4CjA@mail.gmail.com>
 <20200121154528.GK7808@zn.tnic> <E9162CDC-BBC5-4D69-87FB-C93AB8B3D581@lca.pw> <20200121221814.GQ7808@zn.tnic>
In-Reply-To: <20200121221814.GQ7808@zn.tnic>
From:   Marco Elver <elver@google.com>
Date:   Wed, 22 Jan 2020 00:30:09 +0100
Message-ID: <CANpmjNMCyWbbMX2kK8b+Uygg2v-yaQZky8r_X_ca6YCKCy8-dw@mail.gmail.com>
Subject: Re: [PATCH -next] x86/mm/pat: silence a data race in cpa_4k_install
To:     Borislav Petkov <bp@alien8.de>
Cc:     Qian Cai <cai@lca.pw>, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue, 21 Jan 2020 at 23:18, Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Jan 21, 2020 at 03:21:35PM -0500, Qian Cai wrote:
> > Actually "__no_kcsan" does not work because I have
>
> Why, because KCSAN conflicts with inlining? I'm looking at the comment
> over __no_kasan_or_inline.

Rather a bug in GCC. AFAIK it is GCC <9 ignoring
__attribute__((no_sanitize_*)) for functions that it decides to
inline. Somewhere GCC loses the attribute when inlined, resulting in
still emitting instrumentation calls. __no_kcsan_or_inline works
around it by making such functions noinline. GCC also emits an error
if you try to combine __always_inline and
__attribute__((no_sanitize_*)).

For these reasons we sadly need __no_kcsan_or_inline (similarly we
need __no_kasan_or_inline for KASAN for the same reasons). I hope this
will look a bit nicer once we move past GCC<9.

> > CONFIG_OPTIMIZE_INLINING=y (GCC 8.3.1) here, so it has to be,
> >
> > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> > index 20823392f4f2..fabbf8a33b7f 100644
> > --- a/arch/x86/mm/pat/set_memory.c
> > +++ b/arch/x86/mm/pat/set_memory.c
> > @@ -126,7 +126,7 @@ static inline void cpa_inc_2m_checked(void)
> >         cpa_2m_checked++;
> >  }
> >
> > -static inline void cpa_inc_4k_install(void)
> > +static inline void __no_kcsan_or_inline cpa_inc_4k_install(void)

It should be 'static __no_kcsan_or_inline void
cpa_inc_4k_install(void)', since __no_kcsan_or_inline provides
__always_inline on non-KCSAN builds.

Thanks,
-- Marco

> >  {
> >         cpa_4k_install++;
> >  }
> >
> > Are you fine with it or data_race() looks better?
>
> This one looks marginally better because the annotation is still outside
> of the function, so to speak.
>
> Btw, looking at the other "inc" CPA statistics functions there, does it
> mean that for KCSAN they all need to be annotated now too?
>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette