Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 28 Oct 2019 18:46:49 +0100
From:   Marco Elver <elver@google.com>
To:     Christian Brauner <christian.brauner@ubuntu.com>
Cc:     Oleg Nesterov <oleg@redhat.com>, dvyukov@google.com,
        ebiederm@xmission.com, linux-kernel@vger.kernel.org,
        syzkaller-bugs@googlegroups.com
Subject: Re: [PATCH cgroup/for-5.5] cgroup: remove
 cgroup_enable_task_cg_lists() optimization
Message-ID: <20191028174649.GA63741@google.com>
References: <20191021142111.GB1339@redhat.com>
 <20191024190351.GD3622521@devbig004.ftw2.facebook.com>
 <20191025125606.GI3622521@devbig004.ftw2.facebook.com>
 <20191025133358.pxpzxkhqc3mboi5x@wittgenstein>
 <20191025141325.GB6020@redhat.com>
 <20191025143224.wtwkkimqq4644iqq@wittgenstein>
 <20191025155224.GC6020@redhat.com>
 <20191025170523.u43rkulrui22ynix@wittgenstein>
 <20191028164852.GA17900@redhat.com>
 <20191028173031.m32p5e3ek764hnre@wittgenstein>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191028173031.m32p5e3ek764hnre@wittgenstein>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


On Mon, 28 Oct 2019, Christian Brauner wrote:

> On Mon, Oct 28, 2019 at 05:48:52PM +0100, Oleg Nesterov wrote:
> > On 10/25, Christian Brauner wrote:
> > 
> > It is not that this code lacked READ_ONCE(). I am sure me and others
> > understood that this code can read ->exit_state more than once, just
> > nobody noticed that in this case this is really wrong.
> > 
> > IOW, if we simply change the code before 3245d6acab98 to use READ_ONCE()
> > the code will be equally wrong, and
> > 
> > > and as far as I understand this would also help kcsan to better detect
> > > races.
> > 
> > this change will simply hide the problem from kcsan.
> 
> I can't speak to that since the claim that read_once() helps them even
> if it's not really doing anything. But maybe I misunderstood the
> k{c,t}san manpage.

What Oleg said is right: marking things _ONCE will make these accesses
no longer be data races, and  KCSAN would then no longer report these as
data race, even if the code is still buggy due to there being a race
condition. In this case, the race condition would stop also being a data
race, and we'd no longer find it.

Thanks,
-- Marco