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;
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH -next] mm/page_counter: mark intentional data races
Date:   Wed, 29 Jan 2020 04:51:58 -0500
Message-Id: <9507ADF5-1040-495E-9A39-C0C23412AD64@lca.pw>
References: <CANpmjNNaCtL+vqpPKug9_DoFUue=PdoTyQFXLOx5H_BYCyDMzA@mail.gmail.com>
Cc:     Michal Hocko <mhocko@kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Linux Memory Management List <linux-mm@kvack.org>,
        LKML <linux-kernel@vger.kernel.org>
In-Reply-To: <CANpmjNNaCtL+vqpPKug9_DoFUue=PdoTyQFXLOx5H_BYCyDMzA@mail.gmail.com>
To:     Marco Elver <elver@google.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jan 29, 2020, at 4:06 AM, Marco Elver <elver@google.com> wrote:
>=20
> These should be using 'READ_ONCE' and 'WRITE_ONCE' for c->watermark.
> Store or load tearing would change the logic here, since the
> comparison might see garbage.

I originally thought that it probably does not matter because it is racy the=
re by doing lockless access anyway. Another thread could change the value at=
 anytime.

Now, I agree set it to a garbage due to a data race could be quite unpleasan=
t there.=