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
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
Subject: Re: [PATCH] mm/vmscan: fix data races at kswapd_classzone_idx
From:   Qian Cai <cai@lca.pw>
In-Reply-To: <20200225181101.eca053d3201a6ac68e543572@linux-foundation.org>
Date:   Tue, 25 Feb 2020 21:26:35 -0500
Cc:     Marco Elver <elver@google.com>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE34F3EE-B992-418E-B2A4-D1FDDCD86906@lca.pw>
References: <1582649726-15474-1-git-send-email-cai@lca.pw>
 <20200225181101.eca053d3201a6ac68e543572@linux-foundation.org>
To:     Andrew Morton <akpm@linux-foundation.org>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Feb 25, 2020, at 9:11 PM, Andrew Morton <akpm@linux-foundation.org> =
wrote:
>=20
> On Tue, 25 Feb 2020 11:55:26 -0500 Qian Cai <cai@lca.pw> wrote:
>=20
>> pgdat->kswapd_classzone_idx could be accessed concurrently in
>> wakeup_kswapd(). Plain writes and reads without any lock protection
>> result in data races. Fix them by adding a pair of READ|WRITE_ONCE() =
as
>> well as saving a branch (compilers might well optimize the original =
code
>> in an unintentional way anyway). The data races were reported by =
KCSAN,
>>=20
>> ...
>>=20
>> --- a/mm/vmscan.c
>> +++ b/mm/vmscan.c
>> @@ -3961,11 +3961,10 @@ void wakeup_kswapd(struct zone *zone, gfp_t =
gfp_flags, int order,
>> 		return;
>> 	pgdat =3D zone->zone_pgdat;
>>=20
>> -	if (pgdat->kswapd_classzone_idx =3D=3D MAX_NR_ZONES)
>> -		pgdat->kswapd_classzone_idx =3D classzone_idx;
>> -	else
>> -		pgdat->kswapd_classzone_idx =3D =
max(pgdat->kswapd_classzone_idx,
>> -						  classzone_idx);
>> +	if (READ_ONCE(pgdat->kswapd_classzone_idx) =3D=3D MAX_NR_ZONES =
||
>> +	    READ_ONCE(pgdat->kswapd_classzone_idx) < classzone_idx)
>> +		WRITE_ONCE(pgdat->kswapd_classzone_idx, classzone_idx);
>> +
>> 	pgdat->kswapd_order =3D max(pgdat->kswapd_order, order);
>> 	if (!waitqueue_active(&pgdat->kswapd_wait))
>> 		return;
>=20
> This is very partial, isn't it?  The above code itself is racy against
> other code which manipulates ->kswapd_classzone_idx and the
> manipulation in allow_direct_reclaim() is performed by threads other
> than kswapd and so need the READ_ONCE treatment and is still racy with
> that?

Right, I suppose allow_direct_reclaim() could use some treatment too.

>=20
> I guess occasional races here don't really matter, but a grossly wrong
> read from load tearing might matter.  In which case shouldn't we be
> defending against them in all cases where non-kswapd threads read this
> field?