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=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Qian Cai <cai@lca.pw>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH] mm/memcontrol: fix a data race in scan count
Date:   Sun, 9 Feb 2020 23:44:26 -0500
Message-Id: <6E237CA6-8968-4207-A9BB-1D18CB30822B@lca.pw>
References: <20200209202840.2bf97ffcfa811550d733c461@linux-foundation.org>
Cc:     hannes@cmpxchg.org, mhocko@kernel.org, vdavydov.dev@gmail.com,
        cgroups@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
In-Reply-To: <20200209202840.2bf97ffcfa811550d733c461@linux-foundation.org>
To:     Andrew Morton <akpm@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 9, 2020, at 11:28 PM, Andrew Morton <akpm@linux-foundation.org> wro=
te:
>=20
> I worry about the readability/maintainability of these things.  A naive
> reader who comes upon this code will wonder "why the heck is it using
> READ_ONCE?".  A possibly lengthy trawl through the git history will
> reveal the reason but that's rather unkind.  Wouldn't a simple
>=20
>    /* modified under lru_lock, so use READ_ONCE */
>=20
> improve the situation?

Sure. I just don=E2=80=99t remember there are many places in the existing co=
de which put comments for READ_ONCE() and WRITE_ONCE(). For example, kernel/=
locking/osq_lock.c and kernel/rcu/srcutree.c, but I suppose every subsystem c=
ould be different.=