user/sven/linux.git, branch v3.14.68

Linux 3.14.68

2016-05-04T21:51:35Z

sunrpc/cache: drop reference when sunrpc_cache_pipe_upcall() detects a race

2016-05-04T21:51:26Z

commit a6ab1e8126d205238defbb55d23661a3a5c6a0d8 upstream. sunrpc_cache_pipe_upcall() can detect a race if CACHE_PENDING is no longer set. In this case it aborts the queuing of the upcall. However it has already taken a new counted reference on "h" and doesn't "put" it, even though it frees the data structure holding the reference. So let's delay the "cache_get" until we know we need it. Fixes: f9e1aedc6c79 ("sunrpc/cache: remove races with queuing an upcall.") Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields Signed-off-by: Greg Kroah-Hartman

jme: Fix device PM wakeup API usage

2016-05-04T21:51:26Z

commit 81422e672f8181d7ad1ee6c60c723aac649f538f upstream. According to Documentation/power/devices.txt The driver should not use device_set_wakeup_enable() which is the policy for user to decide. Using device_init_wakeup() to initialize dev->power.should_wakeup and dev->power.can_wakeup on driver initialization. And use device_may_wakeup() on suspend to decide if WoL function should be enabled on NIC. Reported-by: Diego Viola Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

jme: Do not enable NIC WoL functions on S0

2016-05-04T21:51:26Z

commit 0772a99b818079e628a1da122ac7ee023faed83e upstream. Otherwise it might be back on resume right after going to suspend in some hardware. Reported-by: Diego Viola Signed-off-by: Guo-Fu Tseng Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

bus: imx-weim: Take the 'status' property value into account

2016-05-04T21:51:26Z

commit 33b96d2c9579213cf3f36d7b29841b1e464750c4 upstream. Currently we have an incorrect behaviour when multiple devices are present under the weim node. For example: &weim { ... status = "okay"; sram@0,0 { ... status = "okay"; }; mram@0,0 { ... status = "disabled"; }; }; In this case only the 'sram' device should be probed and not 'mram'. However what happens currently is that the status variable is ignored, causing the 'sram' device to be disabled and 'mram' to be enabled. Change the weim_parse_dt() function to use for_each_available_child_of_node()so that the devices marked with 'status = disabled' are not probed. Suggested-by: Wolfgang Netbal Signed-off-by: Fabio Estevam Reviewed-by: Sascha Hauer Acked-by: Shawn Guo Signed-off-by: Olof Johansson Signed-off-by: Greg Kroah-Hartman

ARM: OMAP3: Add cpuidle parameters table for omap3430

2016-05-04T21:51:26Z

commit 98f42221501353067251fbf11e732707dbb68ce3 upstream. Based on CPU type choose generic omap3 or omap3430 specific cpuidle parameters. Parameters for omap3430 were measured on Nokia N900 device and added by commit 5a1b1d3a9efa ("OMAP3: RX-51: Pass cpu idle parameters") which were later removed by commit 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table") due to huge code complexity. This patch brings cpuidle parameters for omap3430 devices again, but uses simple condition based on CPU type. Fixes: 231900afba52 ("ARM: OMAP3: cpuidle - remove rx51 cpuidle parameters table") Signed-off-by: Pali Rohár Acked-by: Daniel Lezcano Signed-off-by: Tony Lindgren Signed-off-by: Greg Kroah-Hartman

perf stat: Document --detailed option

2016-05-04T21:51:25Z

commit f594bae08183fb6b57db55387794ece3e1edf6f6 upstream. I'm surprised this remained undocumented since at least 2011. And it is actually a very useful switch, as Steve and I came to realize recently. Add the text from 2cba3ffb9a9d ("perf stat: Add -d -d and -d -d -d options to show more CPU events") which added the incrementing aspect to -d. Tested-by: Arnaldo Carvalho de Melo Signed-off-by: Borislav Petkov Signed-off-by: Arnaldo Carvalho de Melo Cc: Alexander Shishkin Cc: David Ahern Cc: Davidlohr Bueso Cc: Jiri Olsa Cc: Mel Gorman Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Fixes: 2cba3ffb9a9d ("perf stat: Add -d -d and -d -d -d options to show more CPU events") Link: http://lkml.kernel.org/r/1457347294-32546-1-git-send-email-bp@alien8.de Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman

