linux.git, branch v4.9.69

Linux 4.9.69

2017-12-14T08:28:24+00:00

afs: Connect up the CB.ProbeUuid

2017-12-14T08:28:24+00:00

[ Upstream commit f4b3526d83c40dd8bf5948b9d7a1b2c340f0dcc8 ]

The handler for the CB.ProbeUuid operation in the cache manager is
implemented, but isn't listed in the switch-statement of operation
selection, so won't be used.  Fix this by adding it.

Signed-off-by: David Howells 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/mlx5: Assign send CQ and recv CQ of UMR QP

2017-12-14T08:28:24+00:00

[ Upstream commit 31fde034a8bd964a5c7c1a5663fc87a913158db2 ]

The UMR's QP is created by calling mlx5_ib_create_qp directly, and
therefore the send CQ and the recv CQ on the ibqp weren't assigned.

Assign them right after calling the mlx5_ib_create_qp to assure
that any access to those pointers will work as expected and won't
crash the system as might happen as part of reset flow.

Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters")
Signed-off-by: Majd Dibbiny 
Reviewed-by: Yishai Hadas 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

IB/mlx4: Increase maximal message size under UD QP

2017-12-14T08:28:24+00:00

[ Upstream commit 5f22a1d87c5315a98981ecf93cd8de226cffe6ca ]

Maximal message should be used as a limit to the max message payload allowed,
without the headers. The ConnectX-3 check is done against this value includes
the headers. When the payload is 4K this will cause the NIC to drop packets.

Increase maximal message to 8K as workaround, this shouldn't change current
behaviour because we continue to set the MTU to 4k.

To reproduce;
set MTU to 4296 on the corresponding interface, for example:
ifconfig eth0 mtu 4296 (both server and client)

On server:
ib_send_bw -c UD -d mlx4_0 -s 4096 -n 1000000 -i1 -m 4096

On client:
ib_send_bw -d mlx4_0 -c UD  -s 4096 -n 1000000 -i 1 -m 4096

Fixes: 6e0d733d9215 ("IB/mlx4: Allow 4K messages for UD QPs")
Signed-off-by: Mark Bloch 
Reviewed-by: Majd Dibbiny 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Doug Ledford 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

xfrm: Copy policy family in clone_policy

2017-12-14T08:28:24+00:00

[ Upstream commit 0e74aa1d79a5bbc663e03a2804399cae418a0321 ]

The syzbot found an ancient bug in the IPsec code.  When we cloned
a socket policy (for example, for a child TCP socket derived from a
listening socket), we did not copy the family field.  This results
in a live policy with a zero family field.  This triggers a BUG_ON
check in the af_key code when the cloned policy is retrieved.

This patch fixes it by copying the family field over.

Reported-by: syzbot 
Signed-off-by: Herbert Xu 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

jump_label: Invoke jump_label_test() via early_initcall()

2017-12-14T08:28:24+00:00

[ Upstream commit 92ee46efeb505ead3ab06d3c5ce695637ed5f152 ]

Fengguang Wu reported that running the rcuperf test during boot can cause
the jump_label_test() to hit a WARN_ON(). The issue is that the core jump
label code relies on kernel_text_address() to detect when it can no longer
update branches that may be contained in __init sections. The
kernel_text_address() in turn assumes that if the system_state variable is
greter than or equal to SYSTEM_RUNNING then __init sections are no longer
valid (since the assumption is that they have been freed). However, when
rcuperf is setup to run in early boot it can call kernel_power_off() which
sets the system_state to SYSTEM_POWER_OFF.

Since rcuperf initialization is invoked via a module_init(), we can make
the dependency of jump_label_test() needing to complete before rcuperf
explicit by calling it via early_initcall().

Reported-by: Fengguang Wu 
Signed-off-by: Jason Baron 
Acked-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/1510609727-2238-1-git-send-email-jbaron@akamai.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

atm: horizon: Fix irq release error

2017-12-14T08:28:24+00:00

[ Upstream commit bde533f2ea607cbbbe76ef8738b36243939a7bc2 ]

atm_dev_register() can fail here and passed parameters to free irq
which is not initialised. Initialization of 'dev->irq' happened after
the 'goto out_free_irq'. So using 'irq' insted of 'dev->irq' in
free_irq().

Signed-off-by: Arvind Yadav 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

clk: uniphier: fix DAPLL2 clock rate of Pro5

2017-12-14T08:28:24+00:00

[ Upstream commit 67affb78a4e4feb837953e3434c8402a5c3b272f ]

The parent of DAPLL2 should be DAPLL1.  Fix the clock connection.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

bpf: fix lockdep splat

2017-12-14T08:28:23+00:00

