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:   Wed, 4 Mar 2020 09:14:41 -0800
From:   "Paul E. McKenney" <paulmck@kernel.org>
To:     Qian Cai <cai@lca.pw>
Cc:     Marco Elver <elver@google.com>,
        Matthew Wilcox <willy@infradead.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next] lib: disable KCSAN for XArray
Message-ID: <20200304171441.GA2935@paulmck-ThinkPad-P72>
Reply-To: paulmck@kernel.org
References: <20200304031551.1326-1-cai@lca.pw>
 <20200304033329.GZ29971@bombadil.infradead.org>
 <20200304040515.GX2935@paulmck-ThinkPad-P72>
 <20200304043356.GC29971@bombadil.infradead.org>
 <20200304141021.GY2935@paulmck-ThinkPad-P72>
 <CANpmjNOotdBa_7EhA75f2Y59HfEVsGsquv1cvQ=OjtA784poRA@mail.gmail.com>
 <1583341858.7365.155.camel@lca.pw>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1583341858.7365.155.camel@lca.pw>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Mar 04, 2020 at 12:10:58PM -0500, Qian Cai wrote:
> On Wed, 2020-03-04 at 17:40 +0100, Marco Elver wrote:
> > On Wed, 4 Mar 2020 at 15:10, Paul E. McKenney <paulmck@kernel.org> wrote:
> > > 
> > > On Tue, Mar 03, 2020 at 08:33:56PM -0800, Matthew Wilcox wrote:
> > > > On Tue, Mar 03, 2020 at 08:05:15PM -0800, Paul E. McKenney wrote:
> > > > > On Tue, Mar 03, 2020 at 07:33:29PM -0800, Matthew Wilcox wrote:
> > > > > > On Tue, Mar 03, 2020 at 10:15:51PM -0500, Qian Cai wrote:
> > > > > > > Functions like xas_find_marked(), xas_set_mark(), and xas_clear_mark()
> > > > > > > could happen concurrently result in data races, but those operate only
> > > > > > > on a single bit that are pretty much harmless. For example,
> > 
> > I currently do not see those as justification to blacklist the whole
> > file. Wouldn't __no_kcsan be better? That is, in case there is no
> > other solution that emerges from the remainder of the discussion here.
> 
> I suppose it is up to Matthew. Currently, I can see there are several functions
> may need __no_kcsan,
> 
> xa_get_mark(), xas_find_marked(), xas_find_chunk() etc.
> 
> My worry was that there could be many of those functions operating on marks
> (which is a single-bit) in xarray that could end up needing the same treatment.
> 
> So far, my testing is thin on filesystem side where xarray is pretty much used
> for page caches, so the reports I got from KCSAN runs does not necessary tell
> the whole story. Once I updated my KCSAN runs to include things like xfstests,
> it could add quite a few churns later if we decided to go with?the __no_kcsan
> route.

Agreed, the filesystems developers and maintainers will decide how they
would like to approach this.

							Thanx, Paul