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.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 927B7C2BA83 for ; Mon, 10 Feb 2020 02:20:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 54A5720870 for ; Mon, 10 Feb 2020 02:20:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="lLD/+OqY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 54A5720870 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 D84EC6B0092; Sun, 9 Feb 2020 21:20:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D35746B0093; Sun, 9 Feb 2020 21:20:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C241E6B0095; Sun, 9 Feb 2020 21:20:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by kanga.kvack.org (Postfix) with ESMTP id A89C16B0092 for ; Sun, 9 Feb 2020 21:20:10 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 7176B2C14 for ; Mon, 10 Feb 2020 02:20:10 +0000 (UTC) X-FDA: 76472612580.30.feast49_1e951d7bbf911 X-HE-Tag: feast49_1e951d7bbf911 X-Filterd-Recvd-Size: 3337 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf40.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Feb 2020 02:20:09 +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 E907F20578; Mon, 10 Feb 2020 02:20:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581301209; bh=c9R1yL17Ieuk+QF6jhqru/+TVSnntO0E6LwgLPaJB5k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=lLD/+OqYa2flV1yIcil8qIGO7j8MWm1DgNl2AlT4UoFHBX9YBrSSzL9S90u8kbKem f0Rme8LLpw2Ymd1ER75n9IBSltGzpDGwhgxIEy3GrWZVq0QVgHZj2o5ujZw4kRdn4c rh6BcW9jRbLcYq1JUiH+7itRqvwaUY8bmsXuaIbM= Date: Sun, 9 Feb 2020 18:20:08 -0800 From: Andrew Morton To: Qian Cai Cc: Matthew Wilcox , Marco Elver , jhubbard@nvidia.com, ira.weiny@intel.com, dan.j.williams@intel.com, jack@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH -next v2] mm: mark an intentional data race in page_zonenum Message-Id: <20200209182008.008c06f1cf4347a95f9de0a5@linux-foundation.org> In-Reply-To: <95A69596-D5F9-41EB-84A0-AE32D17FE320@lca.pw> References: <20200206183000.913-1-cai@lca.pw> <20200206202005.GY8731@bombadil.infradead.org> <95A69596-D5F9-41EB-84A0-AE32D17FE320@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=UTF-8 Content-Transfer-Encoding: quoted-printable 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 Thu, 6 Feb 2020 15:25:41 -0500 Qian Cai wrote: >=20 >=20 > > On Feb 6, 2020, at 3:20 PM, Matthew Wilcox wrot= e: > >=20 > > On Thu, Feb 06, 2020 at 01:30:00PM -0500, Qian Cai wrote: > >> Both the read and write are done only with the non-exclusive mmap_se= m > >> held. Since the read only check for a specific bit range (up to 3 bi= ts) > >> in the flag but the write here never change those 3 bits, so load > >> tearing would be harmless here. Thus, just mark it as an intentional > >> data races using the data_race() macro which is designed for those > >> situations [1]. > >=20 > > This changelog makes me think you don't really understand the situati= on. > >=20 > > A page never changes its zone number. The zone number happens to be > > stored in the same word as other bits which are modified, but the zon= e > > number bits will never be modified by any other write. So we can acc= ept > > a reload of the zone bits after an intervening write and we don't nee= d > > to use READ_ONCE(). >=20 > Maybe your explanation is better, but I did try to explain the same thi= ng. > I=E2=80=99ll let Andrew to decide if he would like to update the commit= log a bit > with your wording. Using data_race() here seems misleading - there is no race, but we're using data_race() to suppress a false positive warning from KCSAN, yes? That's a bit hacky. If this happens rarely then perhaps adding a suitable comment in page_zonenum() which explains this will suffice.=20 But if we keep on abusing data_race() in this fashion then it would be better to add a new macro for this purpose.