Messages in this thread | | | Subject | Re: [PATCH -next] lib: disable KCSAN for XArray | From | Qian Cai <> | Date | Wed, 04 Mar 2020 12:10:58 -0500 |
| |
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.
| |