lkml.org 
[lkml]   [2020]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    From
    Subject[PATCH 5.6 31/38] RDMA/cma: Teach lockdep about the order of rtnl and lock
    Date
    From: Jason Gunthorpe <jgg@mellanox.com>

    commit 32ac9e4399b12d3e54d312a0e0e30ed5cd19bd4e upstream.

    This lock ordering only happens when bonding is enabled and a certain
    bonding related event fires. However, since it can happen this is a global
    restriction on lock ordering.

    Teach lockdep about the order directly and unconditionally so bugs here
    are found quickly.

    See https://syzkaller.appspot.com/bug?extid=55de90ab5f44172b0c90

    Link: https://lore.kernel.org/r/20200227203651.GA27185@ziepe.ca
    Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

    ---
    drivers/infiniband/core/cma.c | 13 +++++++++++++
    1 file changed, 13 insertions(+)

    --- a/drivers/infiniband/core/cma.c
    +++ b/drivers/infiniband/core/cma.c
    @@ -4790,6 +4790,19 @@ static int __init cma_init(void)
    {
    int ret;

    + /*
    + * There is a rare lock ordering dependency in cma_netdev_callback()
    + * that only happens when bonding is enabled. Teach lockdep that rtnl
    + * must never be nested under lock so it can find these without having
    + * to test with bonding.
    + */
    + if (IS_ENABLED(CONFIG_LOCKDEP)) {
    + rtnl_lock();
    + mutex_lock(&lock);
    + mutex_unlock(&lock);
    + rtnl_unlock();
    + }
    +
    cma_wq = alloc_ordered_workqueue("rdma_cm", WQ_MEM_RECLAIM);
    if (!cma_wq)
    return -ENOMEM;

    \
     
     \ /
      Last update: 2020-04-11 14:22    [W:4.375 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site