Message ID | 1581615390-9720-1-git-send-email-cai@lca.pw (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [-next,v2] mm/kmemleak: annotate various data races obj->ptr | expand |
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@lca.pw> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 3a4259eeb5a0..aa6832432d6a 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -1169,7 +1169,12 @@ static bool update_checksum(struct kmemleak_object *object) u32 old_csum = object->checksum; kasan_disable_current(); - object->checksum = crc32(0, (void *)object->pointer, object->size); + /* + * crc32() will dereference object->pointer. If an unstable value was + * returned due to a data race, it will be corrected in the next scan. + */ + object->checksum = data_race(crc32(0, (void *)object->pointer, + object->size)); kasan_enable_current(); return object->checksum != old_csum; @@ -1243,7 +1248,7 @@ static void scan_block(void *_start, void *_end, break; kasan_disable_current(); - pointer = *ptr; + pointer = data_race(*ptr); kasan_enable_current(); untagged_ptr = (unsigned long)kasan_reset_tag((void *)pointer);
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@lca.pw> --- v2: add a missing annotation. mm/kmemleak.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)