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: <20200209182008.008c06f1cf4347a95f9de0a5@linux-foundation.org>
 <2B333FA6-AB17-4169-B9EE-9355FF9C42A4@lca.pw> <20200209200620.883ad431b01bcd38939ff5b4@linux-foundation.org>
In-Reply-To: <20200209200620.883ad431b01bcd38939ff5b4@linux-foundation.org>
From:   Marco Elver <elver@google.com>
Date:   Mon, 10 Feb 2020 08:58:06 +0100
Message-ID: <CANpmjNOs-ncPxv1gnzwXwCpf1nqABn59wUhpo-tf8A_8VP0dvQ@mail.gmail.com>
Subject: Re: [PATCH -next v2] mm: mark an intentional data race in page_zonenum
To:     Andrew Morton <akpm@linux-foundation.org>
Cc:     Qian Cai <cai@lca.pw>, Matthew Wilcox <willy@infradead.org>,
        John Hubbard <jhubbard@nvidia.com>, ira.weiny@intel.com,
        Dan Williams <dan.j.williams@intel.com>,
        Jan Kara <jack@suse.cz>,
        Linux Memory Management List <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 10 Feb 2020 at 05:06, Andrew Morton <akpm@linux-foundation.org> wro=
te:
>
> On Sun, 9 Feb 2020 21:41:56 -0500 Qian Cai <cai@lca.pw> wrote:
>
> >
> >
> > > On Feb 9, 2020, at 9:20 PM, Andrew Morton <akpm@linux-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, ye=
s?
> >
> > 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 h=
armless data race.
> >
> > Marco also mentioned,
> >
> > =E2=80=9CVarious options were considered, and based on feedback from Li=
nus,
> > decided 'data_race(..)' is the best option:=E2=80=9D
> >
> > lore.kernel.org/linux-fsdevel/CAHk-=3Dwg5CkOEF8DTez1Qu0XTEFw_oHhxN98bDn=
FqbY7HL5AB2g@mail.gmail.com/
> >
> > Paul also said,
> >
> > =E2=80=9DPeople will get used to the name more quickly than they will g=
et used
> > to typing the extra seven characters.  Here is the current comment head=
er:
> >
> > /*
> >  * data_race(): macro to document that accesses in an expression may co=
nflict 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 t=
o 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 KCS=
AN that
> >   any data races due to accesses in ``expr`` should be ignored and resu=
lting
> >   behaviour when encountering a data race is deemed safe.=E2=80=9D
>
> 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-Yh63fcNcVTjBbNQi=
EPg@mail.gmail.com
If that makes more sense, the patch here could eventually be replaced.

Thanks,
-- Marco