Re: [PATCH 01/11] IB/uverbs: Get rid of null_obj_type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 10, 2018 at 08:55:13PM -0600, Jason Gunthorpe wrote:
> From: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
>
> If the method fails after calling rdma_explicit_destroy (eg if
> copy_to_user faults) then it will trigger a kernel oops:
>
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
> PGD 800000000548d067 P4D 800000000548d067 PUD 54a0067 PMD 0
> SMP PTI
> CPU: 0 PID: 359 Comm: ibv_rc_pingpong Not tainted 4.18.0-rc1+ #28
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
> RIP: 0010:          (null)
> Code: Bad RIP value.
> RSP: 0018:ffffc900001a3bf0 EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff88000603bd00 RCX: 0000000000000003
> RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff88000603bd00
> RBP: 0000000000000001 R08: ffffc900001a3cf8 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: ffffc900001a3cf0
> R13: 0000000000000000 R14: ffffc900001a3cf0 R15: 0000000000000000
> FS:  00007fb00dda8700(0000) GS:ffff880007c00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: ffffffffffffffd6 CR3: 000000000548e004 CR4: 00000000003606b0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  ? rdma_lookup_put_uobject+0x22/0x50 [ib_uverbs]
>  ? uverbs_finalize_object+0x3b/0x60 [ib_uverbs]
>  ? uverbs_finalize_attrs+0x128/0x140 [ib_uverbs]
>  ? ib_uverbs_cmd_verbs+0x698/0x7c0 [ib_uverbs]
>  ? find_held_lock+0x2d/0x90
>  ? __might_fault+0x39/0x90
>  ? ib_uverbs_ioctl+0x111/0x1f0 [ib_uverbs]
>  ? do_vfs_ioctl+0xa0/0x6d0
>  ? trace_hardirqs_on_caller+0xed/0x180
>  ? _raw_spin_unlock_irq+0x24/0x40
>  ? syscall_trace_enter+0x138/0x1d0
>  ? ksys_ioctl+0x35/0x60
>  ? __x64_sys_ioctl+0x11/0x20
>  ? do_syscall_64+0x5b/0x1c0
>  ? entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> This is because the type was replaced with the null_type during explicit
> destroy that cannot complete the destruction.
>
> One of the side effects of replacing the type is to make the object
> handle totally unreachable - so no other command could attempt to use
> it, even though it remains on the uboject list.
>
> We can get the same end result by just fully destroying the object inside
> rdma_explicit_destroy and leaving the caller the residual kref for the
> uobj with no attached HW object, and no presence in the ubojects list.
>
> Signed-off-by: Jason Gunthorpe <jgg@xxxxxxxxxxxx>
> ---
>  drivers/infiniband/core/rdma_core.c | 41 +++++++----------------------
>  1 file changed, 9 insertions(+), 32 deletions(-)
>

Thanks,
Reviewed-by: Leon Romanovsky <leonro@xxxxxxxxxxxx>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux