On Wed, 2018-03-14 at 16:46 -0400, Doug Ledford wrote:
> On Wed, 2018-03-14 at 09:14 +0200, Leon Romanovsky wrote:
> > From: Mark Bloch <markb@xxxxxxxxxxxx>
> >
> > On load we create private CQ/QP/PD in order to be used by UMR, we
> > create
> > those resources after we register ourself as an IB device, and we
> > destroy
> > them after we unregister as an IB device. This was changed by
> > commit
> > 16c1975f1032 ("IB/mlx5: Create profile infrastructure to add and
> > remove
> > stages") which moved the destruction before we unregistration. This
> > allowed to trigger an invalid memory access when unloading mlx5_ib
> > while
> > there are open resources:
> >
> > BUG: unable to handle kernel paging request at 00000001002c012c
> > ...
> > Call Trace:
> > mlx5_ib_post_send_wait+0x75/0x110 [mlx5_ib]
> > __slab_free+0x9a/0x2d0
> > delay_time_func+0x10/0x10 [mlx5_ib]
> > unreg_umr.isra.15+0x4b/0x50 [mlx5_ib]
> > mlx5_mr_cache_free+0x46/0x150 [mlx5_ib]
> > clean_mr+0xc9/0x190 [mlx5_ib]
> > dereg_mr+0xba/0xf0 [mlx5_ib]
> > ib_dereg_mr+0x13/0x20 [ib_core]
> > remove_commit_idr_uobject+0x16/0x70 [ib_uverbs]
> > uverbs_cleanup_ucontext+0xe8/0x1a0 [ib_uverbs]
> > ib_uverbs_cleanup_ucontext.isra.9+0x19/0x40 [ib_uverbs]
> > ib_uverbs_remove_one+0x162/0x2e0 [ib_uverbs]
> > ib_unregister_device+0xd4/0x190 [ib_core]
> > __mlx5_ib_remove+0x2e/0x40 [mlx5_ib]
> > mlx5_remove_device+0xf5/0x120 [mlx5_core]
> > mlx5_unregister_interface+0x37/0x90 [mlx5_core]
> > mlx5_ib_cleanup+0xc/0x225 [mlx5_ib]
> > SyS_delete_module+0x153/0x230
> > do_syscall_64+0x62/0x110
> > entry_SYSCALL_64_after_hwframe+0x21/0x86
> > ...
> >
> > We restore the original behavior by breaking the UMR stage into two
> > parts,
> > pre and post IB registration stages, this way we can restore the
> > original
> > functionality and maintain clean separation of logic between
> > stages.
> >
> > Fixes: 16c1975f1032 ("IB/mlx5: Create profile infrastructure to add
> > and remove stages")
> > Signed-off-by: Mark Bloch <markb@xxxxxxxxxxxx>
> > Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxxxx>
> > ---
> > Hi,
> >
> > Please be aware that this patch will create merge conflict between
> > rdma-rc and rdma-next.
>
> Yeah, we'll get a chance to work through that. I've applied this to
> for-rc, and I have plans to merge for-rc into for-next (I need to do
> that before I take the 5 patch series I said I was taking, but that I
> haven't actually applied yet because it needs the merge between for-
> rc
> and for-next before I apply it). So, we'll get to fix this up before
> the for-next branch heads to Linus. And the cause of the merge issue
> is
> understandable, so I don't have a problem with it.
Is this the fix for the issue I worked with Jason which we had to pull
for RHEL 7.5
Regards
Laurence
>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
