From: Jason Gunthorpe <jgg@nvidia.com>
To: Leon Romanovsky <leon@kernel.org>
Cc: Doug Ledford <dledford@redhat.com>,
Leon Romanovsky <leonro@mellanox.com>,
<linux-rdma@vger.kernel.org>
Subject: Re: [PATCH rdma-rc] RDMA/core: Fix race between alloc_uobj and destroy_fd
Date: Thu, 16 Jul 2020 10:55:06 -0300 [thread overview]
Message-ID: <20200716135506.GA2626442@nvidia.com> (raw)
In-Reply-To: <20200716102059.1420681-1-leon@kernel.org>
On Thu, Jul 16, 2020 at 01:20:59PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@mellanox.com>
>
> Both new object allocation and FD destroy paths hold UVERBS_LOOKUP_WRITE,
> the race between them causes the following dump stack.
>
> [ 268.688470] ------------[ cut here ]------------
> [ 268.689460] WARNING: CPU: 4 PID: 6913 at drivers/infiniband/core/rdma_core.c:768 uverbs_uobject_fd_release+0x202/0x230
> [ 268.691322] Kernel panic - not syncing: panic_on_warn set ...
> [ 268.692273] CPU: 4 PID: 6913 Comm: syz-executor.3 Not tainted 5.7.0-rc2 #22
> [ 268.693456] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> [ 268.695688] Call Trace:
> [ 268.696135] dump_stack+0x94/0xce
> [ 268.696784] panic+0x234/0x56f
> [ 268.697384] ? __warn+0x1e1/0x1e1
> [ 268.697942] ? kmsg_dump_rewind_nolock+0xd9/0xd9
> [ 268.698782] ? printk+0xb2/0xdd
> [ 268.699301] ? __warn+0x1b1/0x1e1
> [ 268.699946] ? uverbs_uobject_fd_release+0x202/0x230
> [ 268.700829] __warn+0x1cc/0x1e1
> [ 268.701402] ? uverbs_uobject_fd_release+0x202/0x230
> [ 268.702227] report_bug+0x200/0x310
> [ 268.702807] ? uverbs_uobject_fd_release+0x202/0x230
> [ 268.703618] fixup_bug.part.11+0x32/0x80
> [ 268.704260] do_error_trap+0xd3/0x100
> [ 268.704898] do_invalid_op+0x31/0x40
> [ 268.705581] ? uverbs_uobject_fd_release+0x202/0x230
> [ 268.706479] invalid_op+0x1e/0x30
> [ 268.707035] RIP: 0010:uverbs_uobject_fd_release+0x202/0x230
> [ 268.708046] Code: fe 4c 89 e7 e8 af 23 fe ff e9 2a ff ff ff e8 c5 fa 61 fe be 03 00 00 00 4c 89 e7 e8 68 eb f5 fe e9 13 ff ff ff e8 ae fa 61 fe <0f> 0b eb ac e8 e5 aa 3c fe e8 50 2b 86 fe e9 6a fe ff ff e8 46 2b
> [ 268.711365] RSP: 0018:ffffc90008117d88 EFLAGS: 00010293
> [ 268.712218] RAX: ffff88810e146580 RBX: 1ffff92001022fb1 RCX: ffffffff82d5b902
> [ 268.713439] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88811951b040
> [ 268.714606] RBP: ffff88811951b000 R08: ffffed10232a3609 R09: ffffed10232a3609
> [ 268.715805] R10: ffff88811951b043 R11: 0000000000000001 R12: ffff888100a7c600
> [ 268.717119] R13: ffff888100a7c650 R14: ffffc90008117da8 R15: ffffffff82d5b700
> [ 268.718401] ? __uverbs_cleanup_ufile+0x270/0x270
> [ 268.719181] ? uverbs_uobject_fd_release+0x202/0x230
> [ 268.720140] ? uverbs_uobject_fd_release+0x202/0x230
> [ 268.720967] ? __uverbs_cleanup_ufile+0x270/0x270
> [ 268.721758] ? locks_remove_file+0x282/0x3d0
> [ 268.722529] ? security_file_free+0xaa/0xd0
> [ 268.723224] __fput+0x2be/0x770
> [ 268.723743] task_work_run+0x10e/0x1b0
> [ 268.724428] exit_to_usermode_loop+0x145/0x170
> [ 268.725172] do_syscall_64+0x2d0/0x390
> [ 268.725786] ? prepare_exit_to_usermode+0x17a/0x230
> [ 268.726580] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 268.727413] RIP: 0033:0x414da7
> [ 268.728029] Code: 00 00 0f 05 48 3d 00 f0 ff ff 77 3f f3 c3 0f 1f 44 00 00 53 89 fb 48 83 ec 10 e8 f4 fb ff ff 89 df 89 c2 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 2b 89 d7 89 44 24 0c e8 36 fc ff ff 8b 44 24
> [ 268.731055] RSP: 002b:00007fff39d379d0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
> [ 268.732322] RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000414da7
> [ 268.733587] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000003
> [ 268.734818] RBP: 00007fff39d37a3c R08: 0000000400000000 R09: 0000000400000000
> [ 268.736472] R10: 00007fff39d37910 R11: 0000000000000293 R12: 0000000000000001
> [ 268.737754] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000003
> [ 268.738983] Dumping ftrace buffer:
> [ 268.739601] (ftrace buffer empty)
> [ 268.740181] Kernel Offset: disabled
> [ 268.740770] Rebooting in 1 seconds..
>
> Fixes: aba94548c9e4 ("IB/uverbs: Move the FD uobj type struct file allocation to alloc_commit")
> Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
> ---
> drivers/infiniband/core/rdma_core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
Applied to for-rc
Thanks,
Jason
prev parent reply other threads:[~2020-07-16 13:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 10:20 [PATCH rdma-rc] RDMA/core: Fix race between alloc_uobj and destroy_fd Leon Romanovsky
2020-07-16 13:55 ` Jason Gunthorpe [this message]
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=20200716135506.GA2626442@nvidia.com \
--to=jgg@nvidia.com \
--cc=dledford@redhat.com \
--cc=leon@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).