linux-stable.git/drivers/infiniband, branch linux-4.6.y

IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs

2016-07-27T15:42:08+00:00

commit 8c5122e45a10a9262f872b53f151a592e870f905 upstream.

When this code was reworked for IBoE support the order of assignments
for the sl_tclass_flowlabel got flipped around resulting in
TClass & FlowLabel being permanently set to 0 in the packet headers.

This breaks IB routers that rely on these headers, but only affects
kernel users - libmlx4 does this properly for user space.

Fixes: fa417f7b520e ("IB/mlx4: Add support for IBoE")
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/rdmavt: Correct qp_priv_alloc() return value test

2016-07-27T15:42:08+00:00

commit c755f4afa66ad3ed98870bd3254f37c47fb2c800 upstream.

The current drivers return errors from this calldown
wrapped in an ERR_PTR().

The rdmavt code incorrectly tests for NULL.

The code is fixed to use IS_ERR() and change ret according
to the driver return value.

Reviewed-by: Dennis Dalessandro 
Signed-off-by: Mike Marciniszyn 
Signed-off-by: Dennis Dalessandro 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/cm: Fix a recently introduced locking bug

2016-07-27T15:42:08+00:00

commit 943f44d94aa26bfdcaafc40d3701e24eeb58edce upstream.

ib_cm_notify() can be called from interrupt context. Hence do not
reenable interrupts unconditionally in cm_establish().

This patch avoids that lockdep reports the following warning:

WARNING: CPU: 0 PID: 23317 at kernel/locking/lockdep.c:2624 trace _hardirqs_on_caller+0x112/0x1b0
DEBUG_LOCKS_WARN_ON(current->hardirq_context)
Call Trace:
   [] dump_stack+0x67/0x92
 [] __warn+0xc1/0xe0
 [] warn_slowpath_fmt+0x4a/0x50
 [] trace_hardirqs_on_caller+0x112/0x1b0
 [] trace_hardirqs_on+0xd/0x10
 [] _raw_spin_unlock_irq+0x27/0x40
 [] ib_cm_notify+0x25c/0x290 [ib_cm]
 [] srpt_qp_event+0xa1/0xf0 [ib_srpt]
 [] mlx4_ib_qp_event+0x67/0xd0 [mlx4_ib]
 [] mlx4_qp_event+0x5a/0xc0 [mlx4_core]
 [] mlx4_eq_int+0x3d8/0xcf0 [mlx4_core]
 [] mlx4_msi_x_interrupt+0xc/0x20 [mlx4_core]
 [] handle_irq_event_percpu+0x64/0x100
 [] handle_irq_event+0x34/0x60
 [] handle_edge_irq+0x6a/0x150
 [] handle_irq+0x15/0x20
 [] do_IRQ+0x5c/0x110
 [] common_interrupt+0x89/0x89
 [] blk_run_queue_async+0x37/0x40
 [] rq_completed+0x43/0x70 [dm_mod]
 [] dm_softirq_done+0x176/0x280 [dm_mod]
 [] blk_done_softirq+0x52/0x90
 [] __do_softirq+0x10f/0x230
 [] irq_exit+0xa8/0xb0
 [] smp_trace_call_function_single_interrupt+0x2e/0x30
 [] smp_call_function_single_interrupt+0x9/0x10
 [] call_function_single_interrupt+0x89/0x90
 

Fixes: commit be4b499323bf (IB/cm: Do not queue work to a device that's going away)
Signed-off-by: Bart Van Assche 
Cc: Erez Shitrit 
Cc: Sean Hefty 
Cc: Nikolay Borisov 
Acked-by: Erez Shitrit 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/srp: Fix srp_create_target() error handling

2016-06-01T19:18:04+00:00

commit f83b2561a6d4ff12959660ad597580097b744941 upstream.

Avoid that the following kernel oops occurs if memory pool
allocation fails:

BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] ib_drain_rq+0x0/0x20 [ib_core]
Call Trace:
 [] srp_create_target+0xca6/0x13a9 [ib_srp]
 [] dev_attr_store+0x13/0x20
 [] sysfs_kf_write+0x40/0x50
 [] kernfs_fop_write+0x13c/0x180
 [] __vfs_write+0x23/0xf0
 [] vfs_write+0xa4/0x1a0
 [] SyS_write+0x44/0xa0
 [] entry_SYSCALL_64_fastpath+0x1c/0xac

Fixes: 1dc7b1f10dcb ("IB/srp: use the new CQ API")
Signed-off-by: Bart Van Assche 
Reviewed-by: Leon Romanovsky 
Tested-by: Laurence Oberman 
Cc: Christoph Hellwig 
Cc: Sagi Grimberg 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/srp: Fix a debug kernel crash

2016-06-01T19:18:04+00:00

