1. 27 Mar, 2018 9 commits
    • Majd Dibbiny's avatar
      IB/mlx5: Enable ECN capable bits for UD RoCE v2 QPs · ea8af0d2
      Majd Dibbiny authored
      When working with RC QPs, the FW sets the ECN capable bits for all
      the RoCE v2 packets. On the other hand, for UD QPs, the driver needs
      to set the the ECN capable bits in the Address Handler since the HW
      generates each packet according to the Address Handler and not
      the QP context.
      
      If ECN is not enabled in NIC or switch, these bits are ignored.
      
      Fixes: 2811ba51 ("IB/mlx5: Add RoCE fields to Address Vector")
      Reviewed-by: default avatarMark Bloch <markb@mellanox.com>
      Signed-off-by: default avatarMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      ea8af0d2
    • Matan Barak's avatar
      IB/uverbs: UAPI pointers should use __aligned_u64 type · be23fb9a
      Matan Barak authored
      The ioctl() UAPIs are meant to be used by both user-space
      and kernel ioctl() handlers.
      
      Mostly, these UAPI structs tend to consist of simple types, but
      sometimes user-space pointers may be passed between user-space and
      kernel. We would like to avoid dereferencing a user-space pointer in
      the kernel, thus - we always define RDMA_UAPI_PTR as a __aligned_u64
      type.
      
      Fixes: 1f7ff9d5 ('IB/uverbs: Move to new headers and make naming consistent')
      Signed-off-by: default avatarMatan Barak <matanb@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      be23fb9a
    • Jason Gunthorpe's avatar
      Merge branch '32compat' · 819b6028
      Jason Gunthorpe authored
      The design of the uAPI had intended all structs to share the same layout on 32
      and 64 bit compiles. Unfortunately over the years some errors have crept in.
      
      This series fixes all the incompatabilities. It goes along with a userspace
      rdma-core series that causes the providers to use these structs directly and
      then does various self-checks on the command formation.
      
      Those checks were combined with output from pahole on 32 and 64 bit compiles
      to confirm that the structure layouts are the same.
      
      This series does not make implicit padding explicit, as long as the implicit
      padding is the same on 32 and 64 bit compiles.
      
      Finally, the issue is put to rest by using __aligned_u64 in the uapi headers,
      if new code copies that type, and is checked in userspace, it is unlikely we
      will see problems in future.
      
      There are two patches that break the ABI for a 32 bit kernel, one for rxe and
      one for mlx4. Both patches have notes, but the overall feeling from Doug and I
      is that providing compat is just too difficult and not necessary since there
      is no real user of a 32 bit userspace and 32 bit kernel for various good
      reasons.
      
      The 32 bit userspace / 64 bit kernel case however does seem to have some real
      users and does need to work as designed.
      
      * 32compat:
        RDMA: Change all uapi headers to use __aligned_u64 instead of __u64
        RDMA/rxe: Fix uABI structure layouts for 32/64 compat
        RDMA/mlx4: Fix uABI structure layouts for 32/64 compat
        RDMA/qedr: Fix uABI structure layouts for 32/64 compat
        RDMA/ucma: Fix uABI structure layouts for 32/64 compat
        RDMA: Remove minor pahole differences between 32/64
      819b6028
    • Jason Gunthorpe's avatar
      RDMA: Change all uapi headers to use __aligned_u64 instead of __u64 · 26b99066
      Jason Gunthorpe authored
      The new auditing standard for the subsystem will be to only use
      __aligned_64 in uapi headers to try and prevent 32/64 compat bugs
      from existing in the future.
      
      Changing all existing usage will help ensure new developers copy the
      right idea.
      
      The before/after of this patch was tested using pahole on 32 and 64
      bit compiles to confirm it has no change in the structure layout, so
      this patch is a NOP.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      26b99066
    • Jason Gunthorpe's avatar
      RDMA/rxe: Fix uABI structure layouts for 32/64 compat · f2e9bfac
      Jason Gunthorpe authored
      With 32 bit compilation several of the fields become misaligned here.
      Fixing this is an ABI break for 32 bit rxe and it is in well used
      portions of the rxe ABI.
      
      To handle this we bump the ABI version, as expected. However the user
      space driver doesn't handle it properly today, so all existing user
      space continues to work.
      
      Updated userspace will start to require the necessary kernel version.
      
      We don't expect there to be any 32 bit users of rxe. Most likely cases,
      such as ARM 32 already generally don't work because rxe does not handle
      the CPU cache properly on its shared with userspace pages.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      f2e9bfac
    • Jason Gunthorpe's avatar
      RDMA/mlx4: Fix uABI structure layouts for 32/64 compat · 366380a0
      Jason Gunthorpe authored
      rss_caps in struct mlx4_uverbs_ex_query_device_resp is misaligned on
      32 bit compared to 64 bit, add explicit padding.
      
      The rss caps were introduced recently and are very rarely used in user
      space, mainly for DPDK.
      
      We don't expect there to be a real 32 bit user, so this change is done
      without compat considerations.
      
      Fixes: 09d208b2 ("IB/mlx4: Add report for RSS capabilities by vendor channel")
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      366380a0
    • Jason Gunthorpe's avatar
      RDMA/qedr: Fix uABI structure layouts for 32/64 compat · 71e80a47
      Jason Gunthorpe authored
      struct qedr_alloc_ucontext_resp is a different length in 32 and 64
      bit compiles due to implicit compiler padding.
      
      The structs alloc_pd_uresp, create_cq_uresp and create_qp_uresp are
      not padded by the compiler, but in user space the compiler pads them
      due to the way the core and driver structs are concatenated. Make
      this padding explicit and consistent for future sanity.
      
      The kernel driver can already handle the user buffer being smaller
      than required and copies correctly, so no compat or ABI break happens
      from introducing the explicit padding.
      Acked-by: default avatarMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      71e80a47
    • Jason Gunthorpe's avatar
      RDMA/ucma: Fix uABI structure layouts for 32/64 compat · 611cb92b
      Jason Gunthorpe authored
      The rdma_ucm_event_resp is a different length on 32 and 64 bit compiles.
      
      The kernel requires it to be the expected length or longer so 32 bit
      builds running on a 64 bit kernel will not work.
      
      Retain full compat by having all kernels accept a struct with or without
      the trailing reserved field.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      611cb92b
    • Jason Gunthorpe's avatar
      RDMA: Remove minor pahole differences between 32/64 · 38b48808
      Jason Gunthorpe authored
      To help automatic detection we want pahole to report the same struct
      layouts for 32 and 64 bit compiles. These cases are all implicit
      padding added at the end of embedded structs as part of a union.
      
      The added reserved fields have no impact on the ABI.
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      38b48808
  2. 23 Mar, 2018 3 commits
  3. 22 Mar, 2018 4 commits
  4. 21 Mar, 2018 1 commit
  5. 19 Mar, 2018 17 commits
  6. 16 Mar, 2018 1 commit
    • Leon Romanovsky's avatar
      RDMA/restrack: Don't rely on uninitialized variable in restrack_add flow · 7d9a935e
      Leon Romanovsky authored
      The restrack code relies on the fact that object structures are zeroed at
      the allocation stage, the mlx4 CQ wasn't allocated with kzalloc and it
      caused to the following crash.
      
      [  137.392209] general protection fault: 0000 [#1] SMP KASAN PTI
      [  137.392972] CPU: 0 PID: 622 Comm: ibv_rc_pingpong Tainted: G        W        4.16.0-rc1-00099-g00313983 #11
      [  137.395079] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-2.fc27 04/01/2014
      [  137.396866] RIP: 0010:rdma_restrack_del+0xc8/0xf0
      [  137.397762] RSP: 0018:ffff8801b54e7968 EFLAGS: 00010206
      [  137.399008] RAX: 0000000000000000 RBX: ffff8801d8bcbae8 RCX: ffffffffb82314df
      [  137.400055] RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: 70696b533d454741
      [  137.401103] RBP: ffff8801d90c07a0 R08: ffff8801d8bcbb00 R09: 0000000000000000
      [  137.402470] R10: 0000000000000001 R11: ffffed0036a9cf52 R12: ffff8801d90c0ad0
      [  137.403318] R13: ffff8801d853fb20 R14: ffff8801d8bcbb28 R15: 0000000000000014
      [  137.404736] FS:  00007fb415d43740(0000) GS:ffff8801e5c00000(0000) knlGS:0000000000000000
      [  137.406074] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  137.407101] CR2: 00007fb41557df20 CR3: 00000001b580c001 CR4: 00000000003606b0
      [  137.408308] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [  137.409352] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      [  137.410385] Call Trace:
      [  137.411058]  ib_destroy_cq+0x23/0x60
      [  137.411460]  uverbs_free_cq+0x37/0xa0
      [  137.412040]  remove_commit_idr_uobject+0x38/0xf0
      [  137.413042]  _rdma_remove_commit_uobject+0x5c/0x160
      [  137.413782]  ? lookup_get_idr_uobject+0x39/0x50
      [  137.414737]  rdma_remove_commit_uobject+0x3b/0x70
      [  137.415742]  ib_uverbs_destroy_cq+0x114/0x1d0
      [  137.416260]  ? ib_uverbs_req_notify_cq+0x160/0x160
      [  137.417073]  ? kernel_text_address+0x5c/0x90
      [  137.417805]  ? __kernel_text_address+0xe/0x30
      [  137.418766]  ? unwind_get_return_address+0x2f/0x50
      [  137.419558]  ib_uverbs_write+0x453/0x6a0
      [  137.420220]  ? show_ibdev+0x90/0x90
      [  137.420653]  ? __kasan_slab_free+0x136/0x180
      [  137.421155]  ? kmem_cache_free+0x78/0x1e0
      [  137.422192]  ? remove_vma+0x83/0x90
      [  137.422614]  ? do_munmap+0x447/0x6c0
      [  137.423045]  ? vm_munmap+0xb0/0x100
      [  137.423481]  ? SyS_munmap+0x1d/0x30
      [  137.424120]  ? do_syscall_64+0xeb/0x250
      [  137.424984]  ? entry_SYSCALL_64_after_hwframe+0x21/0x86
      [  137.425611]  ? lru_add_drain_all+0x270/0x270
      [  137.426116]  ? lru_add_drain_cpu+0xa3/0x170
      [  137.426616]  ? lru_add_drain+0x11/0x20
      [  137.427058]  ? free_pages_and_swap_cache+0xa6/0x120
      [  137.427672]  ? tlb_flush_mmu_free+0x78/0x90
      [  137.428168]  ? arch_tlb_finish_mmu+0x6d/0xb0
      [  137.428680]  __vfs_write+0xc4/0x350
      [  137.430917]  ? kernel_read+0xa0/0xa0
      [  137.432758]  ? remove_vma+0x90/0x90
      [  137.434781]  ? __kasan_slab_free+0x14b/0x180
      [  137.437486]  ? remove_vma+0x83/0x90
      [  137.439836]  ? kmem_cache_free+0x78/0x1e0
      [  137.442195]  ? percpu_counter_add_batch+0x1d/0x90
      [  137.444389]  vfs_write+0xf7/0x280
      [  137.446030]  SyS_write+0xa1/0x120
      [  137.447867]  ? SyS_read+0x120/0x120
      [  137.449670]  ? mm_fault_error+0x180/0x180
      [  137.451539]  ? _cond_resched+0x16/0x50
      [  137.453697]  ? SyS_read+0x120/0x120
      [  137.455883]  do_syscall_64+0xeb/0x250
      [  137.457686]  entry_SYSCALL_64_after_hwframe+0x21/0x86
      [  137.459595] RIP: 0033:0x7fb415637b94
      [  137.461315] RSP: 002b:00007ffdebea7d88 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      [  137.463879] RAX: ffffffffffffffda RBX: 00005565022d1bd0 RCX: 00007fb415637b94
      [  137.466519] RDX: 0000000000000018 RSI: 00007ffdebea7da0 RDI: 0000000000000003
      [  137.469543] RBP: 00007ffdebea7d98 R08: 0000000000000000 R09: 00005565022d40c0
      [  137.472479] R10: 00000000000009cf R11: 0000000000000246 R12: 00005565022d2520
      [  137.475125] R13: 00000000000003e8 R14: 0000000000000000 R15: 00007ffdebea7fd0
      [  137.477760] Code: f7 e8 dd 0d 0b ff 48 c7 43 40 00 00 00 00 48 89 df e8 0d 0b 0b ff 48 8d 7b 28 c6 03 00 e8 41 0d 0b ff 48 8b 7b 28 48 85 ff 74 06 <f0> ff 4f 48 74 10 5b 48 89 ef 5d 41 5c 41 5d 41 5e e9 32 b0 ee
      [  137.483375] RIP: rdma_restrack_del+0xc8/0xf0 RSP: ffff8801b54e7968
      [  137.486436] ---[ end trace 81835a1ea6722eed ]---
      [  137.488566] Kernel panic - not syncing: Fatal exception
      [  137.491162] Kernel Offset: 0x36000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
      
      Fixes: 00313983 ("RDMA/nldev: provide detailed CM_ID information")
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarJason Gunthorpe <jgg@mellanox.com>
      7d9a935e
  7. 15 Mar, 2018 5 commits