On Thu, 6 Feb 2020 19:37:15 -0500 Qian Cai <cai@xxxxxx> wrote: > swap_cache_info.* could be accessed concurrently as noticed by > KCSAN, > > BUG: KCSAN: data-race in lookup_swap_cache / lookup_swap_cache > > write to 0xffffffff85517318 of 8 bytes by task 94138 on cpu 101: > lookup_swap_cache+0x12e/0x460 > lookup_swap_cache at mm/swap_state.c:322 > do_swap_page+0x112/0xeb0 > __handle_mm_fault+0xc7a/0xd00 > handle_mm_fault+0xfc/0x2f0 > do_page_fault+0x263/0x6f9 > page_fault+0x34/0x40 > > ... > > --- a/mm/swap_state.c > +++ b/mm/swap_state.c > @@ -58,8 +58,8 @@ static bool enable_vma_readahead __read_mostly = true; > #define GET_SWAP_RA_VAL(vma) \ > (atomic_long_read(&(vma)->swap_readahead_info) ? : 4) > > -#define INC_CACHE_INFO(x) do { swap_cache_info.x++; } while (0) > -#define ADD_CACHE_INFO(x, nr) do { swap_cache_info.x += (nr); } while (0) > +#define INC_CACHE_INFO(x) data_race(swap_cache_info.x++) > +#define ADD_CACHE_INFO(x, nr) data_race(swap_cache_info.x += (nr)) The data_race() macro appears to be stuck in Paul's linx-next tree. Can we expect this to be mainlined soon, or is there an issue?