Re: [PATCH -next] mm/swap_state: mark various intentional data races

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux