From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7633C4BA06 for ; Wed, 26 Feb 2020 02:11:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6851E21744 for ; Wed, 26 Feb 2020 02:11:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="KMWf8lCx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6851E21744 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 037546B0003; Tue, 25 Feb 2020 21:11:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F29F26B0005; Tue, 25 Feb 2020 21:11:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3F0C6B0006; Tue, 25 Feb 2020 21:11:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id CB7FB6B0003 for ; Tue, 25 Feb 2020 21:11:04 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 84B5C180AD811 for ; Wed, 26 Feb 2020 02:11:04 +0000 (UTC) X-FDA: 76530650448.23.offer52_920d1c893d5c X-HE-Tag: offer52_920d1c893d5c X-Filterd-Recvd-Size: 3153 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf41.hostedemail.com (Postfix) with ESMTP for ; Wed, 26 Feb 2020 02:11:02 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7A4CE21744; Wed, 26 Feb 2020 02:11:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1582683061; bh=ZEaedp/t+OQSF3UOsAPhZYZgIEc+LWUwL3y+/EEtQhA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KMWf8lCx4d8eRF5v4CGpKVE8EnPQo0CFGrnGVlu8kncXipEwtwpCsQIpjm3SDeyfh Ah2b+mGlHmB6PKYzocKhQKhMaQh4tpOOlYNqsoGPseZs6xOMpS40LCsUSuhfVIziRi 3asgSyZdZbKMPwQoczZ0RDkU9rp/VUe/B27qFS/w= Date: Tue, 25 Feb 2020 18:11:01 -0800 From: Andrew Morton To: Qian Cai Cc: elver@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmscan: fix data races at kswapd_classzone_idx Message-Id: <20200225181101.eca053d3201a6ac68e543572@linux-foundation.org> In-Reply-To: <1582649726-15474-1-git-send-email-cai@lca.pw> References: <1582649726-15474-1-git-send-email-cai@lca.pw> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, 25 Feb 2020 11:55:26 -0500 Qian Cai wrote: > 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, > > ... > > --- 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 = zone->zone_pgdat; > > - if (pgdat->kswapd_classzone_idx == MAX_NR_ZONES) > - pgdat->kswapd_classzone_idx = classzone_idx; > - else > - pgdat->kswapd_classzone_idx = max(pgdat->kswapd_classzone_idx, > - classzone_idx); > + if (READ_ONCE(pgdat->kswapd_classzone_idx) == MAX_NR_ZONES || > + READ_ONCE(pgdat->kswapd_classzone_idx) < classzone_idx) > + WRITE_ONCE(pgdat->kswapd_classzone_idx, classzone_idx); > + > pgdat->kswapd_order = max(pgdat->kswapd_order, order); > if (!waitqueue_active(&pgdat->kswapd_wait)) > return; 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? 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?