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?
