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 0B64FC35247 for ; Thu, 6 Feb 2020 20:20:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C27F121741 for ; Thu, 6 Feb 2020 20:20:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="ZGi2BML2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C27F121741 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 911B76B0003; Thu, 6 Feb 2020 15:20:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 89BB56B0006; Thu, 6 Feb 2020 15:20:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7633E6B0007; Thu, 6 Feb 2020 15:20:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5A8246B0003 for ; Thu, 6 Feb 2020 15:20:14 -0500 (EST) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 0C4082816 for ; Thu, 6 Feb 2020 20:20:14 +0000 (UTC) X-FDA: 76460819148.06.pies87_3c3472fa33b00 X-HE-Tag: pies87_3c3472fa33b00 X-Filterd-Recvd-Size: 2479 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf44.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 20:20:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rjvBCgQG7PCKo30bNWy0wd3PGVZSHpsi4wor0rOBgAc=; b=ZGi2BML2CU17sq6hY7F3ILOGkv c/kLQ0QaLgaEMpVhUWFAIemXaBw2BO1DbXwzDWMuGDE4St66KbdnVITd49zhhLZ/hMhomYa3THPjR LmaMH9Ji4IehU7vzAQWyRyp8cANkv/87f6SOWANwPK2tiKsFvKipVnvZ6ap1F3os2Pkuqj9gFXCwI DxMypz8aNDozSey/EkLU9T1iXZCLzz507UtB1DRfJnXScrHJviqhucPP/vqVOngGKb45hXIsgdclA uTyiLeEs0HH+6ZK7UHeE5ORUP7dwqFvPNpkJ8oIYUpqOdjiHEVKxtFgMw9Nlzc0Wi5K0UrwPnYCOz YPc4+pvQ==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1iznd7-0005az-Hc; Thu, 06 Feb 2020 20:20:05 +0000 Date: Thu, 6 Feb 2020 12:20:05 -0800 From: Matthew Wilcox To: Qian Cai Cc: akpm@linux-foundation.org, elver@google.com, 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: <20200206202005.GY8731@bombadil.infradead.org> References: <20200206183000.913-1-cai@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200206183000.913-1-cai@lca.pw> 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, Feb 06, 2020 at 01:30:00PM -0500, Qian Cai wrote: > Both the read and write are done only with the non-exclusive mmap_sem > held. Since the read only check for a specific bit range (up to 3 bits) > 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]. This changelog makes me think you don't really understand the situation. 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 zone number bits will never be modified by any other write. So we can accept a reload of the zone bits after an intervening write and we don't need to use READ_ONCE().