linux-stable.git/drivers/infiniband, branch v4.4.4

IB/cma: Fix RDMA port validation for iWarp

2016-03-03T23:07:32+00:00

commit 649367735ee5dedb128d9fac0b86ba7e0fe7ae3b upstream.

cma_validate_port wrongly assumed that Ethernet devices are RoCE
devices and thus their ndev should be matched in the GID table.
This broke the iWarp support. Fixing that matching the ndev only if
we work on a RoCE port.

Cc:  # 4.4.x-
Fixes: abae1b71dd37 ('IB/cma: cma_validate_port should verify the port
		     and netdevice')
Reported-by: Hariprasad Shenai 
Tested-by: Hariprasad Shenai 
Signed-off-by: Matan Barak 
Reviewed-by: Steve Wise 
Signed-off-by: Doug Ledford 
Signed-off-by: Steve Wise 
Signed-off-by: Greg Kroah-Hartman

IB/mlx5: Expose correct maximum number of CQE capacity

2016-03-03T23:07:25+00:00

commit 9f17768611ebf81dfac69948dd12622b6f2e45fc upstream.

Maximum number of EQE capacity per CQ was mistakenly exposed
as CQE. Fix that.

Fixes: 938fe83c8dcb ("net/mlx5_core: New device capabilities handling")
Signed-off-by: Leon Romanovsky 
Reviewed-by: Sagi Grimberg 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/qib: Support creating qps with GFP_NOIO flag

2016-03-03T23:07:25+00:00

commit fbbeb8632bf0b46ab44cfcedc4654cd7831b7161 upstream.

The current code is problematic when the QP creation and ipoib is used to
support NFS and NFS desires to do IO for paging purposes. In that case, the
GFP_KERNEL allocation in qib_qp.c causes a deadlock in tight memory
situations.

This fix adds support to create queue pair with GFP_NOIO flag for connected
mode only to cleanly fail the create queue pair in those situations.

Reviewed-by: Mike Marciniszyn 
Signed-off-by: Vinit Agnihotri 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

IB/qib: fix mcast detach when qp not attached

2016-03-03T23:07:25+00:00

commit 09dc9cd6528f5b52bcbd3292a6312e762c85260f upstream.

The code produces the following trace:

[1750924.419007] general protection fault: 0000 [#3] SMP
[1750924.420364] Modules linked in: nfnetlink autofs4 rpcsec_gss_krb5 nfsv4
dcdbas rfcomm bnep bluetooth nfsd auth_rpcgss nfs_acl dm_multipath nfs lockd
scsi_dh sunrpc fscache radeon ttm drm_kms_helper drm serio_raw parport_pc
ppdev i2c_algo_bit lpc_ich ipmi_si ib_mthca ib_qib dca lp parport ib_ipoib
mac_hid ib_cm i3000_edac ib_sa ib_uverbs edac_core ib_umad ib_mad ib_core
ib_addr tg3 ptp dm_mirror dm_region_hash dm_log psmouse pps_core
[1750924.420364] CPU: 1 PID: 8401 Comm: python Tainted: G D
3.13.0-39-generic #66-Ubuntu
[1750924.420364] Hardware name: Dell Computer Corporation PowerEdge
860/0XM089, BIOS A04 07/24/2007
[1750924.420364] task: ffff8800366a9800 ti: ffff88007af1c000 task.ti:
ffff88007af1c000
[1750924.420364] RIP: 0010:[] []
qib_mcast_qp_free+0x11/0x50 [ib_qib]
[1750924.420364] RSP: 0018:ffff88007af1dd70  EFLAGS: 00010246
[1750924.420364] RAX: 0000000000000001 RBX: ffff88007b822688 RCX:
000000000000000f
[1750924.420364] RDX: ffff88007b822688 RSI: ffff8800366c15a0 RDI:
6764697200000000
[1750924.420364] RBP: ffff88007af1dd78 R08: 0000000000000001 R09:
0000000000000000
[1750924.420364] R10: 0000000000000011 R11: 0000000000000246 R12:
ffff88007baa1d98
[1750924.420364] R13: ffff88003ecab000 R14: ffff88007b822660 R15:
0000000000000000
[1750924.420364] FS:  00007ffff7fd8740(0000) GS:ffff88007fc80000(0000)
knlGS:0000000000000000
[1750924.420364] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1750924.420364] CR2: 00007ffff597c750 CR3: 000000006860b000 CR4:
00000000000007e0
[1750924.420364] Stack:
[1750924.420364]  ffff88007b822688 ffff88007af1ddf0 ffffffffa0132429
000000007af1de20
[1750924.420364]  ffff88007baa1dc8 ffff88007baa0000 ffff88007af1de70
ffffffffa00cb313
[1750924.420364]  00007fffffffde88 0000000000000000 0000000000000008
ffff88003ecab000
[1750924.420364] Call Trace:
[1750924.420364]  [] qib_multicast_detach+0x1e9/0x350
[ib_qib]
[1750924.568035]  [] ? ib_uverbs_modify_qp+0x323/0x3d0
[ib_uverbs]
[1750924.568035]  [] ib_detach_mcast+0x31/0x50 [ib_core]
[1750924.568035]  [] ib_uverbs_detach_mcast+0x93/0x170
[ib_uverbs]
[1750924.568035]  [] ib_uverbs_write+0xc6/0x2c0 [ib_uverbs]
[1750924.568035]  [] ? apparmor_file_permission+0x18/0x20
[1750924.568035]  [] ? security_file_permission+0x23/0xa0
[1750924.568035]  [] vfs_write+0xb4/0x1f0
[1750924.568035]  [] SyS_write+0x49/0xa0
[1750924.568035]  [] system_call_fastpath+0x1a/0x1f
[1750924.568035] Code: 66 2e 0f 1f 84 00 00 00 00 00 31 c0 5d c3 66 2e 0f 1f
84 00 00 00 00 00 66 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb 48 8b 7f 10
 ff 8f 40 01 00 00 74 0e 48 89 df e8 8e f8 06 e1 5b 5d c3 0f
[1750924.568035] RIP  [] qib_mcast_qp_free+0x11/0x50
[ib_qib]
[1750924.568035]  RSP 
[1750924.650439] ---[ end trace 73d5d4b3f8ad4851 ]

The fix is to note the qib_mcast_qp that was found.   If none is found, then
return EINVAL indicating the error.

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

IB/cm: Fix a recently introduced deadlock

2016-03-03T23:07:25+00:00

commit 4bfdf635c668869c69fd18ece37ec66fb6f38fcf upstream.

ib_send_cm_drep() calls cm_enter_timewait() while holding a spinlock
that can be locked from inside an interrupt handler. Hence do not
enable interrupts inside cm_enter_timewait() if called with interrupts
disabled.

This patch fixes e.g. the following deadlock:
Acked-by: Erez Shitrit 

=================================
[ INFO: inconsistent lock state ]
4.4.0-rc7+ #1 Tainted: G            E
---------------------------------
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/8/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&cm_id_priv->lock)->rlock){?.+...}, at: [] cm_establish+0x
74/0x1b0 [ib_cm]
{HARDIRQ-ON-W} state was registered at:
  [] mark_held_locks+0x71/0x90
  [] trace_hardirqs_on_caller+0xa7/0x1c0
  [] trace_hardirqs_on+0xd/0x10
  [] _raw_spin_unlock_irq+0x2b/0x40
  [] cm_enter_timewait+0xae/0x100 [ib_cm]
  [] ib_send_cm_drep+0xb6/0x190 [ib_cm]
  [] srp_cm_handler+0x128/0x1a0 [ib_srp]
  [] cm_process_work+0x20/0xf0 [ib_cm]
  [] cm_dreq_handler+0x135/0x2c0 [ib_cm]
  [] cm_work_handler+0x75/0xd0 [ib_cm]
  [] process_one_work+0x1bd/0x460
  [] worker_thread+0x118/0x420
  [] kthread+0xe4/0x100
  [] ret_from_fork+0x3f/0x70
