| Message ID | 20200207003715.1578-1-cai@lca.pw (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [-next] mm/swap_state: mark various intentional data races | expand |
On Thu, 6 Feb 2020 19:37:15 -0500 Qian Cai <cai@lca.pw> 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?
> On Feb 9, 2020, at 9:00 PM, Andrew Morton <akpm@linux-foundation.org> wrote: > > 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? I read Paul is trying to get this merged into the mainline no later than v5.7-rc1 or sooner. lore.kernel.org/lkml/20200131211950.GX2935@paulmck-ThinkPad-P72/
On Sun, 9 Feb 2020 21:56:38 -0500 Qian Cai <cai@lca.pw> wrote: > > > > On Feb 9, 2020, at 9:00 PM, Andrew Morton <akpm@linux-foundation.org> wrote: > > > > 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? > > I read Paul is trying to get this merged into the mainline no later than v5.7-rc1 or sooner. > > lore.kernel.org/lkml/20200131211950.GX2935@paulmck-ThinkPad-P72/ OK, thanks. c48981eeb0d5 clearly can't break anything as it simply adds a macro. Ingo, can we please get that upstream soonish?
diff --git a/mm/swap_state.c b/mm/swap_state.c index 8e7ce9a9bc5e..c0fcae432bdf 100644 --- 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)) static struct { unsigned long add_total;
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 read to 0xffffffff85517318 of 8 bytes by task 91655 on cpu 100: lookup_swap_cache+0x117/0x460 lookup_swap_cache at mm/swap_state.c:322 shmem_swapin_page+0xc7/0x9e0 shmem_getpage_gfp+0x2ca/0x16c0 shmem_fault+0xef/0x3c0 __do_fault+0x9e/0x220 do_fault+0x4a0/0x920 __handle_mm_fault+0xc69/0xd00 handle_mm_fault+0xfc/0x2f0 do_page_fault+0x263/0x6f9 page_fault+0x34/0x40 Reported by Kernel Concurrency Sanitizer on: CPU: 100 PID: 91655 Comm: systemd-journal Tainted: G W O L 5.5.0-next-20200204+ #6 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019 write to 0xffffffff8d717308 of 8 bytes by task 11365 on cpu 87: __delete_from_swap_cache+0x681/0x8b0 __delete_from_swap_cache at mm/swap_state.c:178 read to 0xffffffff8d717308 of 8 bytes by task 11275 on cpu 53: __delete_from_swap_cache+0x66e/0x8b0 __delete_from_swap_cache at mm/swap_state.c:178 Both the read and write are done as lockless. Since swap_cache_info.* are only used to print out counter information, even if any of them missed a few incremental due to data races, it will be harmless, so just mark it as an intentional data race using the data_race() macro. While at it, fix a checkpatch.pl warning, WARNING: Single statement macros should not use a do {} while (0) loop Signed-off-by: Qian Cai <cai@lca.pw> --- mm/swap_state.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)