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=-8.4 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_IN_DEF_DKIM_WL 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 66E78C352A3 for ; Mon, 10 Feb 2020 13:38:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 155552070A for ; Mon, 10 Feb 2020 13:38:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="k+lzJ4Ld" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 155552070A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B61E66B00F8; Mon, 10 Feb 2020 08:38:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B12C96B00F9; Mon, 10 Feb 2020 08:38:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A01296B00FA; Mon, 10 Feb 2020 08:38:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0086.hostedemail.com [216.40.44.86]) by kanga.kvack.org (Postfix) with ESMTP id 87C306B00F8 for ; Mon, 10 Feb 2020 08:38:40 -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 3FB162C9D for ; Mon, 10 Feb 2020 13:38:40 +0000 (UTC) X-FDA: 76474322400.30.net47_85dbd6e8d8a51 X-HE-Tag: net47_85dbd6e8d8a51 X-Filterd-Recvd-Size: 6229 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Feb 2020 13:38:39 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id z2so9183340oih.6 for ; Mon, 10 Feb 2020 05:38:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=n4VkksM4yOFdYfQnXs70fdXcOaBAA6a7KVukuRv0B/0=; b=k+lzJ4LdVh/1CbBpkXb4FWY8y+vVjD7ltGBGbPuFD0uyLFRLCgr/86TNCv3ZuIO5lc iZAhHWmfya+7eTMixVFHqktD33bGbumFIeGqGriRe8MJdzMkrzO3wrfYvo0c6novP3w1 MDf//CvojUaFeIuzJCuWfCOD+OBT9yUirBAEc35ypZ7soOcXMip1sh0I3w1TuTeaVqYw tkqXQSdt6ZAvkY1IfvcwxsqLi0bGerDdyF+WjzpcxhLeGSj1oH6P6MYtVV/4kWMWXfj6 sxccmVhTQ0Zwi9obne74Az6QxE9/MC53fssklkMXyCJhYmKzLFbvxsROdwd2VjNYWjkj MGOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=n4VkksM4yOFdYfQnXs70fdXcOaBAA6a7KVukuRv0B/0=; b=Yg8QAFxAAXdAkz9HpQFA3RMoG2MR4eyVAEQYl+fvK0rLJF9tsXBWayuAwLgfwzqa8k EKowaXargz6bcN2HGmZ8E/ImPTIDBdmwezltw5kdiS25ZCcYaClviJqnpBeEVjmCxUZu WVmr+qSFuGTwZFvDNJvICMt2Yh6lecQAaSWWOgnCiu7g6HHc+ZG1kCGiGq2UGxNmqscj rTrOx7aw29afgb1XiQGr2tCBlEzPNVF8zB0JViz7ouvB+9yglh1qR8Q8mBUoHI5WTZ9k dkt1A0DySLFjfBG1NM6fJJj5LGlkGkQGU4T8tLFAUZLzDl+tKycm2+F3hUJNlncaM2S2 gxgw== X-Gm-Message-State: APjAAAVgRePtJ2XQQco4uFVhlB01K53FeuFsTw7/WU2kbJ+VeorGLxBi ZZ959GcHX084wvL5EaczrQaXHbLIF784gkGWHTyh7g== X-Google-Smtp-Source: APXvYqwYyimiAXF9GFpmoWjkeLpxZAVT1sw988pbvyOIWijKr+khjLBniVC+M11IYa0DLswdQMWJYiVEA+7edQrYJVU= X-Received: by 2002:aca:2112:: with SMTP id 18mr788817oiz.155.1581341918727; Mon, 10 Feb 2020 05:38:38 -0800 (PST) MIME-Version: 1.0 References: <26B88005-28E6-4A09-B3A7-DC982DABE679@lca.pw> <1581341769.7365.25.camel@lca.pw> In-Reply-To: <1581341769.7365.25.camel@lca.pw> From: Marco Elver Date: Mon, 10 Feb 2020 14:38:27 +0100 Message-ID: Subject: Re: [PATCH] mm: fix a data race in put_page() To: Qian Cai Cc: John Hubbard , Jan Kara , David Hildenbrand , Andrew Morton , ira.weiny@intel.com, Dan Williams , Linux Memory Management List , Linux Kernel Mailing List , "Paul E. McKenney" , kasan-dev 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 Mon, 10 Feb 2020 at 14:36, Qian Cai wrote: > > On Mon, 2020-02-10 at 13:58 +0100, Marco Elver wrote: > > On Mon, 10 Feb 2020 at 13:16, Qian Cai wrote: > > > > > > > > > > > > > On Feb 10, 2020, at 2:48 AM, Marco Elver wrote: > > > > > > > > Here is an alternative: > > > > > > > > Let's say KCSAN gives you this: > > > > /* ... Assert that the bits set in mask are not written > > > > concurrently; they may still be read concurrently. > > > > The access that immediately follows is assumed to access those > > > > bits and safe w.r.t. data races. > > > > > > > > For example, this may be used when certain bits of @flags may > > > > only be modified when holding the appropriate lock, > > > > but other bits may still be modified locklessly. > > > > ... > > > > */ > > > > #define ASSERT_EXCLUSIVE_BITS(flags, mask) .... > > > > > > > > Then we can write page_zonenum as follows: > > > > > > > > static inline enum zone_type page_zonenum(const struct page *page) > > > > { > > > > + ASSERT_EXCLUSIVE_BITS(page->flags, ZONES_MASK << ZONES_PGSH= IFT); > > > > return (page->flags >> ZONES_PGSHIFT) & ZONES_MASK; > > > > } > > > > > > > > This will accomplish the following: > > > > 1. The current code is not touched, and we do not have to verify th= at > > > > the change is correct without KCSAN. > > > > 2. We're not introducing a bunch of special macros to read bits in = various ways. > > > > 3. KCSAN will assume that the access is safe, and no data race repo= rt > > > > is generated. > > > > 4. If somebody modifies ZONES bits concurrently, KCSAN will tell yo= u > > > > about the race. > > > > 5. We're documenting the code. > > > > > > > > Anything I missed? > > > > > > I don=E2=80=99t know. Having to write the same line twice does not fe= el me any better than data_race() with commenting occasionally. > > > > Point 4 above: While data_race() will ignore cause KCSAN to not report > > the data race, now you might be missing a real bug: if somebody > > concurrently modifies the bits accessed, you want to know about it! > > Either way, it's up to you to add the ASSERT_EXCLUSIVE_BITS, but just > > remember that if you decide to silence it with data_race(), you need > > to be sure there are no concurrent writers to those bits. > > Right, in this case, there is no concurrent writers to those bits, so I'l= l add a > comment should be sufficient. However, I'll keep ASSERT_EXCLUSIVE_BITS() = in mind > for other places. Right now there are no concurrent writers to those bits. But somebody might introduce a bug that will write them, even though they shouldn't have. With ASSERT_EXCLUSIVE_BITS() you can catch that. Once I have the patches for this out, I would consider adding it here for this reason. > > > > There is no way to automatically infer all over the kernel which bits > > we care about, and the most reliable is to be explicit about it. I > > don't see a problem with it per se. > > > > Thanks, > > -- Marco