Drivers: hv: vmbus: prevent cpu offlining on newer hypervisors

2016-05-04T21:51:25Z

commit e513229b4c386e6c9f66298c13fde92f73e6e1ac upstream. When an SMP Hyper-V guest is running on top of 2012R2 Server and secondary cpus are sent offline (with echo 0 > /sys/devices/system/cpu/cpu$cpu/online) the system freeze is observed. This happens due to the fact that on newer hypervisors (Win8, WS2012R2, ...) vmbus channel handlers are distributed across all cpus (see init_vp_index() function in drivers/hv/channel_mgmt.c) and on cpu offlining nobody reassigns them to CPU0. Prevent cpu offlining when vmbus is loaded until the issue is fixed host-side. This patch also disables hibernation but it is OK as it is also broken (MCE error is hit on resume). Suspend still works. Tested with WS2008R2 and WS2012R2. Signed-off-by: Vitaly Kuznetsov Signed-off-by: K. Y. Srinivasan [ 3chas3@gmail.com: rebase to 3.14-stable ] Signed-off-by: Chas Williams <3chas3@gmail.com> Signed-off-by: Greg Kroah-Hartman

include/linux/poison.h: fix LIST_POISON{1,2} offset

2016-05-04T21:51:25Z

commit 8a5e5e02fc83aaf67053ab53b359af08c6c49aaf upstream. Poison pointer values should be small enough to find a room in non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space" is located starting from 0x0. Given unprivileged users cannot mmap anything below mmap_min_addr, it should be safe to use poison pointers lower than mmap_min_addr. The current poison pointer values of LIST_POISON{1,2} might be too big for mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu uses only 0x10000). There is little point to use such a big value given the "poison pointer space" below 1 MB is not yet exhausted. Changing it to a smaller value solves the problem for small mmap_min_addr setups. The values are suggested by Solar Designer: http://www.openwall.com/lists/oss-security/2015/05/02/6 Signed-off-by: Vasily Kulikov Cc: Solar Designer Cc: Thomas Gleixner Cc: "Kirill A. Shutemov" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

serial: sh-sci: Remove cpufreq notifier to fix crash/deadlock

2016-05-04T21:51:25Z

commit ff1cab374ad98f4b9f408525ca9c08992b4ed784 upstream. The BSP team noticed that there is spin/mutex lock issue on sh-sci when CPUFREQ is used. The issue is that the notifier function may call mutex_lock() while the spinlock is held, which can lead to a BUG(). This may happen if CPUFREQ is changed while another CPU calls clk_get_rate(). Taking the spinlock was added to the notifier function in commit e552de2413edad1a ("sh-sci: add platform device private data"), to protect the list of serial ports against modification during traversal. At that time the Common Clock Framework didn't exist yet, and clk_get_rate() just returned clk->rate without taking a mutex. Note that since commit d535a2305facf9b4 ("serial: sh-sci: Require a device per port mapping."), there's no longer a list of serial ports to traverse, and taking the spinlock became superfluous. To fix the issue, just remove the cpufreq notifier: 1. The notifier doesn't work correctly: all it does is update stored clock rates; it does not update the divider in the hardware. The divider will only be updated when calling sci_set_termios(). I believe this was broken back in 2004, when the old drivers/char/sh-sci.c driver (where the notifier did update the divider) was replaced by drivers/serial/sh-sci.c (where the notifier just updated port->uartclk). Cfr. full-history-linux commits 6f8deaef2e9675d9 ("[PATCH] sh: port sh-sci driver to the new API") and 3f73fe878dc9210a ("[PATCH] Remove old sh-sci driver"). 2. On modern SoCs, the sh-sci parent clock rate is no longer related to the CPU clock rate anyway, so using a cpufreq notifier is futile. Signed-off-by: Geert Uytterhoeven Signed-off-by: Greg Kroah-Hartman