[ Upstream commit 89ad2fa3f043a1e8daae193bcb5fe34d5f8caf28 ]

pcpu_freelist_pop() needs the same lockdep awareness than
pcpu_freelist_populate() to avoid a false positive.

 [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]

 switchto-defaul/12508 [HC0[0]:SC0[6]:HE0:SE0] is trying to acquire:
  (&htab->buckets[i].lock){......}, at: [] __htab_percpu_map_update_elem+0x1cb/0x300

 and this task is already holding:
  (dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...}, at: [] __dev_queue_xmit+0
x868/0x1240
 which would create a new lock dependency:
  (dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...} -> (&htab->buckets[i].lock){......}

 but this new dependency connects a SOFTIRQ-irq-safe lock:
  (dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...}
 ... which became SOFTIRQ-irq-safe at:
   [] __lock_acquire+0x42b/0x1f10
   [] lock_acquire+0xbc/0x1b0
   [] _raw_spin_lock+0x38/0x50
   [] __dev_queue_xmit+0x868/0x1240
   [] dev_queue_xmit+0x10/0x20
   [] ip_finish_output2+0x439/0x590
   [] ip_finish_output+0x150/0x2f0
   [] ip_output+0x7d/0x260
   [] ip_local_out+0x5e/0xe0
   [] ip_queue_xmit+0x205/0x620
   [] tcp_transmit_skb+0x5a8/0xcb0
   [] tcp_write_xmit+0x242/0x1070
   [] __tcp_push_pending_frames+0x3c/0xf0
   [] tcp_rcv_established+0x312/0x700
   [] tcp_v4_do_rcv+0x11c/0x200
   [] tcp_v4_rcv+0xaa2/0xc30
   [] ip_local_deliver_finish+0xa7/0x240
   [] ip_local_deliver+0x66/0x200
   [] ip_rcv_finish+0xdd/0x560
   [] ip_rcv+0x295/0x510
   [] __netif_receive_skb_core+0x988/0x1020
   [] __netif_receive_skb+0x21/0x70
   [] process_backlog+0x6f/0x230
   [] net_rx_action+0x229/0x420
   [] __do_softirq+0xd8/0x43d
   [] do_softirq_own_stack+0x1c/0x30
   [] do_softirq+0x55/0x60
   [] __local_bh_enable_ip+0xa8/0xb0
   [] cpu_startup_entry+0x1c7/0x500
   [] start_secondary+0x113/0x140

 to a SOFTIRQ-irq-unsafe lock:
  (&head->lock){+.+...}
 ... which became SOFTIRQ-irq-unsafe at:
 ...  [] __lock_acquire+0x82f/0x1f10
   [] lock_acquire+0xbc/0x1b0
   [] _raw_spin_lock+0x38/0x50
   [] pcpu_freelist_pop+0x7a/0xb0
   [] htab_map_alloc+0x50c/0x5f0
   [] SyS_bpf+0x265/0x1200
   [] entry_SYSCALL_64_fastpath+0x12/0x17

 other info that might help us debug this:

 Chain exists of:
   dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2 --> &htab->buckets[i].lock --> &head->lock

  Possible interrupt unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&head->lock);
                                local_irq_disable();
                                lock(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2);
                                lock(&htab->buckets[i].lock);
   
     lock(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2);

  *** DEADLOCK ***

Fixes: e19494edab82 ("bpf: introduce percpu_freelist")
Signed-off-by: Eric Dumazet 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

sctp: use the right sk after waking up from wait_buf sleep

2017-12-14T08:28:23+00:00

[ Upstream commit cea0cc80a6777beb6eb643d4ad53690e1ad1d4ff ]

Commit dfcb9f4f99f1 ("sctp: deny peeloff operation on asocs with threads
sleeping on it") fixed the race between peeloff and wait sndbuf by
checking waitqueue_active(&asoc->wait) in sctp_do_peeloff().

But it actually doesn't work, as even if waitqueue_active returns false
the waiting sndbuf thread may still not yet hold sk lock. After asoc is
peeled off, sk is not asoc->base.sk any more, then to hold the old sk
lock couldn't make assoc safe to access.

This patch is to fix this by changing to hold the new sk lock if sk is
not asoc->base.sk, meanwhile, also set the sk in sctp_sendmsg with the
new sk.

With this fix, there is no more race between peeloff and waitbuf, the
check 'waitqueue_active' in sctp_do_peeloff can be removed.

Thanks Marcelo and Neil for making this clear.

v1->v2:
  fix it by changing to lock the new sock instead of adding a flag in asoc.

Suggested-by: Neil Horman 
Signed-off-by: Xin Long 
Acked-by: Neil Horman 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman