1. 18 3月, 2020 1 次提交
  2. 13 3月, 2020 1 次提交
  3. 11 3月, 2020 2 次提交
  4. 10 3月, 2020 1 次提交
  5. 05 3月, 2020 4 次提交
    • B
      RDMA/iwcm: Fix iwcm work deallocation · 810dbc69
      Bernard Metzler 提交于
      The dealloc_work_entries() function must update the work_free_list pointer
      while freeing its entries, since potentially called again on same list. A
      second iteration of the work list caused system crash. This happens, if
      work allocation fails during cma_iw_listen() and free_cm_id() tries to
      free the list again during cleanup.
      
      Fixes: 922a8e9f ("RDMA: iWARP Connection Manager.")
      Link: https://lore.kernel.org/r/20200302181614.17042-1-bmt@zurich.ibm.com
      Reported-by: syzbot+cb0c054eabfba4342146@syzkaller.appspotmail.com
      Signed-off-by: NBernard Metzler <bmt@zurich.ibm.com>
      Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      810dbc69
    • M
      RDMA/nldev: Fix crash when set a QP to a new counter but QPN is missing · 78f34a16
      Mark Zhang 提交于
      This fixes the kernel crash when a RDMA_NLDEV_CMD_STAT_SET command is
      received, but the QP number parameter is not available.
      
        iwpm_register_pid: Unable to send a nlmsg (client = 2)
        infiniband syz1: RDMA CMA: cma_listen_on_dev, error -98
        general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
        KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
        CPU: 0 PID: 9754 Comm: syz-executor069 Not tainted 5.6.0-rc2-syzkaller #0
        Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
        RIP: 0010:nla_get_u32 include/net/netlink.h:1474 [inline]
        RIP: 0010:nldev_stat_set_doit+0x63c/0xb70 drivers/infiniband/core/nldev.c:1760
        Code: fc 01 0f 84 58 03 00 00 e8 41 83 bf fb 4c 8b a3 58 fd ff ff 48 b8 00 00 00 00 00 fc ff df 49 8d 7c 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 6d
        RSP: 0018:ffffc900068bf350 EFLAGS: 00010247
        RAX: dffffc0000000000 RBX: ffffc900068bf728 RCX: ffffffff85b60470
        RDX: 0000000000000000 RSI: ffffffff85b6047f RDI: 0000000000000004
        RBP: ffffc900068bf750 R08: ffff88808c3ee140 R09: ffff8880a25e6010
        R10: ffffed10144bcddc R11: ffff8880a25e6ee3 R12: 0000000000000000
        R13: ffff88809acb0000 R14: ffff888092a42c80 R15: 000000009ef2e29a
        FS:  0000000001ff0880(0000) GS:ffff8880ae800000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 00007f4733e34000 CR3: 00000000a9b27000 CR4: 00000000001406f0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
          rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:195 [inline]
          rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
          rdma_nl_rcv+0x5d9/0x980 drivers/infiniband/core/netlink.c:259
          netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
          netlink_unicast+0x59e/0x7e0 net/netlink/af_netlink.c:1329
          netlink_sendmsg+0x91c/0xea0 net/netlink/af_netlink.c:1918
          sock_sendmsg_nosec net/socket.c:652 [inline]
          sock_sendmsg+0xd7/0x130 net/socket.c:672
          ____sys_sendmsg+0x753/0x880 net/socket.c:2343
          ___sys_sendmsg+0x100/0x170 net/socket.c:2397
          __sys_sendmsg+0x105/0x1d0 net/socket.c:2430
          __do_sys_sendmsg net/socket.c:2439 [inline]
          __se_sys_sendmsg net/socket.c:2437 [inline]
          __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2437
          do_syscall_64+0xfa/0x790 arch/x86/entry/common.c:294
          entry_SYSCALL_64_after_hwframe+0x49/0xbe
        RIP: 0033:0x4403d9
        Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
        RSP: 002b:00007ffc0efbc5c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
        RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 00000000004403d9
        RDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000004
        RBP: 00000000006ca018 R08: 0000000000000008 R09: 00000000004002c8
        R10: 000000000000004a R11: 0000000000000246 R12: 0000000000401c60
        R13: 0000000000401cf0 R14: 0000000000000000 R15: 0000000000000000
      
      Fixes: b389327d ("RDMA/nldev: Allow counter manual mode configration through RDMA netlink")
      Link: https://lore.kernel.org/r/20200227125111.99142-1-leon@kernel.org
      Reported-by: syzbot+bd4af81bc51ee0283445@syzkaller.appspotmail.com
      Signed-off-by: NMark Zhang <markz@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      78f34a16
    • J
      RDMA/odp: Ensure the mm is still alive before creating an implicit child · a4e63bce
      Jason Gunthorpe 提交于
      Registration of a mmu_notifier requires the caller to hold a mmget() on
      the mm as registration is not permitted to race with exit_mmap(). There is
      a BUG_ON inside the mmu_notifier to guard against this.
      
      Normally creating a umem is done against current which implicitly holds
      the mmget(), however an implicit ODP child is created from a pagefault
      work queue and is not guaranteed to have a mmget().
      
      Call mmget() around this registration and abort faulting if the MM has
      gone to exit_mmap().
      
      Before the patch below the notifier was registered when the implicit ODP
      parent was created, so there was no chance to register a notifier outside
      of current.
      
      Fixes: c571feca ("RDMA/odp: use mmu_notifier_get/put for 'struct ib_ucontext_per_mm'")
      Link: https://lore.kernel.org/r/20200227114118.94736-1-leon@kernel.orgSigned-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      a4e63bce
    • M
      RDMA/core: Fix protection fault in ib_mr_pool_destroy · e38b55ea
      Maor Gottlieb 提交于
      Fix NULL pointer dereference in the error flow of ib_create_qp_user
      when accessing to uninitialized list pointers - rdma_mrs and sig_mrs.
      The following crash from syzkaller revealed it.
      
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        general protection fault: 0000 [#1] SMP KASAN PTI
        CPU: 1 PID: 23167 Comm: syz-executor.1 Not tainted 5.5.0-rc5 #2
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
        rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
        RIP: 0010:ib_mr_pool_destroy+0x81/0x1f0
        Code: 00 00 fc ff df 49 c1 ec 03 4d 01 fc e8 a8 ea 72 fe 41 80 3c 24 00
        0f 85 62 01 00 00 48 8b 13 48 89 d6 4c 8d 6a c8 48 c1 ee 03 <42> 80 3c
        3e 00 0f 85 34 01 00 00 48 8d 7a 08 4c 8b 02 48 89 fe 48
        RSP: 0018:ffffc9000951f8b0 EFLAGS: 00010046
        RAX: 0000000000040000 RBX: ffff88810f268038 RCX: ffffffff82c41628
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffc9000951f850
        RBP: ffff88810f268020 R08: 0000000000000004 R09: fffff520012a3f0a
        R10: 0000000000000001 R11: fffff520012a3f0a R12: ffffed1021e4d007
        R13: ffffffffffffffc8 R14: 0000000000000246 R15: dffffc0000000000
        FS:  00007f54bc788700(0000) GS:ffff88811b100000(0000)
        knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000000 CR3: 0000000116920002 CR4: 0000000000360ee0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         rdma_rw_cleanup_mrs+0x15/0x30
         ib_destroy_qp_user+0x674/0x7d0
         ib_create_qp_user+0xb01/0x11c0
         create_qp+0x1517/0x2130
         ib_uverbs_create_qp+0x13e/0x190
         ib_uverbs_write+0xaa5/0xdf0
         __vfs_write+0x7c/0x100
         vfs_write+0x168/0x4a0
         ksys_write+0xc8/0x200
         do_syscall_64+0x9c/0x390
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x465b49
        Code: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48 89
        f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01
        f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
        RSP: 002b:00007f54bc787c58 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
        RAX: ffffffffffffffda RBX: 000000000073bf00 RCX: 0000000000465b49
        RDX: 0000000000000040 RSI: 0000000020000540 RDI: 0000000000000003
        RBP: 00007f54bc787c70 R08: 0000000000000000 R09: 0000000000000000
        R10: 0000000000000000 R11: 0000000000000246 R12: 00007f54bc7886bc
        R13: 00000000004ca2ec R14: 000000000070ded0 R15: 0000000000000005
      
      Fixes: a060b562 ("IB/core: generic RDMA READ/WRITE API")
      Link: https://lore.kernel.org/r/20200227112708.93023-1-leon@kernel.orgSigned-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NJason Gunthorpe <jgg@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      e38b55ea
  6. 28 2月, 2020 3 次提交
    • M
      RDMA/core: Fix pkey and port assignment in get_new_pps · 801b67f3
      Maor Gottlieb 提交于
      When port is part of the modify mask, then we should take it from the
      qp_attr and not from the old pps. Same for PKEY. Otherwise there are
      panics in some configurations:
      
        RIP: 0010:get_pkey_idx_qp_list+0x50/0x80 [ib_core]
        Code: c7 18 e8 13 04 30 ef 0f b6 43 06 48 69 c0 b8 00 00 00 48 03 85 a0 04 00 00 48 8b 50 20 48 8d 48 20 48 39 ca 74 1a 0f b7 73 04 <66> 39 72 10 75 08 eb 10 66 39 72 10 74 0a 48 8b 12 48 39 ca 75 f2
        RSP: 0018:ffffafb3480932f0 EFLAGS: 00010203
        RAX: ffff98059ababa10 RBX: ffff980d926e8cc0 RCX: ffff98059ababa30
        RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff98059ababa28
        RBP: ffff98059b940000 R08: 00000000000310c0 R09: ffff97fe47c07480
        R10: 0000000000000036 R11: 0000000000000200 R12: 0000000000000071
        R13: ffff98059b940000 R14: ffff980d87f948a0 R15: 0000000000000000
        FS:  00007f88deb31740(0000) GS:ffff98059f600000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000000000010 CR3: 0000000853e26001 CR4: 00000000001606e0
        Call Trace:
         port_pkey_list_insert+0x3d/0x1b0 [ib_core]
         ? kmem_cache_alloc_trace+0x215/0x220
         ib_security_modify_qp+0x226/0x3a0 [ib_core]
         _ib_modify_qp+0xcf/0x390 [ib_core]
         ipoib_init_qp+0x7f/0x200 [ib_ipoib]
         ? rvt_modify_port+0xd0/0xd0 [rdmavt]
         ? ib_find_pkey+0x99/0xf0 [ib_core]
         ipoib_ib_dev_open_default+0x1a/0x200 [ib_ipoib]
         ipoib_ib_dev_open+0x96/0x130 [ib_ipoib]
         ipoib_open+0x44/0x130 [ib_ipoib]
         __dev_open+0xd1/0x160
         __dev_change_flags+0x1ab/0x1f0
         dev_change_flags+0x23/0x60
         do_setlink+0x328/0xe30
         ? __nla_validate_parse+0x54/0x900
         __rtnl_newlink+0x54e/0x810
         ? __alloc_pages_nodemask+0x17d/0x320
         ? page_fault+0x30/0x50
         ? _cond_resched+0x15/0x30
         ? kmem_cache_alloc_trace+0x1c8/0x220
         rtnl_newlink+0x43/0x60
         rtnetlink_rcv_msg+0x28f/0x350
         ? kmem_cache_alloc+0x1fb/0x200
         ? _cond_resched+0x15/0x30
         ? __kmalloc_node_track_caller+0x24d/0x2d0
         ? rtnl_calcit.isra.31+0x120/0x120
         netlink_rcv_skb+0xcb/0x100
         netlink_unicast+0x1e0/0x340
         netlink_sendmsg+0x317/0x480
         ? __check_object_size+0x48/0x1d0
         sock_sendmsg+0x65/0x80
         ____sys_sendmsg+0x223/0x260
         ? copy_msghdr_from_user+0xdc/0x140
         ___sys_sendmsg+0x7c/0xc0
         ? skb_dequeue+0x57/0x70
         ? __inode_wait_for_writeback+0x75/0xe0
         ? fsnotify_grab_connector+0x45/0x80
         ? __dentry_kill+0x12c/0x180
         __sys_sendmsg+0x58/0xa0
         do_syscall_64+0x5b/0x200
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
        RIP: 0033:0x7f88de467f10
      
      Link: https://lore.kernel.org/r/20200227125728.100551-1-leon@kernel.org
      Cc: <stable@vger.kernel.org>
      Fixes: 1dd01788 ("RDMA/core: Fix protection fault in get_pkey_idx_qp_list")
      Signed-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Tested-by: NMike Marciniszyn <mike.marciniszyn@intel.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      801b67f3
    • J
      RMDA/cm: Fix missing ib_cm_destroy_id() in ib_cm_insert_listen() · c14dfddb
      Jason Gunthorpe 提交于
      The algorithm pre-allocates a cm_id since allocation cannot be done while
      holding the cm.lock spinlock, however it doesn't free it on one error
      path, leading to a memory leak.
      
      Fixes: 067b171b ("IB/cm: Share listening CM IDs")
      Link: https://lore.kernel.org/r/20200221152023.GA8680@ziepe.caSigned-off-by: NJason Gunthorpe <jgg@mellanox.com>
      c14dfddb
    • J
      RDMA/ucma: Put a lock around every call to the rdma_cm layer · 7c119107
      Jason Gunthorpe 提交于
      The rdma_cm must be used single threaded.
      
      This appears to be a bug in the design, as it does have lots of locking
      that seems like it should allow concurrency. However, when it is all said
      and done every single place that uses the cma_exch() scheme is broken, and
      all the unlocked reads from the ucma of the cm_id data are wrong too.
      
      syzkaller has been finding endless bugs related to this.
      
      Fixing this in any elegant way is some enormous amount of work. Take a
      very big hammer and put a mutex around everything to do with the
      ucma_context at the top of every syscall.
      
      Fixes: 75216638 ("RDMA/cma: Export rdma cm interface to userspace")
      Link: https://lore.kernel.org/r/20200218210432.GA31966@ziepe.ca
      Reported-by: syzbot+adb15cf8c2798e4e0db4@syzkaller.appspotmail.com
      Reported-by: syzbot+e5579222b6a3edd96522@syzkaller.appspotmail.com
      Reported-by: syzbot+4b628fcc748474003457@syzkaller.appspotmail.com
      Reported-by: syzbot+29ee8f76017ce6cf03da@syzkaller.appspotmail.com
      Reported-by: syzbot+6956235342b7317ec564@syzkaller.appspotmail.com
      Reported-by: syzbot+b358909d8d01556b790b@syzkaller.appspotmail.com
      Reported-by: syzbot+6b46b135602a3f3ac99e@syzkaller.appspotmail.com
      Reported-by: syzbot+8458d13b13562abf6b77@syzkaller.appspotmail.com
      Reported-by: syzbot+bd034f3fdc0402e942ed@syzkaller.appspotmail.com
      Reported-by: syzbot+c92378b32760a4eef756@syzkaller.appspotmail.com
      Reported-by: syzbot+68b44a1597636e0b342c@syzkaller.appspotmail.com
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      7c119107
  7. 21 2月, 2020 2 次提交
  8. 20 2月, 2020 4 次提交
  9. 19 2月, 2020 1 次提交
  10. 14 2月, 2020 2 次提交
    • M
      RDMA/core: Add weak ordering dma attr to dma mapping · f03d9fad
      Michael Guralnik 提交于
      For memory regions registered with IB_ACCESS_RELAXED_ORDERING will be dma
      mapped with the DMA_ATTR_WEAK_ORDERING.
      
      This will allow reads and writes to the mapping to be weakly ordered, such
      change can enhance performance on some supporting architectures.
      
      Link: https://lore.kernel.org/r/20200212073559.684139-1-leon@kernel.orgSigned-off-by: NMichael Guralnik <michaelgur@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      f03d9fad
    • L
      RDMA/core: Fix protection fault in get_pkey_idx_qp_list · 1dd01788
      Leon Romanovsky 提交于
      We don't need to set pkey as valid in case that user set only one of pkey
      index or port number, otherwise it will be resulted in NULL pointer
      dereference while accessing to uninitialized pkey list.  The following
      crash from Syzkaller revealed it.
      
        kasan: CONFIG_KASAN_INLINE enabled
        kasan: GPF could be caused by NULL-ptr deref or user memory access
        general protection fault: 0000 [#1] SMP KASAN PTI
        CPU: 1 PID: 14753 Comm: syz-executor.2 Not tainted 5.5.0-rc5 #2
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
        rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
        RIP: 0010:get_pkey_idx_qp_list+0x161/0x2d0
        Code: 01 00 00 49 8b 5e 20 4c 39 e3 0f 84 b9 00 00 00 e8 e4 42 6e fe 48
        8d 7b 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04
        02 84 c0 74 08 3c 01 0f 8e d0 00 00 00 48 8d 7d 04 48 b8
        RSP: 0018:ffffc9000bc6f950 EFLAGS: 00010202
        RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff82c8bdec
        RDX: 0000000000000002 RSI: ffffc900030a8000 RDI: 0000000000000010
        RBP: ffff888112c8ce80 R08: 0000000000000004 R09: fffff5200178df1f
        R10: 0000000000000001 R11: fffff5200178df1f R12: ffff888115dc4430
        R13: ffff888115da8498 R14: ffff888115dc4410 R15: ffff888115da8000
        FS:  00007f20777de700(0000) GS:ffff88811b100000(0000)
        knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000001b2f721000 CR3: 00000001173ca002 CR4: 0000000000360ee0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
        Call Trace:
         port_pkey_list_insert+0xd7/0x7c0
         ib_security_modify_qp+0x6fa/0xfc0
         _ib_modify_qp+0x8c4/0xbf0
         modify_qp+0x10da/0x16d0
         ib_uverbs_modify_qp+0x9a/0x100
         ib_uverbs_write+0xaa5/0xdf0
         __vfs_write+0x7c/0x100
         vfs_write+0x168/0x4a0
         ksys_write+0xc8/0x200
         do_syscall_64+0x9c/0x390
         entry_SYSCALL_64_after_hwframe+0x44/0xa9
      
      Fixes: d291f1a6 ("IB/core: Enforce PKey security on QPs")
      Link: https://lore.kernel.org/r/20200212080651.GB679970@unrealSigned-off-by: NMaor Gottlieb <maorg@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Message-Id: <20200212080651.GB679970@unreal>
      1dd01788
  11. 13 2月, 2020 3 次提交
  12. 12 2月, 2020 7 次提交
  13. 01 2月, 2020 3 次提交
  14. 31 1月, 2020 1 次提交
    • J
      RDMA/core: Make the entire API tree static · 8889f6fa
      Jason Gunthorpe 提交于
      Compilation of mlx5 driver without CONFIG_INFINIBAND_USER_ACCESS generates
      the following error.
      
      on x86_64:
      
       ld: drivers/infiniband/hw/mlx5/main.o: in function `mlx5_ib_handler_MLX5_IB_METHOD_VAR_OBJ_ALLOC':
       main.c:(.text+0x186d): undefined reference to `ib_uverbs_get_ucontext_file'
       ld: drivers/infiniband/hw/mlx5/main.o:(.rodata+0x2480): undefined reference to `uverbs_idr_class'
       ld: drivers/infiniband/hw/mlx5/main.o:(.rodata+0x24d8): undefined reference to `uverbs_destroy_def_handler'
      
      This is happening because some parts of the UAPI description are not
      static. This is a hold over from earlier code that relied on struct
      pointers to refer to object types, now object types are referenced by
      number. Remove the unused globals and add statics to the remaining UAPI
      description elements.
      
      Remove the redundent #ifdefs around mlx5_ib_*defs and obsolete
      mlx5_ib_get_devx_tree().
      
      The compiler now trims alot more unused code, including the above
      problematic definitions when !CONFIG_INFINIBAND_USER_ACCESS.
      
      Fixes: 7be76bef ("IB/mlx5: Introduce VAR object and its alloc/destroy methods")
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Acked-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      8889f6fa
  15. 29 1月, 2020 2 次提交
  16. 26 1月, 2020 3 次提交