irq event stamp: 1672286
hardirqs last  enabled at (1672283): [] poll_idle+0x10/0x80
hardirqs last disabled at (1672284): [] common_interrupt+0x84/0x89
softirqs last  enabled at (1672286): [] _local_bh_enable+0x1c/0x50
softirqs last disabled at (1672285): [] irq_enter+0x47/0x70

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&cm_id_priv->lock)->rlock);
  
    lock(&(&cm_id_priv->lock)->rlock);

 *** DEADLOCK ***

no locks held by swapper/8/0.

stack backtrace:
CPU: 8 PID: 0 Comm: swapper/8 Tainted: G            E   4.4.0-rc7+ #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 1.0.2 11/17/2014
 ffff88045af5e950 ffff88046e503a88 ffffffff81251c1b 0000000000000007
 0000000000000006 0000000000000003 ffff88045af5ddc0 ffff88046e503ad8
 ffffffff810a32f4 0000000000000000 0000000000000000 0000000000000001
Call Trace:
   [] dump_stack+0x4f/0x74
 [] print_usage_bug+0x184/0x190
 [] mark_lock_irq+0xf2/0x290
 [] mark_lock+0x115/0x1b0
 [] mark_irqflags+0x15c/0x170
 [] __lock_acquire+0x1ef/0x560
 [] lock_acquire+0x62/0x80
 [] _raw_spin_lock_irqsave+0x43/0x60
 [] cm_establish+0x74/0x1b0 [ib_cm]
 [] ib_cm_notify+0x31/0x100 [ib_cm]
 [] srpt_qp_event+0x54/0xd0 [ib_srpt]
 [] mlx4_ib_qp_event+0x72/0xc0 [mlx4_ib]
 [] mlx4_qp_event+0x69/0xd0 [mlx4_core]
 [] mlx4_eq_int+0x51e/0xd50 [mlx4_core]
 [] mlx4_msi_x_interrupt+0xf/0x20 [mlx4_core]
 [] handle_irq_event_percpu+0x40/0x110
 [] handle_irq_event+0x3f/0x70
 [] handle_edge_irq+0x79/0x120
 [] handle_irq+0x5d/0x130
 [] do_IRQ+0x6d/0x130
 [] common_interrupt+0x89/0x89
   [] cpuidle_enter_state+0xcf/0x200
 [] cpuidle_enter+0x12/0x20
 [] call_cpuidle+0x36/0x60
 [] cpuidle_idle_call+0x63/0x110
 [] cpu_idle_loop+0xfa/0x130
 [] cpu_startup_entry+0xe/0x10
 [] start_secondary+0x83/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 
