1. 28 3月, 2018 12 次提交
    • P
      IB/cm: Block processing alternate path handling RoCE Rx cm messages · 97c45c2c
      Parav Pandit 提交于
      Due to below reasons, it is better to not support alternate path receive
      messages for RoCE in near term.
      
      1. Alternate path for RoCE is not supported at rdmacm layer.
      2. It is not supported in uverbs/core layer for RoCE.
      3. Alternate path for IPv6 for link local address cannot resolve route
      determinstically without a valid incoming interface id whose usecase
      make sense only with dual port mode.
      4. init_av_from_path while processing LAP messages for IB and RoCE can
      lead to adding duplicate entry of AV into the port list, leads to list
      corruption.
      5. rdma-core userspace a well known userspace implementation has removed
      support of libucm which use ucm.ko module, which is the only module that
      can trigger alternate path related messages.
      6. ucm kernel module is requested to be removed from the IB core in
      patch [1].
      
      [1] https://patchwork.kernel.org/patch/10268503/Signed-off-by: NParav Pandit <parav@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      97c45c2c
    • M
      IB/core: Protect against concurrent access to hardware stats · e945130b
      Mark Bloch 提交于
      Currently access to hardware stats buffer isn't protected, this can
      result in multiple writes and reads at the same time to the same
      memory location. This can lead to providing an incorrect value to
      the user. Add a mutex to protect against it.
      
      Fixes: b40f4757 ("IB/core: Make device counter infrastructure dynamic")
      Signed-off-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      e945130b
    • M
      IB/mlx5: Respect new UMR capabilities · c8d75a98
      Majd Dibbiny 提交于
      In some firmware configuration, UMR usage from Virtual Functions is restricted.
      This information is published to the driver using new capability bits.
      
      Avoid using UMRs in these cases and use the Firmware slow-path flow to create
      mkeys and populate them with Virtual to Physical address translation.
      
      Older drivers that do not have this patch, will end up using memory keys that
      aren't populated with Virtual to Physical address translation that is done
      part of the UMR work.
      Reviewed-by: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Tested-by: NLaurence Oberman <loberman@redhat.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      c8d75a98
    • M
      IB/mlx5: Enable ECN capable bits for UD RoCE v2 QPs · ea8af0d2
      Majd Dibbiny 提交于
      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: NMark Bloch <markb@mellanox.com>
      Signed-off-by: NMajd Dibbiny <majd@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      ea8af0d2
    • M
      IB/uverbs: UAPI pointers should use __aligned_u64 type · be23fb9a
      Matan Barak 提交于
      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: NMatan Barak <matanb@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      be23fb9a
    • J
      Merge branch '32compat' · 819b6028
      Jason Gunthorpe 提交于
      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
    • J
      RDMA: Change all uapi headers to use __aligned_u64 instead of __u64 · 26b99066
      Jason Gunthorpe 提交于
      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: NJason Gunthorpe <jgg@mellanox.com>
      26b99066
    • J
      RDMA/rxe: Fix uABI structure layouts for 32/64 compat · f2e9bfac
      Jason Gunthorpe 提交于
      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: NJason Gunthorpe <jgg@mellanox.com>
      f2e9bfac
    • J
      RDMA/mlx4: Fix uABI structure layouts for 32/64 compat · 366380a0
      Jason Gunthorpe 提交于
      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: NJason Gunthorpe <jgg@mellanox.com>
      366380a0
    • J
      RDMA/qedr: Fix uABI structure layouts for 32/64 compat · 71e80a47
      Jason Gunthorpe 提交于
      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: NMichal Kalderon <michal.kalderon@cavium.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      71e80a47
    • J
      RDMA/ucma: Fix uABI structure layouts for 32/64 compat · 611cb92b
      Jason Gunthorpe 提交于
      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: NJason Gunthorpe <jgg@mellanox.com>
      611cb92b
    • J
      RDMA: Remove minor pahole differences between 32/64 · 38b48808
      Jason Gunthorpe 提交于
      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: NJason Gunthorpe <jgg@mellanox.com>
      38b48808
  2. 24 3月, 2018 3 次提交
  3. 23 3月, 2018 4 次提交
  4. 22 3月, 2018 1 次提交
  5. 20 3月, 2018 17 次提交
  6. 17 3月, 2018 1 次提交
    • L
      RDMA/restrack: Don't rely on uninitialized variable in restrack_add flow · 7d9a935e
      Leon Romanovsky 提交于
      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: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      7d9a935e
  7. 16 3月, 2018 2 次提交