linux-stable.git/kernel, branch v4.11.2

cgroup: fix spurious warnings on cgroup_is_dead() from cgroup_sk_alloc()

2017-05-20T12:49:50+00:00

commit a590b90d472f2c176c140576ee3ab44df7f67839 upstream.

cgroup_get() expected to be called only on live cgroups and triggers
warning on a dead cgroup; however, cgroup_sk_alloc() may be called
while cloning a socket which is left in an empty and removed cgroup
and thus may legitimately duplicate its reference on a dead cgroup.
This currently triggers the following warning spuriously.

 WARNING: CPU: 14 PID: 0 at kernel/cgroup.c:490 cgroup_get+0x55/0x60
 ...
  [] __warn+0xd3/0xf0
  [] warn_slowpath_null+0x1e/0x20
  [] cgroup_get+0x55/0x60
  [] cgroup_sk_alloc+0x51/0xe0
  [] sk_clone_lock+0x2db/0x390
  [] inet_csk_clone_lock+0x16/0xc0
  [] tcp_create_openreq_child+0x23/0x4b0
  [] tcp_v6_syn_recv_sock+0x91/0x670
  [] tcp_check_req+0x3a6/0x4e0
  [] tcp_v6_rcv+0x693/0xa00
  [] ip6_input_finish+0x59/0x3e0
  [] ip6_input+0x32/0xb0
  [] ip6_rcv_finish+0x57/0xa0
  [] ipv6_rcv+0x318/0x4d0
  [] __netif_receive_skb_core+0x2d7/0x9a0
  [] __netif_receive_skb+0x16/0x70
  [] netif_receive_skb_internal+0x23/0x80
  [] napi_gro_frags+0x208/0x270
  [] mlx4_en_process_rx_cq+0x74c/0xf40
  [] mlx4_en_poll_rx_cq+0x30/0x90
  [] net_rx_action+0x210/0x350
  [] __do_softirq+0x106/0x2c7
  [] irq_exit+0x9d/0xa0 [] do_IRQ+0x54/0xd0
  [] common_interrupt+0x7f/0x7f 
  [] cpuidle_enter+0x17/0x20
  [] cpu_startup_entry+0x2a9/0x2f0
  [] start_secondary+0xf1/0x100

This patch renames the existing cgroup_get() with the dead cgroup
warning to cgroup_get_live() after cgroup_kn_lock_live() and
introduces the new cgroup_get() which doesn't check whether the cgroup
is live or dead.

All existing cgroup_get() users except for cgroup_sk_alloc() are
converted to use cgroup_get_live().

Fixes: d979a39d7242 ("cgroup: duplicate cgroup reference when cloning sockets")
Cc: Johannes Weiner 
Reported-by: Chris Mason 
Signed-off-by: Tejun Heo 
Signed-off-by: Greg Kroah-Hartman

padata: free correct variable

2017-05-20T12:49:47+00:00

commit 07a77929ba672d93642a56dc2255dd21e6e2290b upstream.

The author meant to free the variable that was just allocated, instead
of the one that failed to be allocated, but made a simple typo. This
patch rectifies that.

Signed-off-by: Jason A. Donenfeld 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

bpf: don't let ldimm64 leak map addresses on unprivileged

2017-05-14T12:06:02+00:00

[ Upstream commit 0d0e57697f162da4aa218b5feafe614fb666db07 ]

The patch fixes two things at once:

1) It checks the env->allow_ptr_leaks and only prints the map address to
   the log if we have the privileges to do so, otherwise it just dumps 0
   as we would when kptr_restrict is enabled on %pK. Given the latter is
   off by default and not every distro sets it, I don't want to rely on
   this, hence the 0 by default for unprivileged.

2) Printing of ldimm64 in the verifier log is currently broken in that
   we don't print the full immediate, but only the 32 bit part of the
   first insn part for ldimm64. Thus, fix this up as well; it's okay to
   access, since we verified all ldimm64 earlier already (including just
   constants) through replace_map_fd_with_map_ptr().

Fixes: 1be7f75d1668 ("bpf: enable non-root eBPF programs")
Fixes: cbd357008604 ("bpf: verifier (add ability to receive verification log)")
Reported-by: Jann Horn 
Signed-off-by: Daniel Borkmann 
Acked-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

bpf: enhance verifier to understand stack pointer arithmetic

2017-05-14T12:06:01+00:00

[ Upstream commit 332270fdc8b6fba07d059a9ad44df9e1a2ad4529 ]

llvm 4.0 and above generates the code like below:
....
440: (b7) r1 = 15
441: (05) goto pc+73
515: (79) r6 = *(u64 *)(r10 -152)
516: (bf) r7 = r10
517: (07) r7 += -112
518: (bf) r2 = r7
519: (0f) r2 += r1
520: (71) r1 = *(u8 *)(r8 +0)
521: (73) *(u8 *)(r2 +45) = r1
....
and the verifier complains "R2 invalid mem access 'inv'" for insn #521.
This is because verifier marks register r2 as unknown value after #519
where r2 is a stack pointer and r1 holds a constant value.

Teach verifier to recognize "stack_ptr + imm" and
"stack_ptr + reg with const val" as valid stack_ptr with new offset.

Signed-off-by: Yonghong Song 
Acked-by: Martin KaFai Lau 
Acked-by: Daniel Borkmann 
Signed-off-by: Alexei Starovoitov 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

