Messages in this thread | | | From | Marco Elver <> | Date | Tue, 21 Jan 2020 09:19:18 +0100 | Subject | Re: [PATCH -next] x86/mm/pat: fix a data race in cpa_inc_4k_install |
| |
On Tue, 21 Jan 2020 at 08:27, Borislav Petkov <bp@alien8.de> wrote: > > On Mon, Jan 20, 2020 at 11:12:00PM -0500, Qian Cai wrote: > > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > > index 20823392f4f2..31e4a73ae70e 100644 > > --- a/arch/x86/mm/pat/set_memory.c > > +++ b/arch/x86/mm/pat/set_memory.c > > @@ -128,7 +128,7 @@ static inline void cpa_inc_2m_checked(void) > > > > static inline void cpa_inc_4k_install(void) > > { > > - cpa_4k_install++; > > + WRITE_ONCE(cpa_4k_install, READ_ONCE(cpa_4k_install) + 1);
As I said in my email that you also copied to the message, this is just a stats counter. For the general case, I think we reached consensus that such accesses should intentionally remain data races: https://lore.kernel.org/linux-fsdevel/CAHk-=wg5CkOEF8DTez1Qu0XTEFw_oHhxN98bDnFqbY7HL5AB2g@mail.gmail.com/T/#u
Either you can use the data_race() macro, making this 'data_race(cpa_4k_install++)' -- this effectively documents the intentional data race --
or just blacklist the entire file by putting KCSAN_SANITIZE_set_memory.o := n into the Makefile.
[ Note that there are 2 more ways to blacklist: - __no_kcsan function attribute, for blacklisting entire functions. - KCSAN_SANITIZE :=n in the Makefile, blacklisting all compilation units in the Makefile. ]
I leave it to you what makes more sense. I don't know if there are other data races lurking here, since cpa_4k_install is not the only stats counter.
> > } > > > > static inline void cpa_inc_lp_sameprot(int level) > > -- > > Fix a data race, says your subject? > > If it had to be honest, it probably should say "Make the code ugly > because the next tool can't handle it". > > Frankly, I'm not a fan of all this "change the kernel to fix the tool" > attitude.
I commented on better ways dealing with this, since this is just stats counting.
Thanks, -- Marco
| |