RDMA/srpt: Postpone HCA removal until after configfs directory removal
A shortcoming of the SCSI target core is that it does not have an API
for removing tpg or wwn objects. Wait until these directories have been
removed before allowing HCA removal to finish.
See also Bart Van Assche, "Re: Why using configfs as the only interface is
wrong for a storage target", 2011-02-07
(https://www.spinics.net/lists/linux-scsi/msg50248.html).
This patch fixes the following kernel crash:
==================================================================
BUG: KASAN: use-after-free in __configfs_open_file.isra.4+0x1a8/0x400
Read of size 8 at addr
ffff88811880b690 by task restart-lio-srp/1215
CPU: 1 PID: 1215 Comm: restart-lio-srp Not tainted 5.3.0-dbg+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:
dump_stack+0x86/0xca
print_address_description+0x74/0x32d
__kasan_report.cold.6+0x1b/0x36
kasan_report+0x12/0x17
__asan_load8+0x54/0x90
__configfs_open_file.isra.4+0x1a8/0x400
configfs_open_file+0x13/0x20
do_dentry_open+0x2b1/0x770
vfs_open+0x58/0x60
path_openat+0x5fa/0x14b0
do_filp_open+0x115/0x180
do_sys_open+0x1d4/0x2a0
__x64_sys_openat+0x59/0x70
do_syscall_64+0x6b/0x2d0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f2f2bd3fcce
Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 05 19 d7 0d 00 8b 00 85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
RSP: 002b:
00007ffd155f7850 EFLAGS:
00000246 ORIG_RAX:
0000000000000101
RAX:
ffffffffffffffda RBX:
0000564609ba88e0 RCX:
00007f2f2bd3fcce
RDX:
0000000000000241 RSI:
0000564609ba8cf0 RDI:
00000000ffffff9c
RBP:
00007ffd155f7950 R08:
0000000000000000 R09:
0000000000000020
R10:
00000000000001b6 R11:
0000000000000246 R12:
0000000000000000
R13:
0000000000000003 R14:
0000000000000001 R15:
0000564609ba8cf0
Allocated by task 995:
save_stack+0x21/0x90
__kasan_kmalloc.constprop.9+0xc7/0xd0
kasan_kmalloc+0x9/0x10
__kmalloc+0x153/0x370
srpt_add_one+0x4f/0x561 [ib_srpt]
add_client_context+0x251/0x290 [ib_core]
ib_register_client+0x1da/0x220 [ib_core]
iblock_get_alignment_offset_lbas+0x6b/0x100 [target_core_iblock]
do_one_initcall+0xcd/0x43a
do_init_module+0x103/0x380
load_module+0x3b77/0x3eb0
__do_sys_finit_module+0x12d/0x1b0
__x64_sys_finit_module+0x43/0x50
do_syscall_64+0x6b/0x2d0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 1221:
save_stack+0x21/0x90
__kasan_slab_free+0x139/0x190
kasan_slab_free+0xe/0x10
slab_free_freelist_hook+0x67/0x1e0
kfree+0xcb/0x2a0
srpt_remove_one+0x596/0x670 [ib_srpt]
remove_client_context+0x9a/0xe0 [ib_core]
disable_device+0x106/0x1b0 [ib_core]
__ib_unregister_device+0x5f/0xf0 [ib_core]
ib_unregister_driver+0x11a/0x170 [ib_core]
0xffffffffa087f666
__x64_sys_delete_module+0x1f8/0x2c0
do_syscall_64+0x6b/0x2d0
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at
ffff88811880b300
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 912 bytes inside of
4096-byte region [
ffff88811880b300,
ffff88811880c300)
The buggy address belongs to the page:
page:
ffffea0004620200 refcount:1 mapcount:0 mapping:
ffff88811ac0de00 index:0x0 compound_mapcount: 0
flags: 0x2fff000000010200(slab|head)
raw:
2fff000000010200 dead000000000100 dead000000000122 ffff88811ac0de00
raw:
0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88811880b580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88811880b600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
ffff88811880b680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88811880b700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88811880b780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Link: https://lore.kernel.org/r/20190930231707.48259-16-bvanassche@acm.org
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>