On Thu, Feb 13, 2020 at 12:36:30PM -0500, Qian Cai wrote: > The value of object->pointer could be accessed concurrently as noticed > by KCSAN, > > write to 0xffffb0ea683a7d50 of 4 bytes by task 23575 on cpu 12: > do_raw_spin_lock+0x114/0x200 > debug_spin_lock_after at kernel/locking/spinlock_debug.c:91 > (inlined by) do_raw_spin_lock at kernel/locking/spinlock_debug.c:115 > _raw_spin_lock+0x40/0x50 > __handle_mm_fault+0xa9e/0xd00 > handle_mm_fault+0xfc/0x2f0 > do_page_fault+0x263/0x6f9 > page_fault+0x34/0x40 > > read to 0xffffb0ea683a7d50 of 4 bytes by task 839 on cpu 60: > crc32_le_base+0x67/0x350 > crc32_le_base+0x67/0x350: > crc32_body at lib/crc32.c:106 > (inlined by) crc32_le_generic at lib/crc32.c:179 > (inlined by) crc32_le at lib/crc32.c:197 > kmemleak_scan+0x528/0xd90 > update_checksum at mm/kmemleak.c:1172 > (inlined by) kmemleak_scan at mm/kmemleak.c:1497 > kmemleak_scan_thread+0xcc/0xfa > kthread+0x1e0/0x200 > ret_from_fork+0x27/0x50 > > write to 0xffff939bf07b95b8 of 4 bytes by interrupt on cpu 119: > __free_object+0x884/0xcb0 > __free_object at lib/debugobjects.c:359 > __debug_check_no_obj_freed+0x19d/0x370 > debug_check_no_obj_freed+0x41/0x4b > slab_free_freelist_hook+0xfb/0x1c0 > kmem_cache_free+0x10c/0x3a0 > free_object_rcu+0x1ca/0x260 > rcu_core+0x677/0xcc0 > rcu_core_si+0x17/0x20 > __do_softirq+0xd9/0x57c > run_ksoftirqd+0x29/0x50 > smpboot_thread_fn+0x222/0x3f0 > kthread+0x1e0/0x200 > ret_from_fork+0x27/0x50 > > read to 0xffff939bf07b95b8 of 8 bytes by task 838 on cpu 109: > scan_block+0x69/0x190 > scan_block at mm/kmemleak.c:1250 > kmemleak_scan+0x249/0xd90 > scan_large_block at mm/kmemleak.c:1309 > (inlined by) kmemleak_scan at mm/kmemleak.c:1434 > kmemleak_scan_thread+0xcc/0xfa > kthread+0x1e0/0x200 > ret_from_fork+0x27/0x50 > > crc32() will dereference object->pointer. If a shattered value was > returned due to a data race, it will be corrected in the next scan. > scan_block() will dereference a range of addresses (e.g., percpu > sections) to search for valid pointers. Even if a data race heppens, it > will cause no issue because the code here does not care about the exact > value of a non-pointer. Thus, mark them as intentional data races using > the data_race() macro. > > Signed-off-by: Qian Cai <cai@xxxxxx> Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx>
