linux-kernel - Re: [PATCH -next] lib: disable KCSAN for XArray

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1583341858.7365.155.camel@lca.pw>
Date:   Wed, 04 Mar 2020 12:10:58 -0500
From:   Qian Cai <cai@....pw>
To:     Marco Elver <elver@...gle.com>,
        "Paul E. McKenney" <paulmck@...nel.org>
Cc:     Matthew Wilcox <willy@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -next] lib: disable KCSAN for XArray

On Wed, 2020-03-04 at 17:40 +0100, Marco Elver wrote:
> On Wed, 4 Mar 2020 at 15:10, Paul E. McKenney <paulmck@...nel.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.