From: Bart Van Assche <bvanassche@acm.org>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leonro@mellanox.com>,
Doug Ledford <dledford@redhat.com>,
linux-rdma@vger.kernel.org, Bart Van Assche <bvanassche@acm.org>
Subject: [PATCH 15/15] RDMA/srpt: Postpone HCA removal until after configfs directory removal
Date: Mon, 30 Sep 2019 16:17:07 -0700 [thread overview]
Message-ID: <20190930231707.48259-16-bvanassche@acm.org> (raw)
In-Reply-To: <20190930231707.48259-1-bvanassche@acm.org>
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
==================================================================
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
---
drivers/infiniband/ulp/srpt/ib_srpt.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c b/drivers/infiniband/ulp/srpt/ib_srpt.c
index 0582b3d4ec4d..daf811abf40a 100644
--- a/drivers/infiniband/ulp/srpt/ib_srpt.c
+++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
@@ -2921,7 +2921,7 @@ static int srpt_release_sport(struct srpt_port *sport)
while (atomic_read(&sport->refcount) > 0 &&
wait_for_completion_timeout(&c, 5 * HZ) <= 0) {
- pr_info("%s_%d: waiting for unregistration of %d sessions ...\n",
+ pr_info("%s_%d: waiting for unregistration of %d sessions and configfs directories ...\n",
dev_name(&sport->sdev->device->dev), sport->port,
atomic_read(&sport->refcount));
rcu_read_lock();
@@ -3732,6 +3732,8 @@ static struct se_portal_group *srpt_make_tpg(struct se_wwn *wwn,
if (res)
return ERR_PTR(res);
+ atomic_inc(&sport->refcount);
+
return tpg;
}
@@ -3745,6 +3747,7 @@ static void srpt_drop_tpg(struct se_portal_group *tpg)
sport->enabled = false;
core_tpg_deregister(tpg);
+ srpt_drop_sport_ref(sport);
}
/**
--
2.23.0.444.g18eeb5a265-goog
next prev parent reply other threads:[~2019-09-30 23:17 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 23:16 [PATCH 00/15] RDMA patches for kernel v5.5 Bart Van Assche
2019-09-30 23:16 ` [PATCH 01/15] RDMA/ucma: Reduce the number of rdma_destroy_id() calls Bart Van Assche
2019-10-01 15:07 ` Jason Gunthorpe
2019-10-01 17:13 ` Bart Van Assche
2019-09-30 23:16 ` [PATCH 02/15] RDMA/iwcm: Fix a lock inversion issue Bart Van Assche
2019-10-01 15:17 ` Jason Gunthorpe
2019-09-30 23:16 ` [PATCH 03/15] RDMA/siw: Simplify several debug messages Bart Van Assche
2019-10-01 15:20 ` Jason Gunthorpe
2019-09-30 23:16 ` [PATCH 04/15] RDMA/siw: Fix port number endianness in a debug message Bart Van Assche
2019-10-01 15:20 ` Jason Gunthorpe
2019-09-30 23:16 ` [PATCH 05/15] RDMA/siw: Make node GUIDs valid EUI-64 identifiers Bart Van Assche
2019-09-30 23:16 ` [PATCH 06/15] RDMA/srp: Remove two casts Bart Van Assche
2019-09-30 23:16 ` [PATCH 07/15] RDMA/srp: Honor the max_send_sge device attribute Bart Van Assche
2019-09-30 23:17 ` [PATCH 08/15] RDMA/srp: Make route resolving error messages more informative Bart Van Assche
2019-09-30 23:17 ` [PATCH 09/15] RDMA/srpt: Fix handling of SR-IOV and iWARP ports Bart Van Assche
2019-10-02 14:14 ` Jason Gunthorpe
2019-10-02 15:21 ` Bart Van Assche
2019-10-02 16:51 ` Jason Gunthorpe
2019-10-02 17:24 ` Leon Romanovsky
2019-10-02 17:43 ` Bart Van Assche
2019-10-03 8:33 ` Leon Romanovsky
2019-09-30 23:17 ` [PATCH 10/15] RDMA/srpt: Fix handling of iWARP logins Bart Van Assche
2019-10-02 14:16 ` Jason Gunthorpe
2019-10-02 15:23 ` Bart Van Assche
2019-09-30 23:17 ` [PATCH 11/15] RDMA/srpt: Improve a debug message Bart Van Assche
2019-09-30 23:17 ` [PATCH 12/15] RDMA/srpt: Rework the approach for closing an RDMA channel Bart Van Assche
2019-09-30 23:17 ` [PATCH 13/15] RDMA/srpt: Rework the code that waits until an RDMA port is no longer in use Bart Van Assche
2019-09-30 23:17 ` [PATCH 14/15] RDMA/srpt: Make the code for handling port identities more systematic Bart Van Assche
2019-09-30 23:17 ` Bart Van Assche [this message]
2019-10-01 11:39 ` [PATCH 03/15] RDMA/siw: Simplify several debug messages Bernard Metzler
2019-10-01 11:45 ` [PATCH 04/15] RDMA/siw: Fix port number endianness in a debug message Bernard Metzler
2019-10-04 18:36 ` [PATCH 00/15] RDMA patches for kernel v5.5 Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190930231707.48259-16-bvanassche@acm.org \
--to=bvanassche@acm.org \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=leonro@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.