Signed-off-by: Doug Ledford 
Signed-off-by: Greg Kroah-Hartman

iw_cxgb3: Fix incorrectly returning error on success

2016-03-03T23:07:10+00:00

commit 67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 upstream.

The cxgb3_*_send() functions return NET_XMIT_ values, which are
positive integers values. So don't treat positive return values
as an error.

Signed-off-by: Steve Wise 
Signed-off-by: Hariprasad Shenai 
Signed-off-by: Doug Ledford 
[a pox on developers and maintainers who do not cc: stable for bug fixes like this - gregkh]
Signed-off-by: Greg Kroah-Hartman

net/mlx5_core: Fix trimming down IRQ number

2016-01-31T19:29:01+00:00

[ Upstream commit 0b6e26ce89391327d955a756a7823272238eb867 ]

With several ConnectX-4 cards installed on a server, one may receive
irqn > 255 from the kernel API, which we mistakenly trim to 8bit.

This causes EQ creation failure with the following stack trace:
[] dump_stack+0x48/0x64
[] __setup_irq+0x3a1/0x4f0
[] request_threaded_irq+0x120/0x180
[] ? mlx5_eq_int+0x450/0x450 [mlx5_core]
[] mlx5_create_map_eq+0x1e4/0x2b0 [mlx5_core]
[] alloc_comp_eqs+0xb1/0x180 [mlx5_core]
[] mlx5_dev_init+0x5e9/0x6e0 [mlx5_core]
[] init_one+0x99/0x1c0 [mlx5_core]
[] local_pci_probe+0x4c/0xa0

Fixing it by changing of the irqn type from u8 to unsigned int to
support values > 255

Fixes: 61d0e73e0a5a ('net/mlx5_core: Use the the real irqn in eq->irqn')
Reported-by: Jiri Pirko 
Signed-off-by: Doron Tsur 
Signed-off-by: Matan Barak 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

RDMA/ocrdma: Depend on async link events from CNA

2015-12-28T16:45:54+00:00

Recently Dough Ledford reported a deadlock happening
between ocrdma-load sequence and NetworkManager service
issuing "open" on be2net interface.

The deadlock happens when any be2net hook (e.g. open/close) is called
in parallel to insmod ocrdma.ko.

A. be2net is sending administrative open/close event to ocrdma holding
   device_list_mutex. It does this from ndo_open/ndo_stop hooks of be2net.
   So sequence of locks is rtnl_lock---> device_list lock

B.  When new ocrdma roce device gets registered, infiniband stack now
    takes rtnl_lock in ib_register_device() in GID initialization routines.
    So sequence of locks in this path is device_list lock ---> rtnl_lock.

This improper locking sequence causes deadlock.

With this patch we stop using administrative open and close events
injected by be2net driver. These events were used to dispatch PORT_ACTIVE
and PORT_ERROR events to the IB-stack. This patch implements a logic
to receive async-link-events generated from CNA whenever link-state-change
is detected. Now on, these async-events will be used to dispatch
PORT_ACTIVE and PORT_ERROR events to IB-stack.

Depending on async-events from CNA removes the need to hold device-list-mutex
and thus breaks the busy-wait scenario.

Reported-by: Doug Ledford 
CC: Sathya Perla 
Signed-off-by: Padmanabh Ratnakar 
Signed-off-by: Selvin Xavier 
Signed-off-by: Devesh Sharma 
Signed-off-by: Doug Ledford

RDMA/ocrdma: Dispatch only port event when port state changes

2015-12-28T16:45:54+00:00

Dispatch only port event to IB stack when port state changes.
Don't explicitly modify qps to error. Let application listen to
port events on async event queue or let QP fail with retry-exceeded
completion error.

Signed-off-by: Padmanabh Ratnakar 
Signed-off-by: Devesh Sharma 
Signed-off-by: Doug Ledford

RDMA/ocrdma: Fix vlan-id assignment in qp parameters

2015-12-28T16:45:54+00:00

vlan-id is wrongly getting as 0 when PFC is enabled.
Set vlan-id configured by user in QP parameters.
In case vlan interface is not used, flash a warning to
user to configure vlan and assign vlan-id as 0 in qp params.

Fixes: dbf727de7440 ('IB/core: Use GID table in AH creation and dmac resolution')
Cc: Matan Barak 
Signed-off-by: Devesh Sharma 
Signed-off-by: Doug Ledford