All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qian Cai <cai@lca.pw>
To: Marco Elver <elver@google.com>
Cc: John Hubbard <jhubbard@nvidia.com>, Jan Kara <jack@suse.cz>,
	David Hildenbrand <david@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	ira.weiny@intel.com, Dan Williams <dan.j.williams@intel.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	kasan-dev <kasan-dev@googlegroups.com>
Subject: Re: [PATCH] mm: fix a data race in put_page()
Date: Mon, 10 Feb 2020 07:16:36 -0500	[thread overview]
Message-ID: <26B88005-28E6-4A09-B3A7-DC982DABE679@lca.pw> (raw)
In-Reply-To: <CANpmjNNaHAnKCMLb+Njs3AhEoJT9O6-Yh63fcNcVTjBbNQiEPg@mail.gmail.com>



> On Feb 10, 2020, at 2:48 AM, Marco Elver <elver@google.com> 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_PGSHIFT);
>        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 that
> 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 report
> is generated.
> 4. If somebody modifies ZONES bits concurrently, KCSAN will tell you
> about the race.
> 5. We're documenting the code.
> 
> Anything I missed?

I don’t know. Having to write the same line twice does not feel me any better than data_race() with commenting occasionally.

  reply	other threads:[~2020-02-10 12:16 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-06 13:17 [PATCH] mm: fix a data race in put_page() Qian Cai
2020-02-06 13:33 ` David Hildenbrand
2020-02-06 13:51   ` Qian Cai
2020-02-06 13:51     ` Qian Cai
2020-02-06 14:55   ` Jan Kara
2020-02-06 14:59     ` David Hildenbrand
2020-02-06 15:23     ` Qian Cai
2020-02-06 23:34       ` John Hubbard
2020-02-06 23:36         ` John Hubbard
2020-02-06 23:55         ` Qian Cai
2020-02-07  0:18         ` Qian Cai
2020-02-07  0:27           ` John Hubbard
2020-02-07  0:55             ` Qian Cai
2020-02-07 13:17               ` Marco Elver
2020-02-07 13:17                 ` Marco Elver
2020-02-09  1:44                 ` John Hubbard
2020-02-09  3:10                   ` Qian Cai
2020-02-09  7:12                     ` John Hubbard
2020-02-10  7:48                       ` Marco Elver
2020-02-10  7:48                         ` Marco Elver
2020-02-10 12:16                         ` Qian Cai [this message]
2020-02-10 12:58                           ` Marco Elver
2020-02-10 12:58                             ` Marco Elver
2020-02-10 13:36                             ` Qian Cai
2020-02-10 13:38                               ` Marco Elver
2020-02-10 13:38                                 ` Marco Elver
2020-02-10 13:55                                 ` Qian Cai
2020-02-10 14:12                                   ` Marco Elver
2020-02-10 14:12                                     ` Marco Elver
2020-02-10 14:31                                     ` Qian Cai
2020-02-10 16:23                         ` Qian Cai
2020-02-10 16:23                           ` Qian Cai
2020-02-10 16:33                           ` Marco Elver
2020-02-10 16:33                             ` Marco Elver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26B88005-28E6-4A09-B3A7-DC982DABE679@lca.pw \
    --to=cai@lca.pw \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=david@redhat.com \
    --cc=elver@google.com \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jhubbard@nvidia.com \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=paulmck@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.