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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 61CFEC352A3 for ; Fri, 7 Feb 2020 00:18:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 04A2021741 for ; Fri, 7 Feb 2020 00:18:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="B12iZ8ko" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 04A2021741 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8388C6B0006; Thu, 6 Feb 2020 19:18:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E8FA6B0007; Thu, 6 Feb 2020 19:18:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6FFA76B0008; Thu, 6 Feb 2020 19:18:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id 56DEF6B0006 for ; Thu, 6 Feb 2020 19:18:19 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0DC908248047 for ; Fri, 7 Feb 2020 00:18:19 +0000 (UTC) X-FDA: 76461419118.14.bears51_65a83ba2f5024 X-HE-Tag: bears51_65a83ba2f5024 X-Filterd-Recvd-Size: 5574 Received: from mail-qk1-f195.google.com (mail-qk1-f195.google.com [209.85.222.195]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Fri, 7 Feb 2020 00:18:18 +0000 (UTC) Received: by mail-qk1-f195.google.com with SMTP id b7so537348qkl.7 for ; Thu, 06 Feb 2020 16:18:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m2dTuWO1ugKcCHTxp+o4yxt+su2yu8181wVA1BN+7GA=; b=B12iZ8ko/b6w6maPcjEcpsoonvUtE2A1DTzmX6pv+zpWPUgPquTz3qKUIBBmF2rkqI 8NDyiIztfImGvwbT8GB5BTlo8SZ7WmZmQsRKt8u+lHdVOUCbs10h9UQFxdAYgbp13ldP oEjP5b3/4xj9FlITI0Cxgkmm0lL3fzIMjStd4PYwoOsoOSHMG8kVhccmLD66df7IhLEy 7xRfb9t0lkch2Z+gjrtBUiaWPOI0EEdIlHVEGwXPawVv7/dVhrbznhwTfSjIKN36zcV2 B1c6kxaOiJnqlsQotvevCyD3Si/WEui6mAu1KIAGuomlWA6UDh2UtKg3YX/LWcsmFNTH CThQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m2dTuWO1ugKcCHTxp+o4yxt+su2yu8181wVA1BN+7GA=; b=lyWqyGa5aHHeVSk2KbiXlvi5BOMkedrkznnkZyB1tGFeZLjDEDly0rikHYz8qMITyZ V3rYD79rzW2eIVYpa0iVyCm6akeVXCQYH8dB2leY/gWnJmqv1DayopTaX6MP6/H96rBW pOkGA3JEmf/P4xZHQIQaoeW6CSzljHc7dzrara7RCR8LyN71YgWuxt9vFyYYuoWWjl7K wzdO42z8iXVWsIRt/rZWnCkkMt/VTX60vCcQjFwmfqt+mRbcCiAUEOTnR6Y9rN2iFMau 3Esd9xk+lZt2LL/23XDPeGlTVoDs2uYSfNmSu+ulx429ktOX4t3nIreZuTMLAlqOIGZg Dzvg== X-Gm-Message-State: APjAAAV1qlCOmTdmsUCiKQeAf11tqP8KBAC03SQ0JGyoeP4J2Oi/cN96 OhYwl7310mwTOSo5BsDhXOpzrw== X-Google-Smtp-Source: APXvYqyW8vjg6mpDaL9RjukFihPCoLu22QT7ULPVH+6VRvaYDXqqwCCxKU52v5R+fKuyrqg+RArsBw== X-Received: by 2002:a37:8e44:: with SMTP id q65mr5066875qkd.70.1581034697891; Thu, 06 Feb 2020 16:18:17 -0800 (PST) Received: from [192.168.1.153] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id y27sm539145qta.50.2020.02.06.16.18.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Feb 2020 16:18:17 -0800 (PST) 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: fix a data race in put_page() From: Qian Cai In-Reply-To: <079c4429-8a11-154d-cf5c-473d2698d18d@nvidia.com> Date: Thu, 6 Feb 2020 19:18:16 -0500 Cc: Jan Kara , David Hildenbrand , akpm@linux-foundation.org, ira.weiny@intel.com, dan.j.williams@intel.com, elver@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Message-Id: <235ACF21-35BE-4EDA-BA64-9553DA53BF12@lca.pw> References: <20200206145501.GD26114@quack2.suse.cz> <079c4429-8a11-154d-cf5c-473d2698d18d@nvidia.com> To: John Hubbard X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Bogosity: Ham, tests=bogofilter, spamicity=0.008478, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Feb 6, 2020, at 6:34 PM, John Hubbard wrote: >=20 > On 2/6/20 7:23 AM, Qian Cai wrote: >>=20 >>=20 >>> On Feb 6, 2020, at 9:55 AM, Jan Kara wrote: >>>=20 >>> I don't think the problem is real. The question is how to make KCSAN = happy >>> in a way that doesn't silence other possibly useful things it can = find and >>> also which makes it most obvious to the reader what's going on... = IMHO >>> using READ_ONCE() fulfills these targets nicely - it is free >>> performance-wise in this case, it silences the checker without = impacting >>> other races on page->flags, its kind of obvious we don't want the = load torn >>> in this case so it makes sense to the reader (although a comment may = be >>> nice). >>=20 >> Actually, use the data_race() macro there fulfilling the same purpose = too, i.e, silence the splat here but still keep searching for other = races. >>=20 >=20 > Yes, but both READ_ONCE() and data_race() would be saying untrue = things about this code, > and that somewhat offends my sense of perfection... :) >=20 > * READ_ONCE(): this field need not be restricted to being read only = once, so the > name is immediately wrong. We're using side effects of READ_ONCE(). >=20 > * data_race(): there is no race on the N bits worth of page zone = number data. There > is only a perceived race, due to tools that look at word-level = granularity. >=20 > I'd propose one or both of the following: >=20 > a) Hope that Marcus has an idea to enhance KCSAN so as to support this = model of > access, and/or A similar thing was brought up before, i.e., anything compared to zero = is immune to load-tearing issues, but it is rather difficult to implement it in the compiler, so = it was settled to use data_race(), = https://lore.kernel.org/lkml/CANpmjNN8J1oWtLPHTgCwbbtTuU_Js-8HD=3DcozW5cYk= m8h-GTBg@mail.gmail.com/#r >=20 > b) Add a new, better-named macro to indicate what's going on. Initial = bikeshed-able > candidates: >=20 > READ_RO_BITS() > READ_IMMUTABLE_BITS() > ...etc... >=20 Actually, Linus might hate those kinds of complication rather than a = simple data_race() macro, = https://lore.kernel.org/linux-fsdevel/CAHk-=3Dwg5CkOEF8DTez1Qu0XTEFw_oHhxN= 98bDnFqbY7HL5AB2g@mail.gmail.com/