Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
GIT fa19a769f82fb9a5ca000b83cacd13fcaeda51ac
commit 5eb7c0d04f04a667c049fe090a95494a8de2955c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Sun Jan 1 20:25:25 2017 -0600
taint/module: Fix problems when out-of-kernel driver defines true or false
Commit 7fd8329ba502 ("taint/module: Clean up global and module taint
flags handling") used the key words true and false as character members
of a new struct. These names cause problems when out-of-kernel modules
such as VirtualBox include their own definitions of true and false.
Fixes: 7fd8329ba502 ("taint/module: Clean up global and module taint flags handling")
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Jessica Yu <jeyu@redhat.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Jessica Yu <jeyu@redhat.com>
commit 4e71de7986386d5fd3765458f27d612931f27f5e
Author: Zhou Chengming <zhouchengming1@huawei.com>
Date: Mon Jan 16 11:21:11 2017 +0800
perf/x86/intel: Handle exclusive threadid correctly on CPU hotplug
The CPU hotplug function intel_pmu_cpu_starting() sets
cpu_hw_events.excl_thread_id unconditionally to 1 when the shared exclusive
counters data structure is already availabe for the sibling thread.
This works during the boot process because the first sibling gets threadid
0 assigned and the second sibling which shares the data structure gets 1.
But when the first thread of the core is offlined and onlined again it
shares the data structure with the second thread and gets exclusive thread
id 1 assigned as well.
Prevent this by checking the threadid of the already online thread.
[ tglx: Rewrote changelog ]
Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
Cc: NuoHan Qiao <qiaonuohan@huawei.com>
Cc: ak@linux.intel.com
Cc: peterz@infradead.org
Cc: kan.liang@intel.com
Cc: dave.hansen@linux.intel.com
Cc: eranian@google.com
Cc: qiaonuohan@huawei.com
Cc: davidcc@google.com
Cc: guohanjun@huawei.com
Link: http://lkml.kernel.org/r/1484536871-3131-1-git-send-email-zhouchengming1@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
--- ---
arch/x86/events/intel/core.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
commit bc7c36eedb0c7004aa06c2afc3c5385adada8fa3
Author: Joonyoung Shim <jy0922.shim@samsung.com>
Date: Tue Jan 17 13:54:36 2017 +0900
clocksource/exynos_mct: Clear interrupt when cpu is shut down
When a CPU goes offline a potentially pending timer interrupt is not
cleared. When the CPU comes online again then the pending interrupt is
delivered before the per cpu clockevent device is initialized. As a
consequence the tick interrupt handler dereferences a NULL pointer.
[ 51.251378] Unable to handle kernel NULL pointer dereference at virtual address 00000040
[ 51.289348] task: ee942d00 task.stack: ee960000
[ 51.293861] PC is at tick_periodic+0x38/0xb0
[ 51.298102] LR is at tick_handle_periodic+0x1c/0x90
Clear the pending interrupt in the cpu dying path.
Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier")
Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org
Cc: cw00.choi@samsung.com
Cc: daniel.lezcano@linaro.org
Cc: stable@vger.kernel.org
Cc: javier@osg.samsung.com
Cc: kgene@kernel.org
Cc: krzk@kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.shim@samsung.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 0faa9cb5b3836a979864a6357e01d2046884ad52
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun Jan 15 10:14:06 2017 -0500
net sched actions: fix refcnt when GETing of action after bind
Demonstrating the issue:
.. add a drop action
$sudo $TC actions add action drop index 10
.. retrieve it
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 2 bind 0 installed 29 sec used 29 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
... bug 1 above: reference is two.
Reference is actually 1 but we forget to subtract 1.
... do a GET again and we see the same issue
try a few times and nothing changes
~$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 2 bind 0 installed 31 sec used 31 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
... lets try to bind the action to a filter..
$ sudo $TC qdisc add dev lo ingress
$ sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 10
... and now a few GETs:
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 3 bind 1 installed 204 sec used 204 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 4 bind 1 installed 206 sec used 206 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 5 bind 1 installed 235 sec used 235 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
.... as can be observed the reference count keeps going up.
After the fix
$ sudo $TC actions add action drop index 10
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 1 bind 0 installed 4 sec used 4 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 1 bind 0 installed 6 sec used 6 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
$ sudo $TC qdisc add dev lo ingress
$ sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 10
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 2 bind 1 installed 32 sec used 32 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
$ sudo $TC -s actions get action gact index 10
action order 1: gact action drop
random type none pass val 0
index 10 ref 2 bind 1 installed 33 sec used 33 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
Fixes: aecc5cefc389 ("net sched actions: fix GETing actions")
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 9577b174cd0323d287c994ef0891db71666d0765
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date: Mon Jan 16 18:31:39 2017 +0200
net/mlx4_core: Eliminate warning messages for SRQ_LIMIT under SRIOV
When running SRIOV, warnings for SRQ LIMIT events flood the Hypervisor's
message log when (correct, normally operating) apps use SRQ LIMIT events
as a trigger to post WQEs to SRQs.
Add more information to the existing debug printout for SRQ_LIMIT, and
output the warning messages only for the SRQ CATAS ERROR event.
Fixes: acba2420f9d2 ("mlx4_core: Add wrapper functions and comm channel and slave event support to EQs")
Fixes: e0debf9cb50d ("mlx4_core: Reduce warning message for SRQ_LIMIT event to debug level")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 7c3945bc2073554bb2ecf983e073dee686679c53
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date: Mon Jan 16 18:31:38 2017 +0200
net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions
Save the qp context flags byte containing the flag disabling vlan stripping
in the RESET to INIT qp transition, rather than in the INIT to RTR
transition. Per the firmware spec, the flags in this byte are active
in the RESET to INIT transition.
As a result of saving the flags in the incorrect qp transition, when
switching dynamically from VGT to VST and back to VGT, the vlan
remained stripped (as is required for VST) and did not return to
not-stripped (as is required for VGT).
Fixes: f0f829bf42cd ("net/mlx4_core: Add immediate activate for VGT->VST->VGT")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 291c566a28910614ce42d0ffe82196eddd6346f4
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date: Mon Jan 16 18:31:37 2017 +0200
net/mlx4_core: Fix racy CQ (Completion Queue) free
In function mlx4_cq_completion() and mlx4_cq_event(), the
radix_tree_lookup requires a rcu_read_lock.
This is mandatory: if another core frees the CQ, it could
run the radix_tree_node_rcu_free() call_rcu() callback while
its being used by the radix tree lookup function.
Additionally, in function mlx4_cq_event(), since we are adding
the rcu lock around the radix-tree lookup, we no longer need to take
the spinlock. Also, the synchronize_irq() call for the async event
eliminates the need for incrementing the cq reference count in
mlx4_cq_event().
Other changes:
1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock:
we no longer take this spinlock in the interrupt context.
The spinlock here, therefore, simply protects against different
threads simultaneously invoking mlx4_cq_free() for different cq's.
2. In function mlx4_cq_free(), we move the radix tree delete to before
the synchronize_irq() calls. This guarantees that we will not
access this cq during any subsequent interrupts, and therefore can
safely free the CQ after the synchronize_irq calls. The rcu_read_lock
in the interrupt handlers only needs to protect against corrupting the
radix tree; the interrupt handlers may access the cq outside the
rcu_read_lock due to the synchronize_irq calls which protect against
premature freeing of the cq.
3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg.
4. We leave the cq reference count mechanism in place, because it is
still needed for the cq completion tasklet mechanism.
Fixes: 6d90aa5cf17b ("net/mlx4_core: Make sure there are no pending async events when freeing CQ")
Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit b618ab4561d40664492cf9f9507f19a1c8272970
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sun Jan 15 19:19:00 2017 +0100
net: stmmac: don't use netdev_[dbg, info, ..] before net_device is registered
Don't use netdev_info and friends before the net_device is registered.
This avoids ugly messages like
"meson8b-dwmac c9410000.ethernet (unnamed net_device) (uninitialized):
Enable RX Mitigation via HW Watchdog Timer"
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit abeffce90c7f6ce74de9794ad0977a168edf8ef6
Author: Arnd Bergmann <arnd@arndb.de>
Date: Sun Jan 15 19:50:46 2017 +0200
net/mlx5e: Fix a -Wmaybe-uninitialized warning
As found by Olof's build bot, we gain a harmless warning about a
potential uninitialized variable reference in mlx5:
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'parse_tc_fdb_actions':
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was declared here
This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair
that gcc is unfortunately unable to completely figure out.
The problem being gcc cannot tell that if(IS_ERR()) in
mlx5e_route_lookup_ipv4() is equivalent to checking if(err) later,
so it assumes that 'out_dev' is used after the 'return PTR_ERR(rt)'.
The PTR_ERR_OR_ZERO() case by comparison is fairly easy to detect
by gcc, so it can't get that wrong, so it no longer warns.
Hadar Hen Zion already attempted to fix the warning earlier by adding fake
initializations, but that ended up not fully addressing all warnings, so
I'm reverting it now that it is no longer needed.
Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.10-rc3-98-gcff3b2c/
Fixes: a42485eb0ee4 ("net/mlx5e: TC ipv4 tunnel encap offload error flow fixes")
Fixes: a757d108dc1a ("net/mlx5e: Fix kbuild warnings for uninitialized parameters")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8a367e74c0120ef68c8c70d5a025648c96626dff
Author: Basil Gunn <basil@pacabunga.com>
Date: Sat Jan 14 12:18:55 2017 -0800
ax25: Fix segfault after sock connection timeout
The ax.25 socket connection timed out & the sock struct has been
previously taken down ie. sock struct is now a NULL pointer. Checking
the sock_flag causes the segfault. Check if the socket struct pointer
is NULL before checking sock_flag. This segfault is seen in
timed out netrom connections.
Please submit to -stable.
Signed-off-by: Basil Gunn <basil@pacabunga.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit f1f7714ea51c56b7163fb1a5acf39c6a204dd758
Author: Daniel Borkmann <daniel@iogearbox.net>
Date: Fri Jan 13 23:38:15 2017 +0100
bpf: rework prog_digest into prog_tag
Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
fdinfo/netlink") was recently discussed, partially due to
admittedly suboptimal name of "prog_digest" in combination
with sha1 hash usage, thus inevitably and rightfully concerns
about its security in terms of collision resistance were
raised with regards to use-cases.
The intended use cases are for debugging resp. introspection
only for providing a stable "tag" over the instruction sequence
that both kernel and user space can calculate independently.
It's not usable at all for making a security relevant decision.
So collisions where two different instruction sequences generate
the same tag can happen, but ideally at a rather low rate. The
"tag" will be dumped in hex and is short enough to introspect
in tracepoints or kallsyms output along with other data such
as stack trace, etc. Thus, this patch performs a rename into
prog_tag and truncates the tag to a short output (64 bits) to
make it obvious it's not collision-free.
Should in future a hash or facility be needed with a security
relevant focus, then we can think about requirements, constraints,
etc that would fit to that situation. For now, rework the exposed
parts for the current use cases as long as nothing has been
released yet. Tested on x86_64 and s390x.
Fixes: 7bd509e311f4 ("bpf: add prog_digest and expose it via fdinfo/netlink")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 613f050d68a8ed3c0b18b9568698908ef7bbc1f7
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date: Wed Jan 11 15:01:57 2017 +0900
perf probe: Fix to probe on gcc generated functions in modules
Fix to probe on gcc generated functions on modules. Since
probing on a module is based on its symbol name, it should
be adjusted on actual symbols.
E.g. without this fix, perf probe shows probe definition
on non-exist symbol as below.
$ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -F in_range*
in_range.isra.12
$ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
p:probe/in_range nf_nat:in_range+0
With this fix, perf probe correctly shows a probe on
gcc-generated symbol.
$ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
p:probe/in_range nf_nat:in_range.isra.12+0
This also fixes same problem on online module as below.
$ perf probe -m i915 -D assert_plane
p:probe/assert_plane i915:assert_plane.constprop.134+0
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/148411450673.9978.14905987549651656075.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
commit 3e96dac7c956089d3f23aca98c4dfca57b6aaf8a
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date: Wed Jan 11 15:00:47 2017 +0900
perf probe: Add error checks to offline probe post-processing
Add error check codes on post processing and improve it for offline
probe events as:
- post processing fails if no matched symbol found in map(-ENOENT)
or strdup() failed(-ENOMEM).
- Even if the symbol name is the same, it updates symbol address
and offset.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/148411443738.9978.4617979132625405545.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
commit 57d5f64d83ab5b5a5118b1597386dd76eaf4340d
Author: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date: Fri Jan 13 15:46:25 2017 +0100
tipc: allocate user memory with GFP_KERNEL flag
Until now, we allocate memory always with GFP_ATOMIC flag.
When the system is under memory pressure and a user tries to send,
the send fails due to low memory. However, the user application
can wait for free memory if we allocate it using GFP_KERNEL flag.
In this commit, we use allocate memory with GFP_KERNEL for all user
allocation.
Reported-by: Rune Torgersen <runet@innovsys.com>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 34c55cf2fc75f8bf6ba87df321038c064cf2d426
Author: Karicheri, Muralidharan <m-karicheri2@ti.com>
Date: Fri Jan 13 09:32:34 2017 -0500
net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
Currently dp83867 driver returns error if phy interface type
PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
Fix this by checking also the interface type if a particular delay
value is missing in the phy dt bindings. Also update the DT document
accordingly.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 02ca0423fd65a0a9c4d70da0dbb8f4b8503f08c7
Author: Jakub Sitnicki <jkbs@redhat.com>
Date: Fri Jan 13 10:12:20 2017 +0100
ip6_tunnel: Account for tunnel header in tunnel MTU
With ip6gre we have a tunnel header which also makes the tunnel MTU
smaller. We need to reserve room for it. Previously we were using up
space reserved for the Tunnel Encapsulation Limit option
header (RFC 2473).
Also, after commit b05229f44228 ("gre6: Cleanup GREv6 transmit path,
call common GRE functions") our contract with the caller has
changed. Now we check if the packet length exceeds the tunnel MTU after
the tunnel header has been pushed, unlike before.
This is reflected in the check where we look at the packet length minus
the size of the tunnel header, which is already accounted for in tunnel
MTU.
Fixes: b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")
Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d2d4edbebe07ddb77980656abe7b9bc7a9e0cdf7
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date: Wed Jan 11 14:59:38 2017 +0900
perf probe: Fix to show correct locations for events on modules
Fix to show correct locations for events on modules by relocating given
address instead of retrying after failure.
This happens when the module text size is big enough, bigger than
sh_addr, because the original code retries with given address + sh_addr
if it failed to find CU DIE at the given address.
Any address smaller than sh_addr always fails and it retries with the
correct address, but addresses bigger than sh_addr will get a CU DIE
which is on the given address (not adjusted by sh_addr).
In my environment(x86-64), the sh_addr of ".text" section is 0x10030.
Since i915 is a huge kernel module, we can see this issue as below.
$ grep "[Tt] .*\[i915\]" /proc/kallsyms | sort | head -n1
ffffffffc0270000 t i915_switcheroo_can_switch [i915]
ffffffffc0270000 + 0x10030 = ffffffffc0280030, so we'll check
symbols cross this boundary.
$ grep "[Tt] .*\[i915\]" /proc/kallsyms | grep -B1 ^ffffffffc028\
| head -n 2
ffffffffc027ff80 t haswell_init_clock_gating [i915]
ffffffffc0280110 t valleyview_init_clock_gating [i915]
So setup probes on both function and see what happen.
$ sudo ./perf probe -m i915 -a haswell_init_clock_gating \
-a valleyview_init_clock_gating
Added new events:
probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
You can now use it in all perf tools, such as:
perf record -e probe:valleyview_init_clock_gating -aR sleep 1
$ sudo ./perf probe -l
probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
probe:valleyview_init_clock_gating (on i915_vga_set_decode:4@gpu/drm/i915/i915_drv.c in i915)
As you can see, haswell_init_clock_gating is correctly shown,
but valleyview_init_clock_gating is not.
With this patch, both events are shown correctly.
$ sudo ./perf probe -l
probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
Committer notes:
In my case:
# perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
Added new events:
probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
You can now use it in all perf tools, such as:
perf record -e probe:valleyview_init_clock_gating -aR sleep 1
# perf probe -l
probe:haswell_init_clock_gating (on i915_getparam+432@gpu/drm/i915/i915_drv.c in i915)
probe:valleyview_init_clock_gating (on __i915_printk+240@gpu/drm/i915/i915_drv.c in i915)
#
# readelf -SW /lib/modules/4.9.0+/build/vmlinux | egrep -w '.text|Name'
[Nr] Name Type Address Off Size ES Flg Lk Inf Al
[ 1] .text PROGBITS ffffffff81000000 200000 822fd3 00 AX 0 0 4096
#
So both are b0rked, now with the fix:
# perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
Added new events:
probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
You can now use it in all perf tools, such as:
perf record -e probe:valleyview_init_clock_gating -aR sleep 1
# perf probe -l
probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
#
Both looks correct.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/148411436777.9978.1440275861947194930.stgit@devbox
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
commit 1666d49e1d416fcc2cce708242a52fe3317ea8ba
Author: Hangbin Liu <liuhangbin@gmail.com>
Date: Thu Jan 12 21:19:37 2017 +0800
mld: do not remove mld souce list info when set link down
This is an IPv6 version of commit 24803f38a5c0 ("igmp: do not remove igmp
souce list..."). In mld_del_delrec(), we will restore back all source filter
info instead of flush them.
Move mld_clear_delrec() from ipv6_mc_down() to ipv6_mc_destroy_dev() since
we should not remove source list info when set link down. Remove
igmp6_group_dropped() in ipv6_mc_destroy_dev() since we have called it in
ipv6_mc_down().
Also clear all source info after igmp6_group_dropped() instead of in it
because ipv6_mc_down() will call igmp6_group_dropped().
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 90f92c631b210c1e97080b53a9d863783281a932
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Tue Sep 13 12:31:17 2016 +0100
ARM: 8613/1: Fix the uaccess crash on PB11MPCore
The following patch was sketched by Russell in response to my
crashes on the PB11MPCore after the patch for software-based
priviledged no access support for ARMv8.1. See this thread:
http://marc.info/?l=linux-arm-kernel&m=144051749807214&w=2
I am unsure what is going on, I suspect everyone involved in
the discussion is. I just want to repost this to get the
discussion restarted, as I still have to apply this patch
with every kernel iteration to get my PB11MPCore Realview
running.
Testing by Neil Armstrong on the Oxnas NAS has revealed that
this bug exist also on that widely deployed hardware, so
we are probably currently regressing all ARM11MPCore systems.
Cc: Russell King <linux@armlinux.org.uk>
Cc: Will Deacon <will.deacon@arm.com>
Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
commit 34393529163af7163ef8459808e3cf2af7db7f16
Author: Ivan Vecera <cera@cera.cz>
Date: Fri Jan 13 22:38:29 2017 +0100
be2net: fix MAC addr setting on privileged BE3 VFs
During interface opening MAC address stored in netdev->dev_addr is
programmed in the HW with exception of BE3 VFs where the initial
MAC is programmed by parent PF. This is OK when MAC address is not
changed when an interfaces is down. In this case the requested MAC is
stored to netdev->dev_addr and later is stored into HW during opening.
But this is not done for all BE3 VFs so the NIC HW does not know
anything about this change and all traffic is filtered.
This is the case of bonding if fail_over_mac == 0 where the MACs of
the slaves are changed while they are down.
The be2net behavior is too restrictive because if a BE3 VF has
the FILTMGMT privilege then it is able to modify its MAC without
any restriction.
To solve the described problem the driver should take care about these
privileged BE3 VFs so the MAC is programmed during opening. And by
contrast unpriviled BE3 VFs should not be allowed to change its MAC
in any case.
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 6d928ae590c8d58cfd5cca997d54394de139cbb7
Author: Ivan Vecera <cera@cera.cz>
Date: Fri Jan 13 22:38:28 2017 +0100
be2net: don't delete MAC on close on unprivileged BE3 VFs
BE3 VFs without FILTMGMT privilege are not allowed to modify its MAC,
VLAN table and UC/MC lists. So don't try to delete MAC on such VFs.
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fe68d8bfe59c561664aa87d827aa4b320eb08895
Author: Ivan Vecera <cera@cera.cz>
Date: Fri Jan 13 22:38:27 2017 +0100
be2net: fix status check in be_cmd_pmac_add()
Return value from be_mcc_notify_wait() contains a base completion status
together with an additional status. The base_status() macro need to be
used to access base status.
Fixes: e3a7ae2 be2net: Changing MAC Address of a VF was broken
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d43e6fb4ac4abfe4ef7c102833ed02330ad701e0
Author: Arnd Bergmann <arnd@arndb.de>
Date: Mon Jan 16 14:20:54 2017 +0100
cpmac: remove hopeless #warning
The #warning was present 10 years ago when the driver first got merged.
As the platform is rather obsolete by now, it seems very unlikely that
the warning will cause anyone to fix the code properly.
kernelci.org reports the warning for every build in the meantime, so
I think it's better to just turn it into a code comment to reduce
noise.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 8ec3e8a192ba6f13be4522ee81227c792c86fb1a
Author: Masaru Nagai <masaru.nagai.vx@renesas.com>
Date: Mon Jan 16 11:45:21 2017 +0100
ravb: do not use zero-length alignment DMA descriptor
Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.
In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.
In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:
[ 20.381417] ------------[ cut here ]------------
[ 20.386054] kernel BUG at lib/swiotlb.c:495!
[ 20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[ 20.395805] Modules linked in:
[ 20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
[ 20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[ 20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[ 20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[ 20.424625] LR is at map_single+0x4c/0x98
[ 20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[ 20.436019] sp : ffff80063a71f9b0
[ 20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[ 20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[ 20.449944] x25: 000000067abe2adc x24: 0000000000000000
[ 20.455252] x23: 0000000000200000 x22: 0000000000000001
[ 20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[ 20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[ 20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[ 20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[ 20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[ 20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[ 20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[ 20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[ 20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[ 20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[ 20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[ 20.518958]
[ 20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[ 20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[ 20.532543] f9a0: ffff80063a71fa30 ffff00000839c680
[ 20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[ 20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[ 20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[ 20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[ 20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[ 20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[ 20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[ 20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[ 20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[ 20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[ 20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[ 20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[ 20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[ 20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[ 20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[ 20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[ 20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[ 20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[ 20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[ 20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[ 20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[ 20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[ 20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[ 20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[ 20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[ 20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[ 20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[ 20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[ 20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[ 20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[ 20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[ 20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[ 20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[ 20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[ 20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[ 20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[ 20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[ 20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[ 20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[ 20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[ 20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[ 20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[ 20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[ 20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[ 20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[ 20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[ 20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[ 20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[ 20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[ 20.931867] Call trace:
[ 20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[ 20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[ 20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[ 20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[ 20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[ 20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[ 20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[ 20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[ 20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[ 21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[ 21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[ 21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[ 21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[ 21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[ 21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[ 21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[ 21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[ 21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[ 21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[ 21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[ 21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[ 21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[ 21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[ 21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[ 21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[ 21.094611] ---[ end trace 5bc544ad491f3814 ]---
[ 21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[ 21.105587] Kernel Offset: disabled
[ 21.109073] Memory Limit: none
[ 21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 0d7f4f0594fc38531e37b94a73ea3ebcc9d9bc11
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue Nov 1 20:27:13 2016 +0000
MAINTAINERS: update rmk's entries
Update my entries in the MAINTAINERS file with the same email address
for kernel work, and, now that the git tree is hosted on more suitable
hardware, add git tree references where appropriate.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
commit 8cf699ec849f4ca1413cea01289bd7d37dbcc626
Author: Eric Dumazet <edumazet@google.com>
Date: Fri Jan 13 08:39:24 2017 -0800
mlx4: do not call napi_schedule() without care
Disable BH around the call to napi_schedule() to avoid following warning
[ 52.095499] NOHZ: local_softirq_pending 08
[ 52.421291] NOHZ: local_softirq_pending 08
[ 52.608313] NOHZ: local_softirq_pending 08
Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Erez Shitrit <erezsh@mellanox.com>
Cc: Eugenia Emantayev <eugenia@mellanox.com>
Cc: Tariq Toukan <tariqt@mellanox.com>
Acked-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ee6ff743e3a4b697e8286054667d7e4e1b56510d
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date: Fri Jan 13 12:05:03 2017 +0100
mmc: core: Restore parts of the polling policy when switch to HS/HS DDR
Regressions for not being able to detect an eMMC HS DDR mode card has been
reported for the sdhci-esdhc-imx driver, but potentially other sdhci
variants may suffer from the similar problem.
The commit e173f8911f09 ("mmc: core: Update CMD13 polling policy when
switch to HS DDR mode"), is causing the problem. It seems that change moved
one step to far, regarding changing the host's timing before polling for a
busy card.
To fix this, let's move back to the behaviour when the host's timing is
updated after the polling, but before the switch status is fetched and
validated.
In cases when polling with CMD13, we keep validating the switch status at
each attempt. However, to align with the other card busy detections
mechanism, let's fetch and validate the switch status also after the host's
timing is updated.
Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Reported-by: Gary Bisson <gary.bisson@boundarydevices.com>
Fixes: e173f8911f09 ("mmc: core: Update CMD13 polling policy when switch..")
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Dong Aisheng <aisheng.dong@nxp.com>
Cc: Haibo Chen <haibo.chen@nxp.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>
commit 4205e4786d0b9fc3b4fec7b1910cf645a0468307
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jan 10 14:01:05 2017 +0100
cpu/hotplug: Provide dynamic range for prepare stage
Mathieu reported that the LTTNG modules are broken as of 4.10-rc1 due to
the removal of the cpu hotplug notifiers.
Usually I don't care much about out of tree modules, but LTTNG is widely
used in distros. There are two ways to solve that:
1) Reserve a hotplug state for LTTNG
2) Add a dynamic range for the prepare states.
While #1 is the simplest solution, #2 is the proper one as we can convert
in tree users, which do not care about ordering, to the dynamic range as
well.
Add a dynamic range which allows LTTNG to request states in the prepare
stage.
Reported-and-tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Sewior <bigeasy@linutronix.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701101353010.3401@nanos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
commit 75f01a4c9cc291ff5cb28ca1216adb163b7a20ee
Author: Lance Richardson <lrichard@redhat.com>
Date: Thu Jan 12 19:33:18 2017 -0500
openvswitch: maintain correct checksum state in conntrack actions
When executing conntrack actions on skbuffs with checksum mode
CHECKSUM_COMPLETE, the checksum must be updated to account for
header pushes and pulls. Otherwise we get "hw csum failure"
logs similar to this (ICMP packet received on geneve tunnel
via ixgbe NIC):
[ 405.740065] genev_sys_6081: hw csum failure
[ 405.740106] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G I 4.10.0-rc3+ #1
[ 405.740108] Call Trace:
[ 405.740110] <IRQ>
[ 405.740113] dump_stack+0x63/0x87
[ 405.740116] netdev_rx_csum_fault+0x3a/0x40
[ 405.740118] __skb_checksum_complete+0xcf/0xe0
[ 405.740120] nf_ip_checksum+0xc8/0xf0
[ 405.740124] icmp_error+0x1de/0x351 [nf_conntrack_ipv4]
[ 405.740132] nf_conntrack_in+0xe1/0x550 [nf_conntrack]
[ 405.740137] ? find_bucket.isra.2+0x62/0x70 [openvswitch]
[ 405.740143] __ovs_ct_lookup+0x95/0x980 [openvswitch]
[ 405.740145] ? netif_rx_internal+0x44/0x110
[ 405.740149] ovs_ct_execute+0x147/0x4b0 [openvswitch]
[ 405.740153] do_execute_actions+0x22e/0xa70 [openvswitch]
[ 405.740157] ovs_execute_actions+0x40/0x120 [openvswitch]
[ 405.740161] ovs_dp_process_packet+0x84/0x120 [openvswitch]
[ 405.740166] ovs_vport_receive+0x73/0xd0 [openvswitch]
[ 405.740168] ? udp_rcv+0x1a/0x20
[ 405.740170] ? ip_local_deliver_finish+0x93/0x1e0
[ 405.740172] ? ip_local_deliver+0x6f/0xe0
[ 405.740174] ? ip_rcv_finish+0x3a0/0x3a0
[ 405.740176] ? ip_rcv_finish+0xdb/0x3a0
[ 405.740177] ? ip_rcv+0x2a7/0x400
[ 405.740180] ? __netif_receive_skb_core+0x970/0xa00
[ 405.740185] netdev_frame_hook+0xd3/0x160 [openvswitch]
[ 405.740187] __netif_receive_skb_core+0x1dc/0xa00
[ 405.740194] ? ixgbe_clean_rx_irq+0x46d/0xa20 [ixgbe]
[ 405.740197] __netif_receive_skb+0x18/0x60
[ 405.740199] netif_receive_skb_internal+0x40/0xb0
[ 405.740201] napi_gro_receive+0xcd/0x120
[ 405.740204] gro_cell_poll+0x57/0x80 [geneve]
[ 405.740206] net_rx_action+0x260/0x3c0
[ 405.740209] __do_softirq+0xc9/0x28c
[ 405.740211] irq_exit+0xd9/0xf0
[ 405.740213] do_IRQ+0x51/0xd0
[ 405.740215] common_interrupt+0x93/0x93
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
Signed-off-by: Lance Richardson <lrichard@redhat.com>
Acked-by: Pravin B Shelar <pshelar@ovn.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 602d9858f07c72eab64f5f00e2fae55f9902cfbe
Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date: Wed Jan 11 21:56:31 2017 +0300
swiotlb: ensure that page-sized mappings are page-aligned
Some drivers do depend on page mappings to be page aligned.
Swiotlb already enforces such alignment for mappings greater than page,
extend that to page-sized mappings as well.
Without this fix, nvme hits BUG() in nvme_setup_prps(), because that routine
assumes page-aligned mappings.
Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>
commit 52d7e48b86fc108e45a656d8e53e4237993c481d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Tue Jan 10 02:28:26 2017 -0800
rcu: Narrow early boot window of illegal synchronous grace periods
The current preemptible RCU implementation goes through three phases
during bootup. In the first phase, there is only one CPU that is running
with preemption disabled, so that a no-op is a synchronous grace period.
In the second mid-boot phase, the scheduler is running, but RCU has
not yet gotten its kthreads spawned (and, for expedited grace periods,
workqueues are not yet running. During this time, any attempt to do
a synchronous grace period will hang the system (or complain bitterly,
depending). In the third and final phase, RCU is fully operational and
everything works normally.
This has been OK for some time, but there has recently been some
synchronous grace periods showing up during the second mid-boot phase.
This code worked "by accident" for awhile, but started failing as soon
as expedited RCU grace periods switched over to workqueues in commit
8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
Note that the code was buggy even before this commit, as it was subject
to failure on real-time systems that forced all expedited grace periods
to run as normal grace periods (for example, using the rcu_normal ksysfs
parameter). The callchain from the failure case is as follows:
early_amd_iommu_init()
|-> acpi_put_table(ivrs_base);
|-> acpi_tb_put_table(table_desc);
|-> acpi_tb_invalidate_table(table_desc);
|-> acpi_tb_release_table(...)
|-> acpi_os_unmap_memory
|-> acpi_os_unmap_iomem
|-> acpi_os_map_cleanup
|-> synchronize_rcu_expedited
The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
which caused the code to try using workqueues before they were
initialized, which did not go well.
This commit therefore reworks RCU to permit synchronous grace periods
to proceed during this mid-boot phase. This commit is therefore a
fix to a regression introduced in v4.9, and is therefore being put
forward post-merge-window in v4.10.
This commit sets a flag from the existing rcu_scheduler_starting()
function which causes all synchronous grace periods to take the expedited
path. The expedited path now checks this flag, using the requesting task
to drive the expedited grace period forward during the mid-boot phase.
Finally, this flag is updated by a core_initcall() function named
rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
Note that this arrangement assumes that tasks are not sent POSIX signals
(or anything similar) from the time that the first task is spawned
through core_initcall() time.
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Stan Kain <stan.kain@gmail.com>
Tested-by: Ivan <waffolz@hotmail.com>
Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
Tested-by: Bruno Pesavento <bpesavento@infinito.it>
Tested-by: Borislav Petkov <bp@suse.de>
Tested-by: Frederic Bezies <fredbezies@gmail.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
commit f466ae66fa6a599f9a53b5f9bafea4b8cfffa7fb
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Mon Jan 9 23:23:15 2017 -0800
rcu: Remove cond_resched() from Tiny synchronize_sched()
It is now legal to invoke synchronize_sched() at early boot, which causes
Tiny RCU's synchronize_sched() to emit spurious splats. This commit
therefore removes the cond_resched() from Tiny RCU's synchronize_sched().
Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: <stable@vger.kernel.org> # 4.9.0-
commit c6180a6237174f481dc856ed6e890d8196b6f0fb
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Fri Jan 13 13:31:32 2017 -0500
NFSv4: Fix client recovery when server reboots multiple times
If the server reboots multiple times, the client should rely on the
server to tell it that it cannot reclaim state as per section 9.6.3.4
in RFC7530 and section 8.4.2.1 in RFC5661.
Currently, the client is being to conservative, and is assuming that
if the server reboots while state recovery is in progress, then it must
ignore state that was not recovered before the reboot.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
commit 003c941057eaa868ca6fedd29a274c863167230d
Author: Shannon Nelson <shannon.nelson@oracle.com>
Date: Thu Jan 12 14:24:58 2017 -0800
tcp: fix tcp_fastopen unaligned access complaints on sparc
Fix up a data alignment issue on sparc by swapping the order
of the cookie byte array field with the length field in
struct tcp_fastopen_cookie, and making it a proper union
to clean up the typecasting.
This addresses log complaints like these:
log_unaligned: 113 callbacks suppressed
Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
Kernel unaligned access at TPC[9764ac] tcp_try_fastopen+0x2ec/0x360
Kernel unaligned access at TPC[9764c8] tcp_try_fastopen+0x308/0x360
Kernel unaligned access at TPC[9764e4] tcp_try_fastopen+0x324/0x360
Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit fa79581ea66ca43d56ef065346ac5be767fcb418
Author: David Lebrun <david.lebrun@uclouvain.be>
Date: Thu Jan 12 21:30:01 2017 +0100
ipv6: sr: fix several BUGs when preemption is enabled
When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
seg6_hmac_init() is called during the initialization of the ipv6 module.
This causes a subsequent call to smp_processor_id() with preemption
enabled, resulting in the following trace.
[ 20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
[ 20.452556] caller is debug_smp_processor_id+0x17/0x19
[ 20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
[ 20.454406] ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
[ 20.455528] ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
[ 20.456539] ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
[ 20.456539] Call Trace:
[ 20.456539] [<ffffffff813607b2>] dump_stack+0x63/0x7f
[ 20.456539] [<ffffffff813778dc>] check_preemption_disabled+0xd1/0xe3
[ 20.456539] [<ffffffff81377905>] debug_smp_processor_id+0x17/0x19
[ 20.460260] [<ffffffffa0061f3b>] seg6_hmac_init+0xfa/0x192 [ipv6]
[ 20.460260] [<ffffffffa0061ccc>] seg6_init+0x39/0x6f [ipv6]
[ 20.460260] [<ffffffffa006121a>] inet6_init+0x21a/0x321 [ipv6]
[ 20.460260] [<ffffffffa0061000>] ? 0xffffffffa0061000
[ 20.460260] [<ffffffff81000457>] do_one_initcall+0x8b/0x115
[ 20.460260] [<ffffffff811328a3>] do_init_module+0x53/0x1c4
[ 20.460260] [<ffffffff8110650a>] load_module+0x1153/0x14ec
[ 20.460260] [<ffffffff81106a7b>] SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106a7b>] ? SYSC_finit_module+0x8c/0xb9
[ 20.460260] [<ffffffff81106abc>] SyS_finit_module+0x9/0xb
[ 20.460260] [<ffffffff810014d1>] do_syscall_64+0x62/0x75
[ 20.460260] [<ffffffff816834f0>] entry_SYSCALL64_slow_path+0x25/0x25
Moreover, dst_cache_* functions also call smp_processor_id(), generating
a similar trace.
This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
and disable preemption when using dst_cache_* functions.
Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 148d3d021cf9724fcf189ce4e525a094bbf5ce89
Author: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu Jan 12 12:09:09 2017 -0800
net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
The __bcm_sysport_tx_reclaim() function is used to reclaim transmit
resources in different places within the driver. Most of them should
not affect the state of the transit flow control.
Introduce bcm_sysport_tx_clean() which cleans the ring, but does not
re-enable flow control towards the networking stack, and make
bcm_sysport_tx_reclaim() do the actual transmit queue flow control.
Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ed79c9d34f4f4c5842b66cab840315e7ac29f666
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri Jan 13 11:46:39 2017 +0100
ARM: put types.h in uapi
Due to the way kbuild works, this header was unintentionally exported
back in 2013 when it was created, despite it not being in a uapi/
directory. This is very non-intuitive behaviour by Kbuild.
However, we've had this include exported to userland for almost four
years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
no hint that anyone has complained about it. So, let's make it
officially exported in this state.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
commit dbef53621116474bb883f76f0ba6b7640bc42332
Author: Michal Kazior <michal.kazior@tieto.com>
Date: Fri Jan 13 13:32:51 2017 +0100
mac80211: prevent skb/txq mismatch
Station structure is considered as not uploaded
(to driver) until drv_sta_state() finishes. This
call is however done after the structure is
attached to mac80211 internal lists and hashes.
This means mac80211 can lookup (and use) station
structure before it is uploaded to a driver.
If this happens (structure exists, but
sta->uploaded is false) fast_tx path can still be
taken. Deep in the fastpath call the sta->uploaded
is checked against to derive "pubsta" argument for
ieee80211_get_txq(). If sta->uploaded is false
(and sta is actually non-NULL) ieee80211_get_txq()
effectively downgraded to vif->txq.
At first glance this may look innocent but coerces
mac80211 into a state that is almost guaranteed
(codel may drop offending skb) to crash because a
station-oriented skb gets queued up on
vif-oriented txq. The ieee80211_tx_dequeue() ends
up looking at info->control.flags and tries to use
txq->sta which in the fail case is NULL.
It's probably pointless to pretend one can
downgrade skb from sta-txq to vif-txq.
Since downgrading unicast traffic to vif->txq must
not be done there's no txq to put a frame on if
sta->uploaded is false. Therefore the code is made
to fall back to regular tx() op path if the
described condition is hit.
Only drivers using wake_tx_queue were affected.
Example crash dump before fix:
Unable to handle kernel paging request at virtual address ffffe26c
PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
[<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
[<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
[<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
[<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
[<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
[<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
[<c0572e90>] (net_rx_action+0xac/0x160)
Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
commit 43071d8fb3b7f589d72663c496a6880fb097533c
Author: Felix Fietkau <nbd@nbd.name>
Date: Fri Jan 13 11:28:25 2017 +0100
mac80211: initialize SMPS field in HT capabilities
ibss and mesh modes copy the ht capabilites from the band without
overriding the SMPS state. Unfortunately the default value 0 for the
SMPS field means static SMPS instead of disabled.
This results in HT ibss and mesh setups using only single-stream rates,
even though SMPS is not supposed to be active.
Initialize SMPS to disabled for all bands on ieee80211_hw_register to
ensure that the value is sane where it is not overriden with the real
SMPS state.
Reported-by: Elektra Wagenrad <onelektra@gmx.net>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
[move VHT TODO comment to a better place]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
commit 7aa4865506a26c607e00bd9794a85785b55ebca7
Author: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Date: Thu Jan 12 07:28:06 2017 -0800
net: thunderx: acpi: fix LMAC initialization
While probing BGX we requesting appropriate QLM for it's configuration
and get LMAC count by that request. Then, while reading configured
MAC values from SSDT table we need to save them in proper mapping:
BGX[i]->lmac[j].mac = <MAC value>
to later provide for initialization stuff. In order to fill
such mapping properly we need to add lmac index to be used while
acpi initialization since at this moment bgx->lmac_count already contains
actual value.
Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit ce1ca7d2d140a1f4aaffd297ac487f246963dd2f
Author: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Date: Mon Jan 9 16:00:44 2017 +0530
svcrdma: avoid duplicate dma unmapping during error recovery
In rdma_read_chunk_frmr() when ib_post_send() fails, the error code path
invokes ib_dma_unmap_sg() to unmap the sg list. It then invokes
svc_rdma_put_frmr() which in turn tries to unmap the same sg list through
ib_dma_unmap_sg() again. This second unmap is invalid and could lead to
problems when the iova being unmapped is subsequently reused. Remove
the call to unmap in rdma_read_chunk_frmr() and let svc_rdma_put_frmr()
handle it.
Fixes: 412a15c0fe53 ("svcrdma: Port to new memory registration API")
Cc: stable@vger.kernel.org
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
commit 8e38b7d4d71479b23b77f01cf0e5071610b8f357
Author: Stefan Schmidt <stefan@osg.samsung.com>
Date: Mon Jan 2 16:58:13 2017…- Loading branch information