lkml.org 
[lkml]   [2018]   [Jun]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: WARNING: bad unlock balance in ucma_event_handler
    On Wed, Jun 13, 2018 at 06:47:02AM -0700, syzbot wrote:
    > Hello,
    >
    > syzbot found the following crash on:
    >
    > HEAD commit: 73fcb1a370c7 Merge branch 'akpm' (patches from Andrew)
    > git tree: upstream
    > console output: https://syzkaller.appspot.com/x/log.txt?x=16d70827800000
    > kernel config: https://syzkaller.appspot.com/x/.config?x=f3b4e30da84ec1ed
    > dashboard link: https://syzkaller.appspot.com/bug?extid=e5579222b6a3edd96522
    > compiler: gcc (GCC) 8.0.1 20180413 (experimental)
    > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=176daf97800000
    > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15e7bd57800000
    >
    > IMPORTANT: if you fix the bug, please add the following tag to the commit:
    > Reported-by: syzbot+e5579222b6a3edd96522@syzkaller.appspotmail.com
    >
    >
    > =====================================
    > WARNING: bad unlock balance detected!
    > 4.17.0-rc5+ #58 Not tainted
    > kworker/u4:0/6 is trying to release lock (&file->mut) at:
    > [<ffffffff8593ecc0>] ucma_event_handler+0x780/0xff0
    > drivers/infiniband/core/ucma.c:390
    > but there are no more locks to release!
    >
    > other info that might help us debug this:
    > 4 locks held by kworker/u4:0/6:
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at:
    > __write_once_size include/linux/compiler.h:215 [inline]
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at:
    > arch_atomic64_set arch/x86/include/asm/atomic64_64.h:34 [inline]
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at: atomic64_set
    > include/asm-generic/atomic-instrumented.h:40 [inline]
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at: atomic_long_set
    > include/asm-generic/atomic-long.h:57 [inline]
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at: set_work_data
    > kernel/workqueue.c:617 [inline]
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at:
    > set_work_pool_and_clear_pending kernel/workqueue.c:644 [inline]
    > #0: (ptrval) ((wq_completion)"ib_addr"){+.+.}, at:
    > process_one_work+0xaef/0x1b50 kernel/workqueue.c:2116
    > #1: (ptrval) ((work_completion)(&(&req->work)->work)){+.+.}, at:
    > process_one_work+0xb46/0x1b50 kernel/workqueue.c:2120
    > #2: (ptrval) (&id_priv->handler_mutex){+.+.}, at:
    > addr_handler+0xa6/0x3d0 drivers/infiniband/core/cma.c:2796
    > #3: (ptrval) (&file->mut){+.+.}, at: ucma_event_handler+0x10e/0xff0
    > drivers/infiniband/core/ucma.c:350

    I think this is probably a use-after-free race, eg when we do
    ctx->file->mut we have raced with ucma_free_ctx() ..

    Which probably means something along the way to free_ctx() did not
    call rdma_addr_cancel?

    Jason

    \
     
     \ /
      Last update: 2018-06-13 19:06    [W:2.664 / U:0.636 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site