1. 09 Mar, 2018 8 commits
    • Leon Romanovsky's avatar
      RDMA/mlx5: Fix integer overflow while resizing CQ · 28e9091e
      Leon Romanovsky authored
      The user can provide very large cqe_size which will cause to integer
      overflow as it can be seen in the following UBSAN warning:
      
      =======================================================================
      UBSAN: Undefined behaviour in drivers/infiniband/hw/mlx5/cq.c:1192:53
      signed integer overflow:
      64870 * 65536 cannot be represented in type 'int'
      CPU: 0 PID: 267 Comm: syzkaller605279 Not tainted 4.15.0+ #90 Hardware
      name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
      rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
      Call Trace:
       dump_stack+0xde/0x164
       ? dma_virt_map_sg+0x22c/0x22c
       ubsan_epilogue+0xe/0x81
       handle_overflow+0x1f3/0x251
       ? __ubsan_handle_negate_overflow+0x19b/0x19b
       ? lock_acquire+0x440/0x440
       mlx5_ib_resize_cq+0x17e7/0x1e40
       ? cyc2ns_read_end+0x10/0x10
       ? native_read_msr_safe+0x6c/0x9b
       ? cyc2ns_read_end+0x10/0x10
       ? mlx5_ib_modify_cq+0x220/0x220
       ? sched_clock_cpu+0x18/0x200
       ? lookup_get_idr_uobject+0x200/0x200
       ? rdma_lookup_get_uobject+0x145/0x2f0
       ib_uverbs_resize_cq+0x207/0x3e0
       ? ib_uverbs_ex_create_cq+0x250/0x250
       ib_uverbs_write+0x7f9/0xef0
       ? cyc2ns_read_end+0x10/0x10
       ? print_irqtrace_events+0x280/0x280
       ? ib_uverbs_ex_create_cq+0x250/0x250
       ? uverbs_devnode+0x110/0x110
       ? sched_clock_cpu+0x18/0x200
       ? do_raw_spin_trylock+0x100/0x100
       ? __lru_cache_add+0x16e/0x290
       __vfs_write+0x10d/0x700
       ? uverbs_devnode+0x110/0x110
       ? kernel_read+0x170/0x170
       ? sched_clock_cpu+0x18/0x200
       ? security_file_permission+0x93/0x260
       vfs_write+0x1b0/0x550
       SyS_write+0xc7/0x1a0
       ? SyS_read+0x1a0/0x1a0
       ? trace_hardirqs_on_thunk+0x1a/0x1c
       entry_SYSCALL_64_fastpath+0x1e/0x8b
      RIP: 0033:0x433549
      RSP: 002b:00007ffe63bd1ea8 EFLAGS: 00000217
      =======================================================================
      
      Cc: syzkaller <syzkaller@googlegroups.com>
      Cc: <stable@vger.kernel.org> # 3.13
      Fixes: bde51583 ("IB/mlx5: Add support for resize CQ")
      Reported-by: default avatarNoa Osherovich <noaos@mellanox.com>
      Reviewed-by: default avatarYishai Hadas <yishaih@mellanox.com>
      Signed-off-by: default avatarLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      28e9091e
    • Doug Ledford's avatar
      Revert "RDMA/mlx5: Fix integer overflow while resizing CQ" · 212a0cbc
      Doug Ledford authored
      The original commit of this patch has a munged log message that is
      missing several of the tags the original author intended to be on the
      patch.  This was due to patchworks misinterpreting a cut-n-paste
      separator line as an end of message line and munging the mbox that was
      used to import the patch:
      
      https://patchwork.kernel.org/patch/10264089/
      
      The original patch will be reapplied with a fixed commit message so the
      proper tags are applied.
      
      This reverts commit aa0de36a.
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      212a0cbc
    • Darren Hart (VMware)'s avatar
      platform/x86: dell-smbios: Resolve dependency error on DCDBAS · 32d7b19b
      Darren Hart (VMware) authored
      When the DELL_SMBIOS_SMM backend is enabled, the DELL_SMBIOS symbol
      depends on DELL_DCDBAS, and we must avoid the situation where
      DELL_SMBIOS=y and DCDBAS=m.
      
      Adding the conditional dependency to DELL_SMBIOS such as:
      
      depends !DELL_SMBIOS_SMM || (DCDBAS || DCDBAS=n)
      
      results in the Kconfig tooling complaining about a circular dependency,
      although it appears to work in practice.
      
      Avoid the errors by simplifying the dependency and forcing DELL_SMBIOS
      to be <= DCDBAS if DCDBAS is enabled (thanks to Greg KH for the
      suggestion).
      
      Cc: Mario.Limonciello@dell.com
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      32d7b19b
    • Darren Hart (VMware)'s avatar
      platform/x86: Allow for SMBIOS backend defaults · 329d58b8
      Darren Hart (VMware) authored
      Avoid accidental configurations by setting default y for DELL_SMBIOS
      backends. Avoid this impacting the default build size, by making them
      dependent on DELL_SMBIOS, so they only appear when DELL_SMBIOS is
      manually selected, or by DELL_LAPTOP or DELL_WMI.
      
      While DELL_SMBIOS does have a prompt, it does not have any dependencies.
      Keeping DELL_SMBIOS visible, despite being "select"ed by DELL_LAPTOP and
      DELL_WMI, is a deliberate choice to provide context for the WMI and SMM
      backends, which would otherwise appear to float without context within
      the menu.
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      329d58b8
    • Mario Limonciello's avatar
      platform/x86: dell-smbios: Link all dell-smbios-* modules together · 25d47027
      Mario Limonciello authored
      Some race conditions were raised due to dell-smbios and its backends
      not being ready by the time that a consumer would call one of the
      exported methods.
      
      To avoid this problem, guarantee that all initialization has been
      done by linking them all together and running init for them all.
      
      As part of this change the Kconfig needs to be adjusted so that
      CONFIG_DELL_SMBIOS_SMM and CONFIG_DELL_SMBIOS_WMI are boolean
      rather than modules.
      
      CONFIG_DELL_SMBIOS is a visually selectable option again and both
      CONFIG_DELL_SMBIOS_WMI and CONFIG_DELL_SMBIOS_SMM are optional.
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      [dvhart: Update prompt and help text for DELL_SMBIOS_* backends]
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      25d47027
    • Mario Limonciello's avatar
      platform/x86: dell-smbios: Rename dell-smbios source to dell-smbios-base · 94f77cb1
      Mario Limonciello authored
      This is being done to faciliate a later change to link all the dell-smbios
      drivers together.
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      94f77cb1
    • Mario Limonciello's avatar
      platform/x86: dell-smbios: Correct some style warnings · b5353962
      Mario Limonciello authored
      WARNING: function definition argument 'struct calling_interface_buffer *'
      should also have an identifier name
      +       int (*call_fn)(struct calling_interface_buffer *);
      
      WARNING: Block comments use * on subsequent lines
      +       /* 4 bytes of table header, plus 7 bytes of Dell header,
      	plus at least
      +          6 bytes of entry */
      
      WARNING: Block comments use a trailing */ on a separate line
      +          6 bytes of entry */
      Signed-off-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      Signed-off-by: default avatarDarren Hart (VMware) <dvhart@infradead.org>
      b5353962
    • Ross Zwisler's avatar
      loop: Fix lost writes caused by missing flag · 1d037577
      Ross Zwisler authored
      The following commit:
      
      commit aa4d8616 ("block: loop: switch to VFS ITER_BVEC")
      
      replaced __do_lo_send_write(), which used ITER_KVEC iterators, with
      lo_write_bvec() which uses ITER_BVEC iterators.  In this change, though,
      the WRITE flag was lost:
      
      -       iov_iter_kvec(&from, ITER_KVEC | WRITE, &kvec, 1, len);
      +       iov_iter_bvec(&i, ITER_BVEC, bvec, 1, bvec->bv_len);
      
      This flag is necessary for the DAX case because we make decisions based on
      whether or not the iterator is a READ or a WRITE in dax_iomap_actor() and
      in dax_iomap_rw().
      
      We end up going through this path in configurations where we combine a PMEM
      device with 4k sectors, a loopback device and DAX.  The consequence of this
      missed flag is that what we intend as a write actually turns into a read in
      the DAX code, so no data is ever written.
      
      The very simplest test case is to create a loopback device and try and
      write a small string to it, then hexdump a few bytes of the device to see
      if the write took.  Without this patch you read back all zeros, with this
      you read back the string you wrote.
      
      For XFS this causes us to fail or panic during the following xfstests:
      
      	xfs/074 xfs/078 xfs/216 xfs/217 xfs/250
      
      For ext4 we have a similar issue where writes never happen, but we don't
      currently have any xfstests that use loopback and show this issue.
      
      Fix this by restoring the WRITE flag argument to iov_iter_bvec().  This
      causes the xfstests to all pass.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: stable@vger.kernel.org
      Fixes: commit aa4d8616 ("block: loop: switch to VFS ITER_BVEC")
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Signed-off-by: default avatarRoss Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      1d037577
  2. 08 Mar, 2018 4 commits
  3. 07 Mar, 2018 28 commits