On 2018/11/8 0:42, Bart Van Assche wrote:
Hello,
If I run the srp tests from the blktests test suite long enough against
kernel v4.20-rc1 then the complaint shown below appears. Has anyone else
already encountered this? This is how I run the srp tests:
(cd blktests && while ./check -q srp; do :; done)
Thanks,
Bart.
==================================================================
BUG: KASAN: use-after-free in rxe_resp_queue_pkt+0x2b/0x70 [rdma_rxe]
Read of size 1 at addr ffff8800361722d5 by task kworker/1:2/26251
CPU: 1 PID: 26251 Comm: kworker/1:2 Not tainted 4.20.0-rc1-dbg+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
Workqueue: target_completion target_complete_ok_work [target_core_mod]
Call Trace:
<IRQ>
dump_stack+0x86/0xca
print_address_description+0x71/0x239
kasan_report.cold.5+0x242/0x301
__asan_load1+0x47/0x50
rxe_resp_queue_pkt+0x2b/0x70 [rdma_rxe]
Is it memory corruption?
first, rxe_resp_queue_pkt, then, rxe_responder.
But now it seems that first rxe_responder, then rxe_resp_queue_pkt
access it.
It is weird.
Zhu Yanjun
rxe_rcv+0x53e/0xb00 [rdma_rxe]
rxe_loopback+0xe/0x10 [rdma_rxe]
rxe_requester+0x13de/0x2130 [rdma_rxe]
rxe_do_task+0xdd/0x170 [rdma_rxe]
tasklet_action_common.isra.14+0xc0/0x280
tasklet_action+0x3d/0x50
__do_softirq+0x128/0x5ae
irq_exit+0xdd/0x100
smp_call_function_single_interrupt+0x90/0x2b0
call_function_single_interrupt+0xf/0x20
</IRQ>
RIP: 0010:_raw_spin_unlock_irq+0x32/0x50
Code: 00 00 00 48 89 e5 53 48 89 fb 48 83 c7 18 48 8b 55 08 e8 a1 ff 30 ff 48 89 df e8 79 67 31 ff e8 34 b6 40 ff fb bf 01 00 00 00 <e8> 09 e9 2b ff 65 8b 05 02 31 1d 7e 85 c0 74 03 5b 5d c3 e8 d9 7a
RSP: 0018:ffff8800b71e7d98 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff04
RAX: 0000000000000000 RBX: ffff88011b66ac80 RCX: ffffffff8115b2e6
RDX: 0000000000000007 RSI: dffffc0000000000 RDI: 0000000000000001
RBP: ffff8800b71e7da0 R08: ffffed00236cd591 R09: ffffed00236cd590
R10: ffffed00236cd590 R11: ffff88011b66ac83 R12: ffff880112b49a00
R13: ffff88011b66acd0 R14: ffff88011b66ac80 R15: ffff88011b66acd0
process_one_work+0x3e6/0x9f0
worker_thread+0x67/0x5b0
kthread+0x1cf/0x1f0
ret_from_fork+0x24/0x30
Allocated by task 26251:
save_stack+0x43/0xd0
kasan_kmalloc+0xc7/0xe0
kasan_slab_alloc+0x11/0x20
kmem_cache_alloc_node+0xf3/0x350
__alloc_skb+0xa8/0x310
rxe_init_packet+0xc8/0x220 [rdma_rxe]
rxe_requester+0x5f9/0x2130 [rdma_rxe]
rxe_do_task+0xdd/0x170 [rdma_rxe]
tasklet_action_common.isra.14+0xc0/0x280
tasklet_action+0x3d/0x50
__do_softirq+0x128/0x5ae
Freed by task 36:
save_stack+0x43/0xd0
__kasan_slab_free+0x139/0x190
kasan_slab_free+0xe/0x10
kmem_cache_free+0xbc/0x330
kfree_skbmem+0x66/0xa0
kfree_skb+0x80/0x1b0
rxe_responder+0x663/0x3760 [rdma_rxe]
rxe_do_task+0xdd/0x170 [rdma_rxe]
tasklet_action_common.isra.14+0xc0/0x280
tasklet_action+0x3d/0x50
__do_softirq+0x128/0x5ae
The buggy address belongs to the object at ffff880036172280
which belongs to the cache skbuff_head_cache of size 200
The buggy address is located 85 bytes inside of
200-byte region [ffff880036172280, ffff880036172348)
The buggy address belongs to the page:
page:ffffea0000d85c80 count:1 mapcount:0 mapping:ffff88011abb7200 index:0x0 compound_mapcount: 0
flags: 0x1fff000000010200(slab|head)
raw: 1fff000000010200 ffffea0002550a00 0000000600000006 ffff88011abb7200
raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff880036172180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880036172200: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff880036172280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880036172300: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
ffff880036172380: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
==================================================================
