linux-kernel - Re: [PATCH -next v2] mm: mark an intentional data race in page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANpmjNOs-ncPxv1gnzwXwCpf1nqABn59wUhpo-tf8A_8VP0dvQ@mail.gmail.com>
Date:   Mon, 10 Feb 2020 08:58:06 +0100
From:   Marco Elver <elver@...gle.com>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Qian Cai <cai@....pw>, Matthew Wilcox <willy@...radead.org>,
        John Hubbard <jhubbard@...dia.com>, ira.weiny@...el.com,
        Dan Williams <dan.j.williams@...el.com>,
        Jan Kara <jack@...e.cz>,
        Linux Memory Management List <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next v2] mm: mark an intentional data race in page_zonenum

On Mon, 10 Feb 2020 at 05:06, Andrew Morton <akpm@...ux-foundation.org> wrote:
>
> On Sun, 9 Feb 2020 21:41:56 -0500 Qian Cai <cai@....pw> wrote:
>
> >
> >
> > > On Feb 9, 2020, at 9:20 PM, Andrew Morton <akpm@...ux-foundation.org> wrote:
> > >
> > > Using data_race() here seems misleading - there is no race, but we're
> > > using data_race() to suppress a false positive warning from KCSAN, yes?
> >
> > It is a data race in the sense of compilers, i.e., KCSAN is a compiler instrumentation, so here the load and store are both in word-size, but code here is only interested in 3 bits which are never changed. Thus, it is a harmless data race.
> >
> > Marco also mentioned,
> >
> > “Various options were considered, and based on feedback from Linus,
> > decided 'data_race(..)' is the best option:”
> >
> > lore.kernel.org/linux-fsdevel/CAHk-=wg5CkOEF8DTez1Qu0XTEFw_oHhxN98bDnFqbY7HL5AB2g@...l.gmail.com/
> >
> > Paul also said,
> >
> > ”People will get used to the name more quickly than they will get used
> > to typing the extra seven characters.  Here is the current comment header:
> >
> > /*
> >  * data_race(): macro to document that accesses in an expression may conflict with
> >  * other concurrent accesses resulting in data races, but the resulting
> >  * behaviour is deemed safe regardless.
> >  *
> >  * This macro *does not* affect normal code generation, but is a hint to tooling
> >  * that data races here should be ignored.
> >  */
> >
> > I will be converting this to docbook form.
> >
> > In addition, in the KCSAN documentation:
> >
> > * KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that
> >   any data races due to accesses in ``expr`` should be ignored and resulting
> >   behaviour when encountering a data race is deemed safe.”
>
> OK.  But I believe page_zonenum() still deserves a comment explaining
> that there is no race and explaining why we're using data_race()
> anyway.  Otherwise the use of data_race() is simply misleading.
>

I have a better suggestion for page_zonenum(), pending a patch if it
makes sense:
  http://lkml.kernel.org/r/CANpmjNNaHAnKCMLb+Njs3AhEoJT9O6-Yh63fcNcVTjBbNQiEPg@mail.gmail.com
If that makes more sense, the patch here could eventually be replaced.

Thanks,
-- Marco