commit 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream.

Avoid that the following BUG() is triggered against a debug
kernel:

kernel BUG at include/linux/scatterlist.h:92!
RIP: 0010:[]  [] srp_map_idb+0x199/0x1a0 [ib_srp]
Call Trace:
 [] srp_map_data+0x84a/0x890 [ib_srp]
 [] srp_queuecommand+0x1e4/0x610 [ib_srp]
 [] scsi_dispatch_cmd+0x9e/0x180
 [] scsi_request_fn+0x477/0x610
 [] __blk_run_queue+0x2e/0x40
 [] blk_delay_work+0x20/0x30
 [] process_one_work+0x197/0x480
 [] worker_thread+0x49/0x490
 [] kthread+0xea/0x100
 [] ret_from_fork+0x22/0x40

Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API")
Signed-off-by: Bart Van Assche 
Cc: Sagi Grimberg 
Cc: Christoph Hellwig 
Reviewed-by: Max Gurtovoy 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma

2016-05-07T15:10:08+00:00

Pull rdma fix from Doug Ledford:
 "Fix for max sector calculation in iSER"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  IB/iser: Fix max_sectors calculation

IB/iser: Fix max_sectors calculation

2016-05-05T16:41:24+00:00

iSER currently has a couple places that set max_sectors in either the host
template or SCSI host, and all of them get it wrong.

This patch instead uses a single assignment that (hopefully) gets it right:
the max_sectors value must be derived from the number of segments in the
FR or FMR structure, but actually be one lower than the page size multiplied
by the number of sectors, as it has to handle the case of non-aligned I/O.

Without this I get trivial to reproduce hangs when running xfstests
(on XFS) over iSER to Linux targets.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Max Gurtovoy 
Acked-by: Sagi Grimberg 
Signed-off-by: Doug Ledford

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma

2016-04-30T00:07:54+00:00

Pull rdma fixes from Doug Ledford:
 "Final set of -rc fixes for 4.6.

  I've collected up a number of patches that are all pretty small with
  the exception of only a couple.  The hfi1 driver has a number of
  important patches, and it is what really drives the line count of this
  pull request up.  These are all small and I've got this kernel built
  and running in the test lab (I have most of the hardware, I think nes
  is the only thing in this patch set that I can't say I've personally
  tested and have up and running).

  Summary:

   - A number of collected fixes for oopses, memory corruptions,
     deadlocks, etc.  All of these fixes are small (many only 5-10
     lines), obvious, and tested.

   - Fix for the security issue related to the use of write for
     bi-directional communications"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  RDMA/nes: don't leak skb if carrier down
  IB/security: Restrict use of the write() interface
  IB/hfi1: Use kernel default llseek for ui device
  IB/hfi1: Don't attempt to free resources if initialization failed
  IB/hfi1: Fix missing lock/unlock in verbs drain callback
  IB/rdmavt: Fix send scheduling
  IB/hfi1: Prevent unpinning of wrong pages
  IB/hfi1: Fix deadlock caused by locking with wrong scope
  IB/hfi1: Prevent NULL pointer deferences in caching code
  MAINTAINERS: Update iser/isert maintainer contact info
  IB/mlx5: Expose correct max_sge_rd limit
  RDMA/iw_cxgb4: Fix bar2 virt addr calculation for T4 chips
  iw_cxgb4: handle draining an idle qp
  iw_cxgb3: initialize ibdev.iwcm->ifname for port mapping
  iw_cxgb4: initialize ibdev.iwcm->ifname for port mapping
  IB/core: Don't drain non-existent rq queue-pair
  IB/core: Fix oops in ib_cache_gid_set_default_gid

RDMA/nes: don't leak skb if carrier down

2016-04-29T01:11:09+00:00

Alternatively one could free the skb, OTOH I don't think this test is
useful so just remove it.

Cc: 
Signed-off-by: Florian Westphal 
Signed-off-by: Doug Ledford

IB/security: Restrict use of the write() interface

2016-04-28T16:03:16+00:00

The drivers/infiniband stack uses write() as a replacement for
bi-directional ioctl().  This is not safe. There are ways to
trigger write calls that result in the return structure that
is normally written to user space being shunted off to user
specified kernel memory instead.

For the immediate repair, detect and deny suspicious accesses to
the write API.

For long term, update the user space libraries and the kernel API
to something that doesn't present the same security vulnerabilities
(likely a structured ioctl() interface).

The impacted uAPI interfaces are generally only available if
hardware from drivers/infiniband is installed in the system.

Reported-by: Jann Horn 
Signed-off-by: Linus Torvalds 
Signed-off-by: Jason Gunthorpe 
[ Expanded check to all known write() entry points ]
Cc: stable@vger.kernel.org
Signed-off-by: Doug Ledford