sched/cputime: Fix ksoftirqd cputime accounting regression

2017-04-27T07:08:26+00:00

irq_time_read() returns the irqtime minus the ksoftirqd time. This
is necessary because irq_time_read() is used to substract the IRQ time
from the sum_exec_runtime of a task. If we were to include the softirq
time of ksoftirqd, this task would substract its own CPU time everytime
it updates ksoftirqd->sum_exec_runtime which would therefore never
progress.

But this behaviour got broken by:

  a499a5a14db ("sched/cputime: Increment kcpustat directly on irqtime account")

... which now includes ksoftirqd softirq time in the time returned by
irq_time_read().

This has resulted in wrong ksoftirqd cputime reported to userspace
through /proc/stat and thus "top" not showing ksoftirqd when it should
after intense networking load.

ksoftirqd->stime happens to be correct but it gets scaled down by
sum_exec_runtime through task_cputime_adjusted().

To fix this, just account the strict IRQ time in a separate counter and
use it to report the IRQ time.

Reported-and-tested-by: Jesper Dangaard Brouer 
Signed-off-by: Frederic Weisbecker 
Reviewed-by: Rik van Riel 
Acked-by: Jesper Dangaard Brouer 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Stanislaw Gruszka 
Cc: Thomas Gleixner 
Cc: Wanpeng Li 
Link: http://lkml.kernel.org/r/1493129448-5356-1-git-send-email-fweisbec@gmail.com
Signed-off-by: Ingo Molnar

Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2017-04-23T19:48:05+00:00

Pull irq fix from Thomas Gleixner:
 "The (hopefully) final fix for the irq affinity spreading logic"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  genirq/affinity: Fix calculating vectors to assign

Merge tag 'trace-v4.11-rc5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace

2017-04-20T19:30:10+00:00

Pull two more ftrace fixes from Steven Rostedt:
 "While continuing my development, I uncovered two more small bugs.

  One is a race condition when enabling the snapshot function probe
  trigger. It enables the probe before allocating the snapshot, and if
  the probe triggers first, it stops tracing with a warning that the
  snapshot buffer was not allocated.

  The seconds is that the snapshot file should show how to use it when
  it is empty. But a bug fix from long ago broke the "is empty" test and
  the snapshot file no longer displays the help message"

* tag 'trace-v4.11-rc5-5' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  ring-buffer: Have ring_buffer_iter_empty() return true when empty
  tracing: Allocate the snapshot buffer before enabling probe

genirq/affinity: Fix calculating vectors to assign

2017-04-20T14:03:09+00:00

The vectors_per_node is calculated from the remaining available vectors.
The current vector starts after pre_vectors, so we need to subtract that
from the current to properly account for the number of remaining vectors
to assign.

Fixes: 3412386b531 ("irq/affinity: Fix extra vecs calculation")
Reported-by: Andrei Vagin 
Signed-off-by: Keith Busch 
Link: http://lkml.kernel.org/r/1492645870-13019-1-git-send-email-keith.busch@intel.com
Signed-off-by: Thomas Gleixner

ring-buffer: Have ring_buffer_iter_empty() return true when empty

2017-04-20T01:23:47+00:00

I noticed that reading the snapshot file when it is empty no longer gives a
status. It suppose to show the status of the snapshot buffer as well as how
to allocate and use it. For example:

 ># cat snapshot
 # tracer: nop
 #
 #
 # * Snapshot is allocated *
 #
 # Snapshot commands:
 # echo 0 > snapshot : Clears and frees snapshot buffer
 # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated.
 #                      Takes a snapshot of the main buffer.
 # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free)
 #                      (Doesn't have to be '2' works with any number that
 #                       is not a '0' or '1')

But instead it just showed an empty buffer:

 ># cat snapshot
 # tracer: nop
 #
 # entries-in-buffer/entries-written: 0/0   #P:4
 #
 #                              _-----=> irqs-off
 #                             / _----=> need-resched
 #                            | / _---=> hardirq/softirq
 #                            || / _--=> preempt-depth
 #                            ||| /     delay
 #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
 #              | |       |   ||||       |         |

What happened was that it was using the ring_buffer_iter_empty() function to
see if it was empty, and if it was, it showed the status. But that function
was returning false when it was empty. The reason was that the iter header
page was on the reader page, and the reader page was empty, but so was the
buffer itself. The check only tested to see if the iter was on the commit
page, but the commit page was no longer pointing to the reader page, but as
all pages were empty, the buffer is also.

Cc: stable@vger.kernel.org
Fixes: 651e22f2701b ("ring-buffer: Always reset iterator to reader page")
Signed-off-by: Steven Rostedt (VMware)

tracing: Allocate the snapshot buffer before enabling probe

2017-04-19T18:19:08+00:00

Currently the snapshot trigger enables the probe and then allocates the
snapshot. If the probe triggers before the allocation, it could cause the
snapshot to fail and turn tracing off. It's best to allocate the snapshot
buffer first, and then enable the trigger. If something goes wrong in the
enabling of the trigger, the snapshot buffer is still allocated, but it can
also be freed by the user by writting zero into the snapshot buffer file.

Also add a check of the return status of alloc_snapshot().

Cc: stable@vger.kernel.org
Fixes: 77fd5c15e3 ("tracing: Add snapshot trigger to function probes")
Signed-off-by: Steven Rostedt (VMware)