Krzysztof Kozlowski [Tue, 11 Feb 2014 10:03:32 +0000 (11:03 +0100)]
mfd: max77693: Fix possible NULL pointer dereference on i2c_new_dummy error
commit
ad09dd6a1f5d6244bd89314015af506ba7f9810a upstream.
During probe the driver allocates dummy I2C devices for MUIC and haptic
with i2c_new_dummy() but it does not check the return value of this
calls.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by devm_regmap_init_i2c() and i2c_unregister_device().
If i2c_new_dummy() fails for MUIC or haptic devices, fail also the probe
for main MFD driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Tue, 11 Feb 2014 10:03:31 +0000 (11:03 +0100)]
mfd: max77686: Fix possible NULL pointer dereference on i2c_new_dummy error
commit
b9e183a1d495cd65412abe0f9df19b151716bfe7 upstream.
During probe the driver allocates dummy I2C device for RTC with
i2c_new_dummy() but it does not check the return value of this call.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by i2c_unregister_device().
If i2c_new_dummy() fails for RTC device, fail also the probe for main
MFD driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Wed, 12 Feb 2014 10:10:56 +0000 (11:10 +0100)]
mfd: 88pm800: Fix I2C device resource leak if probe fails
commit
141050cf3d84fc303df58796d68dc1376b0e8f67 upstream.
During probe the driver allocates two dummy I2C devices for subchips in
function pm800_pages_init(). Additionally this function allocates
regmaps for these subchips. If any of these steps fail then these dummy
I2C devices are not freed and resources leak.
On pm800_pages_init() fail the driver must call pm800_pages_exit() to
unregister dummy I2C devices.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Tue, 11 Feb 2014 10:03:30 +0000 (11:03 +0100)]
mfd: 88pm860x: Fix I2C device resource leak on regmap init fail
commit
a7ab1c8b261305af583ce26bb4a14f555fdaa73e upstream.
During probe the driver allocates dummy I2C device for companion chip
and then allocates a regmap for it. If regmap_init_i2c() fails then the
I2C driver (allocated with i2c_new_dummy()) is not freed and this
resource leaks.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Tue, 11 Feb 2014 10:03:29 +0000 (11:03 +0100)]
mfd: 88pm860x: Fix possible NULL pointer dereference on i2c_new_dummy error
commit
159ce52a6b777fc82fa0b51c7440e25f9e4c6feb upstream.
During probe the driver allocates dummy I2C device for companion chip
with i2c_new_dummy() but it does not check the return value of this call.
In case of error (i2c_new_device(): memory allocation failure or I2C
address cannot be used) this function returns NULL which is later used
by regmap_init_i2c().
If i2c_new_dummy() fails for companion device, fail also the probe for
main MFD driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krzysztof Kozlowski [Tue, 11 Feb 2014 09:12:25 +0000 (10:12 +0100)]
mfd: sec-core: Fix possible NULL pointer dereference when i2c_new_dummy error
commit
65aba1e04916d72b30c028730a1e31860c225412 upstream.
During probe the sec-core driver allocates dummy I2C device for RTC with
i2c_new_dummy() but return value is not checked. In case of error
(i2c_new_device(): memory allocation failure or I2C address cannot be
used) this function returns NULL which is later used by
devm_regmap_init_i2c() or i2c_unregister_device().
If i2c_new_dummy() fails for RTC device, fail also the probe for main
MFD driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Usyskin [Tue, 1 Apr 2014 20:50:41 +0000 (23:50 +0300)]
mei: ignore client writing state during cb completion
commit
34ec43661fe8f1977dd0f05353302ae2ed10aabb upstream.
Ignore client writing state during cb completion to fix a memory
leak.
When moving cbs to the completion list we should not look at
writing_state as this state can be already overwritten by next
write, the fact that a cb is on the write waiting list means
that it was already written to the HW and we can safely complete it.
Same pays for wait in poll handler, we do not have to check the state
wake is done after completion list processing.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Tue, 25 Mar 2014 19:25:18 +0000 (21:25 +0200)]
mei: me: do not load the driver if the FW doesn't support MEI interface
commit
5e6533a6f52f1a8283b2f818f5828be99a417dd6 upstream.
NM and SPS FW types that may run on ME device on server platforms
do not have valid MEI/HECI interface and driver should not
be bound to it as this might lead to system hung.
In practice not all BIOSes effectively hide such devices from the
OS and in some cases it is not possible.
We determine FW type by examining Host FW status registers in order to
unbind the driver.
In this patch we are adding check for ME on Cougar Point, Lynx Point
Devices
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Tested-by: Nikola Ciprich <nikola.ciprich@linuxbox.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomas Winkler [Mon, 10 Mar 2014 13:10:40 +0000 (15:10 +0200)]
mei: fix memory leak of pending write cb objects
commit
cc99ecfdac01215594c73907726b12f251c21e20 upstream.
Write callbacks are released on the write completed path but
when file handler is closed before the writes are
completed those are left dangling on write and write_waiting queues.
We add mei_io_list_free function to perform this task
Also move static functions to client.c form client.h
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Schwidefsky [Tue, 1 Apr 2014 11:45:33 +0000 (13:45 +0200)]
s390: fix control register update
commit
a8a934e44f2bd0ed613e1aa0471e3478c6a9228a upstream.
The git commit
c63badebfebacdba827ab1cc1d420fc81bd8d818
"s390: optimize control register update" broke the update for
control register 0. After the update do the lctlg from the correct
value.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Thu, 20 Mar 2014 07:55:00 +0000 (08:55 +0100)]
s390/bitops,atomic: add missing memory barriers
commit
0ccc8b7ac86053388e793bad20bd26bd777752eb upstream.
When reworking the bitops and atomic ops I missed that those instructions
that got atomic behaviour only perform a "specific-operand-serialization"
instead of a full "serialization".
The compare-and-swap instruction used before performs a full serialization
before and after the instruction is executed, which means it has full
memory barrier semantics.
In order to give the new bitops and atomic ops functions also full memory
barrier semantics add a "bcr 14,0" before and after each of those new
instructions which performs full serialization as well.
This restores memory barrier semantics for bitops and atomic ops functions
which return values, like e.g. atomic_add_return(), but not for functions
which do not return a value, like e.g. atomic_add().
This is consistent to other architectures and what common code requires.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian Borntraeger [Thu, 6 Mar 2014 15:01:38 +0000 (16:01 +0100)]
KVM: s390: Optimize ucontrol path
commit
2955c83f72801245afd0fe5c560cc75b82bea9aa upstream.
Since commit
7c470539c95630c1f2a10f109e96f249730b75eb
(s390/kvm: avoid automatic sie reentry) we will run through the C code
of KVM on host interrupts instead of just reentering the guest. This
will result in additional ucontrol exits (at least HZ per second). Let
handle a 0 intercept in the kernel and dont return to userspace,
even if in ucontrol mode.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Ott [Mon, 27 Jan 2014 12:26:10 +0000 (13:26 +0100)]
s390/cio: fix driver callback initialization for ccw consoles
commit
2253e8d79237c69086ded391e6767afe16972527 upstream.
ccw consoles are in use before they can be properly registered with
the driver core. For devices which are in use by a device driver we
rely on the ccw_device's pointer to the driver callbacks to be valid.
For ccw consoles this pointer is NULL until they are registered later
during boot and we dereferenced this pointer. This worked by
chance on 64 bit builds (cdev->drv was NULL but the optional callback
cdev->drv->path_event was also NULL by coincidence) and was unnoticed
until we received reports about boot failures on 31 bit systems.
Fix it by initializing the driver pointer for ccw consoles.
Reported-by: Mike Frysinger <vapier@gentoo.org>
Reported-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Axel Lin [Tue, 25 Mar 2014 04:44:13 +0000 (12:44 +0800)]
spi: dw: Don't call kfree for memory allocated by devm_kzalloc
commit
c63f5da00845143de621e991ea186be0829647ee upstream.
With devm_kzalloc, the memory is automatically freed when spi_device detach from
the bus.
Fixes: commit
43f627ac9de42 (spi: dw: fix memory leak on error path)
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Uwe Kleine-König [Tue, 25 Mar 2014 14:51:50 +0000 (15:51 +0100)]
spi: efm32: use $vendor,$device scheme for compatible string
commit
12f6dd860cf8bf036c0bec38c00a53da71bcd43a upstream.
Wolfram Sang pointed out that "efm32,$device" is non-standard. So use the
common scheme and prefix device with "efm32-". The old compatible string
is left in place until arch/arm/boot/dts/efm32* is fixed.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Wed, 26 Feb 2014 02:29:40 +0000 (10:29 +0800)]
ACPICA: Restore code that repairs NULL package elements in return values.
commit
61db45ca21630f5ab7f678d54c5d969c21647854 upstream.
The original code was lost accidently, it was not generated along with the
following commit of mechanism improvements and thus not get merged:
Commit:
d5a36100f62fa6db5541344e08b361b34e9114c5
Subject: ACPICA: Add mechanism for early object repairs on a per-name basis
Adds the framework to allow object repairs very early in the
return object analysis. Enables repairs like string->unicode,
etc.
This patch restores the implementation of the NULL element repair code for
ACPI_RTYPE_NONE. In the original design, ACPI_RTYPE_NONE is defined to
collect simple NULL object repairs.
Lv Zheng.
Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=67901
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Wed, 16 Apr 2014 07:53:12 +0000 (15:53 +0800)]
ALSA: hda/realtek - Add headset Mic support for Dell machine
commit
8dc9abb93dde94e7f2bc719032fe16f5713df05c upstream.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Mon, 14 Apr 2014 07:09:44 +0000 (15:09 +0800)]
ALSA: hda/realtek - Add support of ALC288 codec
commit
7c66593286bcd153e4868383e675673a27071bd5 upstream.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 3 Apr 2014 09:51:21 +0000 (11:51 +0200)]
ALSA: hda - Fix silent speaker output due to mute LED fixup
commit
415d555e6b398b00fc1733f0113065a54df9106a upstream.
The recent fixups for HP laptops to support the mute LED made the
speaker output silent on some machines. It turned out that they use
the NID 0x18 for the speaker while it's also used for controlling the
LED via VREF bits although the current driver code blindly assumes
that such a node is a mic pin (where 0x18 is usually so).
This patch fixes the problem by only changing the VREF bits and
keeping the other pin ctl bits.
Reported-and-tested-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 8 Apr 2014 14:58:34 +0000 (16:58 +0200)]
ALSA: ice1712: Fix boundary checks in PCM pointer ops
commit
4f8e940095536bc002a81666a4107a581c84e9b9 upstream.
PCM pointer callbacks in ice1712 driver check the buffer size boundary
wrongly between bytes and frames. This leads to PCM core warnings
like:
snd_pcm_update_hw_ptr0: 105 callbacks suppressed
ALSA pcm_lib.c:352 BUG: pcmC3D0c:0, pos = 5461, buffer size = 5461, period size = 2730
This patch fixes these checks to be placed after the proper unit
conversions.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
W. Trevor King [Sun, 30 Mar 2014 00:47:24 +0000 (17:47 -0700)]
ALSA: hda - Enable beep for ASUS 1015E
commit
a4b7f21d7b42b33609df3f86992a8deff80abfaf upstream.
The `lspci -nnvv` output contains (wrapped for line length):
00:1b.0 Audio device [0403]:
Intel Corporation 7 Series/C210 Series Chipset Family
High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: ASUSTeK Computer Inc. Device [1043:115d]
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hui Wang [Wed, 26 Mar 2014 02:27:41 +0000 (10:27 +0800)]
ALSA: hda - add headset mic detect quirks for three Dell laptops
commit
a870593bab179ca402ead455f45af6e4404a2a7f upstream.
When we plug a 3-ring headset on the Dell machines (VID: 0x10ec0255,
SID: 0x10280632; VID: 0x10ec0293, SID: 0x1028062c; VID: 0x10ec0293,
SID: 0x1028062e), the headset mic can't be detected, after apply this
patch, the headset mic can work well.
BugLink: https://bugs.launchpad.net/bugs/1297581
Cc: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Mon, 17 Mar 2014 05:51:27 +0000 (13:51 +0800)]
ALSA: hda/realtek - Restore default value for ALC283
commit
6bd55b04fe05cb26094b0fe494c7a207e6c0c36e upstream.
Restore the registers to prevent the abnormal digital power supply
rising ratio/sequence to the codec and causing the incorrect default
codec register restoration during initialization.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71861
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrea Adami [Tue, 8 Apr 2014 12:53:44 +0000 (14:53 +0200)]
ARM: pxa: hx4700.h: include "irqs.h" for PXA_NR_BUILTIN_GPIO
commit
c02b50e90be9f41d6802049a1a08246e9eb1a22c upstream.
hx4700 needs the same fix as in
9705e74671f0e4f994d86b00cecf441917c64a66
"ARM: pxa: fix various compilation problems"
Fix build errors. Initial one is:
/linux/arch/arm/mach-pxa/include/mach/hx4700.h:18:32: error:
'PXA_NR_BUILTIN_GPIO' undeclared here (not in a function)
| #define HX4700_ASIC3_GPIO_BASE PXA_NR_BUILTIN_GPIO
Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Petazzoni [Tue, 25 Mar 2014 23:33:58 +0000 (00:33 +0100)]
ARM: mvebu: ensure the mdio node has a clock reference on Armada 370/XP
commit
a6e03dd451c724f785277d8ecca5d1a0b886d892 upstream.
The mvmdio driver accesses some register of the Ethernet unit. It
therefore takes a reference and enables a clock. However, on Armada
370/XP, no clock specification was given in the Device Tree, which
leads the mvmdio driver to fail when being used as a module and loaded
before the mvneta driver: it tries to access a register from a
hardware unit that isn't clocked.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Link: https://lkml.kernel.org/r/1395790439-21332-2-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liu Hua [Fri, 18 Apr 2014 06:45:36 +0000 (07:45 +0100)]
ARM: 8030/1: ARM : kdump : add arch_crash_save_vmcoreinfo
commit
56b700fd6f1e49149880fb1b6ffee0dca5be45fb upstream.
For vmcore generated by LPAE enabled kernel, user space
utility such as crash needs additional infomation to
parse.
So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
i386 linux does.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Liu Hua <sdu.liu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xiangyu Lu [Tue, 15 Apr 2014 08:38:17 +0000 (09:38 +0100)]
ARM: 8027/1: fix do_div() bug in big-endian systems
commit
80bb3ef109ff40a7593d9481c17de9bbc4d7c0e2 upstream.
In big-endian systems, "%1" get the most significant part of the value, cause the instruction to get the wrong result.
When viewing ftrace record in big-endian ARM systems, we found that
the timestamp errors:
swapper-0 [001] 1325.970000: 0:120:R ==> [001] 16:120:R events/1
events/1-16 [001] 1325.970000: 16:120:S ==> [001] 0:120:R swapper
swapper-0 [000] 1325.1000000: 0:120:R + [000] 15:120:R events/0
swapper-0 [000] 1325.1000000: 0:120:R ==> [000] 15:120:R events/0
swapper-0 [000] 1326.030000: 0:120:R + [000] 1150:120:R sshd
swapper-0 [000] 1326.030000: 0:120:R ==> [000] 1150:120:R sshd
When viewed ftrace records, it will call the do_div(n, base) function, which achieved arch/arm/include/asm/div64.h in. When n =
10000000, base = 1000000, in do_div(n, base) will execute "umull %Q0, %R0, %1, %Q2".
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Alex Wu <wuquanming@huawei.com>
Signed-off-by: Xiangyu Lu <luxiangyu@huawei.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christopher Covington [Wed, 19 Mar 2014 17:12:25 +0000 (18:12 +0100)]
ARM: 8007/1: Remove extraneous kcmp syscall ignore
commit
95c52fe063351192e0f4ffb70ef9bac1aa26f5a4 upstream.
The kcmp system call was ported to ARM in
commit
3f7d1fe108dbaefd0c57a41753fc2c90b395f458
"ARM: 7665/1: Wire up kcmp syscall".
Fixes:
3f7d1fe108db ("ARM: 7665/1: Wire up kcmp syscall")
Signed-off-by: Christopher Covington <cov@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Lunn [Sat, 22 Feb 2014 19:14:54 +0000 (20:14 +0100)]
ARM: Fix default CPU selection for ARCH_MULTI_V5
commit
12567bbdee7ea553237085a2bbc0ffa5240f5248 upstream.
CPU_ARM926T should be selected if no other CPU is. Put the ! in the
right place so this works.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Fixes:
24e860fbfdb1c ("ARM: multiplatform: always pick one CPU type")
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Fri, 7 Feb 2014 18:12:27 +0000 (19:12 +0100)]
ARM: 7954/1: mm: remove remaining domain support from ARMv6
commit
b6ccb9803e90c16b212cf4ed62913a7591e79a39 upstream.
CPU_32v6 currently selects CPU_USE_DOMAINS if CPU_V6 and MMU. This is
because ARM 1136 r0pX CPUs lack the v6k extensions, and therefore do
not have hardware thread registers. The lack of these registers requires
the kernel to update the vectors page at each context switch in order to
write a new TLS pointer. This write must be done via the userspace
mapping, since aliasing caches can lead to expensive flushing when using
kmap. Finally, this requires the vectors page to be mapped r/w for
kernel and r/o for user, which has implications for things like put_user
which must trigger CoW appropriately when targetting user pages.
The upshot of all this is that a v6/v7 kernel makes use of domains to
segregate kernel and user memory accesses. This has the nasty
side-effect of making device mappings executable, which has been
observed to cause subtle bugs on recent cores (e.g. Cortex-A15
performing a speculative instruction fetch from the GIC and acking an
interrupt in the process).
This patch solves this problem by removing the remaining domain support
from ARMv6. A new memory type is added specifically for the vectors page
which allows that page (and only that page) to be mapped as user r/o,
kernel r/w. All other user r/o pages are mapped also as kernel r/o.
Patch co-developed with Russell King.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tomasz Figa [Thu, 13 Feb 2014 22:43:54 +0000 (07:43 +0900)]
ARM: dts: Keep G3D regulator always on for exynos5250-arndale
commit
bfeda827278f09f4db35877e5f1ca9c149ca2890 upstream.
Apparently, if G3D regulator is powered off, the SoC cannot enter low
power modes and just hangs. This patch fixes this by keeping the
regulator always on when the system is running, as suggested by Exynos 4
User's Manual in case of Exynos4210/4x12 SoCs (Exynos5250 UM does not
have such note, but observed behavior seems to confirm that it is true
for this SoC as well).
This fixes an issue preventing Arndale board from entering sleep mode
observed since commit
346f372f7b72a0 clk: exynos5250: Add CLK_IGNORE_UNUSED flag for pmu clock
that landed in kernel 3.10, which has fixed the clock driver to make the
SoC actually try to enter the sleep mode.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Tested-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Kukjin Kim <kgene.kim@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Vaussard [Wed, 26 Feb 2014 10:38:09 +0000 (11:38 +0100)]
ARM: dts: omap4/5: Use l3_ick for the gpmc node
commit
7b8b6af169a069454936053631d151a50af7b69a upstream.
The GPMC clock is derived from l3_ick. The simplest solution is
to reference directly l3_ick to provide the GPMC fck in order to
get correct timings. The real management of the clock is left to
hwmod.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mugunthan V N [Thu, 6 Mar 2014 12:31:34 +0000 (18:01 +0530)]
ARM: dts: am33xx: correcting dt node unit address for usb
commit
8abcdd680d543fb582371e146e62ba9f2af8a816 upstream.
DT node's unit address should be its own register offset address to make it a
unique across the system. This patch corrects the incorrect USB entries with
correct register offset for unit address.
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roger Quadros [Thu, 10 Apr 2014 07:18:17 +0000 (10:18 +0300)]
ARM: OMAP3: hwmod data: Correct clock domains for USB modules
commit
c6c56697ae4bf1226263c19e8353343d7083f40e upstream.
OMAP3 doesn't contain "l3_init_clkdm" clock domain. Use the
proper clock domains for USB Host and USB TLL modules.
Gets rid of the following warnings during boot
omap_hwmod: usb_host_hs: could not associate to clkdm l3_init_clkdm
omap_hwmod: usb_tll_hs: could not associate to clkdm l3_init_clkdm
Reported-by: Nishanth Menon <nm@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Fixes:
de231388cb80a8ef3e779bbfa0564ba0157b7377 ("ARM: OMAP: USB: EHCI and OHCI hwmod structures for OMAP3")
Cc: Keshava Munegowda <keshava_mgowda@ti.com>
Cc: Partha Basak <parthab@india.ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nishanth Menon [Wed, 12 Mar 2014 21:43:20 +0000 (16:43 -0500)]
ARM: OMAP4: Fix definition of IS_PM44XX_ERRATUM
commit
07484ca33ef83900f5cfbde075c1a19e5a237aa1 upstream.
Just like IS_PM34XX_ERRATUM, IS_PM44XX_ERRATUM is valid only if
CONFIG_PM is enabled, else, disabling CONFIG_PM results in build
failure complaining about the following:
arch/arm/mach-omap2/built-in.o: In function `omap4_boot_secondary':
:(.text+0x8a70): undefined reference to `pm44xx_errata'
Fixes: c962184 (ARM: OMAP4: PM: add errata support)
Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.ocm>
Acked-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Vaussard [Wed, 26 Feb 2014 10:38:08 +0000 (11:38 +0100)]
CLK: TI: OMAP4/5/DRA7: Remove gpmc_fck from dummy clocks
commit
8559087f0e9722a95df43fa5968bd1ee42bcf540 upstream.
When arch/arm/mach-omap2/gpmc.c calls clk_get(..., "fck"), it will
get a dummy clock and try to use it. As the rate is configured to zero,
this will result in several divisions by zero, and misconfigured
timings, with devices on the bus being lost in the La La Land.
It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
can fail gracefully.
Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Suman Anna [Fri, 14 Mar 2014 09:15:17 +0000 (14:45 +0530)]
ARM: OMAP2+: hwmod: fix missing braces in _init()
commit
3d36ad7e7a9be0d130c862727a052ed279046437 upstream.
Bug was introduced by commit 'f92d959: ARM: OMAP2+: hwmod:
Extract no-idle and no-reset info from DT'
There were 2 versions of the patch posted which resulted in the above
commit. While v1 [1] had the bug, v2 [2] had it fixed.
However v1 apparently seemed to have been pulled in by mistake
introducing the bug.
Given of_find_property() does return NULL when the node passed is
NULL, it did not introduce any functional issues as such, just the
fact that the second if check was executed unnecessarily.
[1] https://www.mail-archive.com/linux-omap@vger.kernel.org/msg94220.html
[2] http://www.spinics.net/lists/linux-omap/msg98490.html
Cc: Nishanth Menon <nm@ti.com>
Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Fixes:
f92d9597f781f6a5a39c73dc71604bd8a21c5299 ("ARM: OMAP2+: hwmod: Extract no-idle and no-reset info from DT")
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Sørensen [Thu, 6 Mar 2014 15:27:15 +0000 (16:27 +0100)]
ARM: OMAP2+: INTC: Acknowledge stuck active interrupts
commit
698b48532539484b012fb7c4176b959d32a17d00 upstream.
When an interrupt has become active on the INTC it will stay active
until it is acked, even if masked or de-asserted. The
INTC_PENDING_IRQn registers are however updated and since these are
used by omap_intc_handle_irq to determine which interrupt to handle,
it will never see the active interrupt. This will result in a storm of
useless interrupts that is only stopped when another higher priority
interrupt is asserted.
Fix by sending the INTC an acknowledge if we find no interrupts to
handle.
Signed-off-by: Stefan Sørensen <stefan.sorensen@spectralink.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Austin [Tue, 18 Mar 2014 18:56:21 +0000 (13:56 -0500)]
ASoC: cs42l73: Fix mask bits for SOC_VALUE_ENUM_SINGLE
commit
1555b652970e541fa1cb80c61ffc696bbfb92bb7 upstream.
The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the mono mix controls.
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Austin [Tue, 18 Mar 2014 19:01:47 +0000 (14:01 -0500)]
ASoC: cs42l52: Fix mask bits for SOC_VALUE_ENUM_SINGLE
commit
d31a33dd7792c7d6c11fda226a3b9e4fb7f86f95 upstream.
The mask bits values were wrong for the SOC_VALUE_ENUM_SINGLE for the PCM/ADC Swap controls
Reported-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Austin [Wed, 19 Mar 2014 15:40:02 +0000 (10:40 -0500)]
ASoC: cs42l51: Fix SOC_DOUBLE_R_SX_TLV shift values for ADC, PCM, and Analog kcontrols
commit
7272e051157ccd5871b5d939548d0ba5a94a2965 upstream.
The shift values for the ADC,PCM, and Analog kcontrols were wrong causing wrong values for the SOC_DOUBLE_R_SX_TLV macros
Fixed the TLV for aout_tlv to show -102dB correctly
Fixes:
1d99f2436d (ASoC: core: Rework SOC_DOUBLE_R_SX_TLV add SOC_SINGLE_SX_TLV)
Reported-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Brian Austin <brian.austin@cirrus.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Brown [Sat, 22 Mar 2014 18:29:15 +0000 (18:29 +0000)]
ASoC: pcm: Drop incorrect double/extra frees
commit
017d9491ce203c620ad1377f46a3ce78d554b2de upstream.
The changes in "ASoC: pcm: free path list before exiting from error
conditions" actually introduced both double frees (in case where the
path list was allocated but empty) and frees of unallocated memory (in
cases where the error being handled was -ENOMEM. Drop the commit for
now.
Fixes:
e4ad1accb (ASoC: pcm: free path list before exiting from error conditions)
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Wed, 12 Mar 2014 16:07:06 +0000 (16:07 +0000)]
arm64: Make DMA coherent and strongly ordered mappings not executable
commit
de2db7432917a82b62d55bb59635586eeca6d1bd upstream.
pgprot_{dmacoherent,writecombine,noncached} don't need to generate
executable mappings with side-effects like __sync_icache_dcache() being
called when the mapping is in user space.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
Tested-by: Laura Abbott <lauraa@codeaurora.org>
Tested-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Wed, 12 Mar 2014 16:28:09 +0000 (16:28 +0000)]
arm64: Do not synchronise I and D caches for special ptes
commit
71fdb6bf61bf0692f004f9daf5650392c0cfe300 upstream.
Special pte mappings are not intended to be executable and do not even
have an associated struct page. This patch ensures that we do not call
__sync_icache_dcache() on such ptes.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Steve Capper <Steve.Capper@arm.com>
Tested-by: Laura Abbott <lauraa@codeaurora.org>
Tested-by: Bharat Bhushan <Bharat.Bhushan@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Sun, 27 Apr 2014 00:19:26 +0000 (17:19 -0700)]
Linux 3.14.2
Oleg Nesterov [Mon, 7 Apr 2014 22:38:29 +0000 (15:38 -0700)]
exit: call disassociate_ctty() before exit_task_namespaces()
commit
c39df5fa37b0623589508c95515b4aa1531c524e upstream.
Commit
8aac62706ada ("move exit_task_namespaces() outside of
exit_notify()") breaks pppd and the exiting service crashes the kernel:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000028
IP: ppp_register_channel+0x13/0x20 [ppp_generic]
Call Trace:
ppp_asynctty_open+0x12b/0x170 [ppp_async]
tty_ldisc_open.isra.2+0x27/0x60
tty_ldisc_hangup+0x1e3/0x220
__tty_hangup+0x2c4/0x440
disassociate_ctty+0x61/0x270
do_exit+0x7f2/0xa50
ppp_register_channel() needs ->net_ns and current->nsproxy == NULL.
Move disassociate_ctty() before exit_task_namespaces(), it doesn't make
sense to delay it after perf_event_exit_task() or cgroup_exit().
This also allows to use task_work_add() inside the (nontrivial) code
paths in disassociate_ctty().
Investigated by Peter Hurley.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Sree Harsha Totakura <sreeharsha@totakura.in>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Sree Harsha Totakura <sreeharsha@totakura.in>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andrey Vagin <avagin@openvz.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Mon, 7 Apr 2014 22:38:41 +0000 (15:38 -0700)]
wait: fix reparent_leader() vs EXIT_DEAD->EXIT_ZOMBIE race
commit
dfccbb5e49a621c1b21a62527d61fc4305617aca upstream.
wait_task_zombie() first does EXIT_ZOMBIE->EXIT_DEAD transition and
drops tasklist_lock. If this task is not the natural child and it is
traced, we change its state back to EXIT_ZOMBIE for ->real_parent.
The last transition is racy, this is even documented in
50b8d257486a
"ptrace: partially fix the do_wait(WEXITED) vs EXIT_DEAD->EXIT_ZOMBIE
race". wait_consider_task() tries to detect this transition and clear
->notask_error but we can't rely on ptrace_reparented(), debugger can
exit and do ptrace_unlink() before its sub-thread sets EXIT_ZOMBIE.
And there is another problem which were missed before: this transition
can also race with reparent_leader() which doesn't reset >exit_signal if
EXIT_DEAD, assuming that this task must be reaped by someone else. So
the tracee can be re-parented with ->exit_signal != SIGCHLD, and if
/sbin/init doesn't use __WALL it becomes unreapable.
Change reparent_leader() to update ->exit_signal even if EXIT_DEAD.
Note: this is the simple temporary hack for -stable, it doesn't try to
solve all problems, it will be reverted by the next changes.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Reported-by: Jan Kratochvil <jan.kratochvil@redhat.com>
Reported-by: Michal Schmidt <mschmidt@redhat.com>
Tested-by: Michal Schmidt <mschmidt@redhat.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Lennart Poettering <lpoetter@redhat.com>
Cc: Roland McGrath <roland@hack.frob.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Zefan [Wed, 12 Feb 2014 20:44:57 +0000 (12:44 -0800)]
jffs2: remove from wait queue after schedule()
commit
3ead9578443b66ddb3d50ed4f53af8a0c0298ec5 upstream.
@wait is a local variable, so if we don't remove it from the wait queue
list, later wake_up() may end up accessing invalid memory.
This was spotted by eyes.
Signed-off-by: Li Zefan <lizefan@huawei.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Zefan [Wed, 12 Feb 2014 20:44:56 +0000 (12:44 -0800)]
jffs2: avoid soft-lockup in jffs2_reserve_space_gc()
commit
13b546d96207c131eeae15dc7b26c6e7d0f1cad7 upstream.
We triggered soft-lockup under stress test on 2.6.34 kernel.
BUG: soft lockup - CPU#1 stuck for 60009ms! [lockf2.test:14488]
...
[<
bf09a4d4>] (jffs2_do_reserve_space+0x420/0x440 [jffs2])
[<
bf09a528>] (jffs2_reserve_space_gc+0x34/0x78 [jffs2])
[<
bf0a1350>] (jffs2_garbage_collect_dnode.isra.3+0x264/0x478 [jffs2])
[<
bf0a2078>] (jffs2_garbage_collect_pass+0x9c0/0xe4c [jffs2])
[<
bf09a670>] (jffs2_reserve_space+0x104/0x2a8 [jffs2])
[<
bf09dc48>] (jffs2_write_inode_range+0x5c/0x4d4 [jffs2])
[<
bf097d8c>] (jffs2_write_end+0x198/0x2c0 [jffs2])
[<
c00e00a4>] (generic_file_buffered_write+0x158/0x200)
[<
c00e14f4>] (__generic_file_aio_write+0x3a4/0x414)
[<
c00e15c0>] (generic_file_aio_write+0x5c/0xbc)
[<
c012334c>] (do_sync_write+0x98/0xd4)
[<
c0123a84>] (vfs_write+0xa8/0x150)
[<
c0123d74>] (sys_write+0x3c/0xc0)]
Fix this by adding a cond_resched() in the while loop.
[akpm@linux-foundation.org: don't initialize `ret']
Signed-off-by: Li Zefan <lizefan@huawei.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ajesh Kunhipurayil Vijayan [Mon, 6 Jan 2014 13:36:55 +0000 (19:06 +0530)]
jffs2: Fix crash due to truncation of csize
commit
41bf1a24c1001f4d0d41a78e1ac575d2f14789d7 upstream.
mounting JFFS2 partition sometimes crashes with this call trace:
[ 1322.240000] Kernel bug detected[#1]:
[ 1322.244000] Cpu 2
[ 1322.244000] $ 0 :
0000000000000000 0000000000000018 000000003ff00070 0000000000000001
[ 1322.252000] $ 4 :
0000000000000000 c0000000f3980150 0000000000000000 0000000000010000
[ 1322.260000] $ 8 :
ffffffffc09cd5f8 0000000000000001 0000000000000088 c0000000ed300de8
[ 1322.268000] $12 :
e5e19d9c5f613a45 ffffffffc046d464 0000000000000000 66227ba5ea67b74e
[ 1322.276000] $16 :
c0000000f1769c00 c0000000ed1e0200 c0000000f3980150 0000000000000000
[ 1322.284000] $20 :
c0000000f3a80000 00000000fffffffc c0000000ed2cfbd8 c0000000f39818f0
[ 1322.292000] $24 :
0000000000000004 0000000000000000
[ 1322.300000] $28 :
c0000000ed2c0000 c0000000ed2cfab8 0000000000010000 ffffffffc039c0b0
[ 1322.308000] Hi :
000000000000023c
[ 1322.312000] Lo :
000000000003f802
[ 1322.316000] epc :
ffffffffc039a9f8 check_tn_node+0x88/0x3b0
[ 1322.320000] Not tainted
[ 1322.324000] ra :
ffffffffc039c0b0 jffs2_do_read_inode_internal+0x1250/0x1e48
[ 1322.332000] Status:
5400f8e3 KX SX UX KERNEL EXL IE
[ 1322.336000] Cause :
00800034
[ 1322.340000] PrId :
000c1004 (Netlogic XLP)
[ 1322.344000] Modules linked in:
[ 1322.348000] Process jffs2_gcd_mtd7 (pid: 264, threadinfo=
c0000000ed2c0000, task=
c0000000f0e68dd8, tls=
0000000000000000)
[ 1322.356000] Stack :
c0000000f1769e30 c0000000ed010780 c0000000ed010780 c0000000ed300000
c0000000f1769c00 c0000000f3980150 c0000000f3a80000 00000000fffffffc
c0000000ed2cfbd8 ffffffffc039c0b0 ffffffffc09c6340 0000000000001000
0000000000000dec ffffffffc016c9d8 c0000000f39805a0 c0000000f3980180
0000008600000000 0000000000000000 0000000000000000 0000000000000000
0001000000000dec c0000000f1769d98 c0000000ed2cfb18 0000000000010000
0000000000010000 0000000000000044 c0000000f3a80000 c0000000f1769c00
c0000000f3d207a8 c0000000f1769d98 c0000000f1769de0 ffffffffc076f9c0
0000000000000009 0000000000000000 0000000000000000 ffffffffc039cf90
0000000000000017 ffffffffc013fbdc 0000000000000001 000000010003e61c
...
[ 1322.424000] Call Trace:
[ 1322.428000] [<
ffffffffc039a9f8>] check_tn_node+0x88/0x3b0
[ 1322.432000] [<
ffffffffc039c0b0>] jffs2_do_read_inode_internal+0x1250/0x1e48
[ 1322.440000] [<
ffffffffc039cf90>] jffs2_do_crccheck_inode+0x70/0xd0
[ 1322.448000] [<
ffffffffc03a1b80>] jffs2_garbage_collect_pass+0x160/0x870
[ 1322.452000] [<
ffffffffc03a392c>] jffs2_garbage_collect_thread+0xdc/0x1f0
[ 1322.460000] [<
ffffffffc01541c8>] kthread+0xb8/0xc0
[ 1322.464000] [<
ffffffffc0106d18>] kernel_thread_helper+0x10/0x18
[ 1322.472000]
[ 1322.472000]
Code:
67bd0050 94a4002c 2c830001 <
00038036>
de050218 2403fffc 0080a82d 00431824 24630044
[ 1322.480000] ---[ end trace
b052bb90e97dfbf5 ]---
The variable csize in structure jffs2_tmp_dnode_info is of type uint16_t, but it
is used to hold the compressed data length(csize) which is declared as uint32_t.
So, when the value of csize exceeds 16bits, it gets truncated when assigned to
tn->csize. This is causing a kernel BUG.
Changing the definition of csize in jffs2_tmp_dnode_info to uint32_t fixes the issue.
Signed-off-by: Ajesh Kunhipurayil Vijayan <ajesh@broadcom.com>
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kamlakant Patel [Mon, 6 Jan 2014 13:36:54 +0000 (19:06 +0530)]
jffs2: Fix segmentation fault found in stress test
commit
3367da5610c50e6b83f86d366d72b41b350b06a2 upstream.
Creating a large file on a JFFS2 partition sometimes crashes with this call
trace:
[ 306.476000] CPU 13 Unable to handle kernel paging request at virtual address
c0000000dfff8002, epc ==
ffffffffc03a80a8, ra ==
ffffffffc03a8044
[ 306.488000] Oops[#1]:
[ 306.488000] Cpu 13
[ 306.492000] $ 0 :
0000000000000000 0000000000000000 0000000000008008 0000000000008007
[ 306.500000] $ 4 :
c0000000dfff8002 000000000000009f c0000000e0007cde c0000000ee95fa58
[ 306.508000] $ 8 :
0000000000000001 0000000000008008 0000000000010000 ffffffffffff8002
[ 306.516000] $12 :
0000000000007fa9 000000000000ff0e 000000000000ff0f 80e55930aebb92bb
[ 306.524000] $16 :
c0000000e0000000 c0000000ee95fa5c c0000000efc80000 ffffffffc09edd70
[ 306.532000] $20 :
ffffffffc2b60000 c0000000ee95fa58 0000000000000000 c0000000efc80000
[ 306.540000] $24 :
0000000000000000 0000000000000004
[ 306.548000] $28 :
c0000000ee950000 c0000000ee95f738 0000000000000000 ffffffffc03a8044
[ 306.556000] Hi :
00000000000574a5
[ 306.560000] Lo :
6193b7a7e903d8c9
[ 306.564000] epc :
ffffffffc03a80a8 jffs2_rtime_compress+0x98/0x198
[ 306.568000] Tainted: G W
[ 306.572000] ra :
ffffffffc03a8044 jffs2_rtime_compress+0x34/0x198
[ 306.580000] Status:
5000f8e3 KX SX UX KERNEL EXL IE
[ 306.584000] Cause :
00800008
[ 306.588000] BadVA :
c0000000dfff8002
[ 306.592000] PrId :
000c1100 (Netlogic XLP)
[ 306.596000] Modules linked in:
[ 306.596000] Process dd (pid: 170, threadinfo=
c0000000ee950000, task=
c0000000ee6e0858, tls=
0000000000c47490)
[ 306.608000] Stack :
7c547f377ddc7ee4 7ffc7f967f5d7fae 7f617f507fc37ff4 7e7d7f817f487f5f
7d8e7fec7ee87eb3 7e977ff27eec7f9e 7d677ec67f917f67 7f3d7e457f017ed7
7fd37f517f867eb2 7fed7fd17ca57e1d 7e5f7fe87f257f77 7fd77f0d7ede7fdb
7fba7fef7e197f99 7fde7fe07ee37eb5 7f5c7f8c7fc67f65 7f457fb87f847e93
7f737f3e7d137cd9 7f8e7e9c7fc47d25 7dbb7fac7fb67e52 7ff17f627da97f64
7f6b7df77ffa7ec5 80057ef17f357fb3 7f767fa27dfc7fd5 7fe37e8e7fd07e53
7e227fcf7efb7fa1 7f547e787fa87fcc 7fcb7fc57f5a7ffb 7fc07f6c7ea97e80
7e2d7ed17e587ee0 7fb17f9d7feb7f31 7f607e797e887faa 7f757fdd7c607ff3
7e877e657ef37fbd 7ec17fd67fe67ff7 7ff67f797ff87dc4 7eef7f3a7c337fa6
7fe57fc97ed87f4b 7ebe7f097f0b8003 7fe97e2a7d997cba 7f587f987f3c7fa9
...
[ 306.676000] Call Trace:
[ 306.680000] [<
ffffffffc03a80a8>] jffs2_rtime_compress+0x98/0x198
[ 306.684000] [<
ffffffffc0394f10>] jffs2_selected_compress+0x110/0x230
[ 306.692000] [<
ffffffffc039508c>] jffs2_compress+0x5c/0x388
[ 306.696000] [<
ffffffffc039dc58>] jffs2_write_inode_range+0xd8/0x388
[ 306.704000] [<
ffffffffc03971bc>] jffs2_write_end+0x16c/0x2d0
[ 306.708000] [<
ffffffffc01d3d90>] generic_file_buffered_write+0xf8/0x2b8
[ 306.716000] [<
ffffffffc01d4e7c>] __generic_file_aio_write+0x1ac/0x350
[ 306.720000] [<
ffffffffc01d50a0>] generic_file_aio_write+0x80/0x168
[ 306.728000] [<
ffffffffc021f7dc>] do_sync_write+0x94/0xf8
[ 306.732000] [<
ffffffffc021ff6c>] vfs_write+0xa4/0x1a0
[ 306.736000] [<
ffffffffc02202e8>] SyS_write+0x50/0x90
[ 306.744000] [<
ffffffffc0116cc0>] handle_sys+0x180/0x1a0
[ 306.748000]
[ 306.748000]
Code:
020b202d 0205282d 90a50000 <
90840000>
14a40038 00000000 0060602d 0000282d 016c5823
[ 306.760000] ---[ end trace
79dd088435be02d0 ]---
Segmentation fault
This crash is caused because the 'positions' is declared as an array of signed
short. The value of position is in the range 0..65535, and will be converted
to a negative number when the position is greater than 32767 and causes a
corruption and crash. Changing the definition to 'unsigned short' fixes this
issue
Signed-off-by: Jayachandran C <jchandra@broadcom.com>
Signed-off-by: Kamlakant Patel <kamlakant.patel@broadcom.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 14 Feb 2014 09:05:49 +0000 (12:05 +0300)]
fs: NULL dereference in posix_acl_to_xattr()
commit
47ba9734403770a4c5e685b01f0a72b835dd4fff upstream.
This patch moves the dereference of "buffer" after the check for NULL.
The only place which passes a NULL parameter is gfs2_set_acl().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Whitney [Tue, 1 Apr 2014 23:49:30 +0000 (19:49 -0400)]
ext4: fix premature freeing of partial clusters split across leaf blocks
commit
ad6599ab3ac98a4474544086e048ce86ec15a4d1 upstream.
Xfstests generic/311 and shared/298 fail when run on a bigalloc file
system. Kernel error messages produced during the tests report that
blocks to be freed are already on the to-be-freed list. When e2fsck
is run at the end of the tests, it typically reports bad i_blocks and
bad free blocks counts.
The bug that causes these failures is located in ext4_ext_rm_leaf().
Code at the end of the function frees a partial cluster if it's not
shared with an extent remaining in the leaf. However, if all the
extents in the leaf have been removed, the code dereferences an
invalid extent pointer (off the front of the leaf) when the check for
sharing is made. This generally has the effect of unconditionally
freeing the partial cluster, which leads to the observed failures
when the partial cluster is shared with the last extent in the next
leaf.
Fix this by attempting to free the cluster only if extents remain in
the leaf. Any remaining partial cluster will be freed if possible
when the next leaf is processed or when leaf removal is complete.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Whitney [Fri, 14 Mar 2014 03:34:16 +0000 (23:34 -0400)]
ext4: fix partial cluster handling for bigalloc file systems
commit
c06344939422bbd032ac967223a7863de57496b5 upstream.
Commit
9cb00419fa, which enables hole punching for bigalloc file
systems, exposed a bug introduced by commit
6ae06ff51e in an earlier
release. When run on a bigalloc file system, xfstests generic/013, 068,
075, 083, 091, 100, 112, 127, 263, 269, and 270 fail with e2fsck errors
or cause kernel error messages indicating that previously freed blocks
are being freed again.
The latter commit optimizes the selection of the starting extent in
ext4_ext_rm_leaf() when hole punching by beginning with the extent
supplied in the path argument rather than with the last extent in the
leaf node (as is still done when truncating). However, the code in
rm_leaf that initially sets partial_cluster to track cluster sharing on
extent boundaries is only guaranteed to run if rm_leaf starts with the
last node in the leaf. Consequently, partial_cluster is not correctly
initialized when hole punching, and a cluster on the boundary of a
punched region that should be retained may instead be deallocated.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Whitney [Wed, 19 Feb 2014 23:52:39 +0000 (18:52 -0500)]
ext4: fix error return from ext4_ext_handle_uninitialized_extents()
commit
ce37c42919608e96ade3748fe23c3062a0a966c5 upstream.
Commit
3779473246 breaks the return of error codes from
ext4_ext_handle_uninitialized_extents() in ext4_ext_map_blocks(). A
portion of the patch assigns that function's signed integer return
value to an unsigned int. Consequently, negatively valued error codes
are lost and can be treated as a bogus allocated block count.
Signed-off-by: Eric Whitney <enwlinux@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Thu, 27 Mar 2014 23:41:34 +0000 (19:41 -0400)]
Btrfs: check for an extent_op on the locked ref
commit
573a075567f0174551e2fad2a3164afd2af788f2 upstream.
We could have possibly added an extent_op to the locked_ref while we dropped
locked_ref->lock, so check for this case as well and loop around. Otherwise we
could lose flag updates which would lead to extent tree corruption. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Josef Bacik [Fri, 7 Mar 2014 00:01:07 +0000 (19:01 -0500)]
Btrfs: fix deadlock with nested trans handles
commit
3bbb24b20a8800158c33eca8564f432dd14d0bf3 upstream.
Zach found this deadlock that would happen like this
btrfs_end_transaction <- reduce trans->use_count to 0
btrfs_run_delayed_refs
btrfs_cow_block
find_free_extent
btrfs_start_transaction <- increase trans->use_count to 1
allocate chunk
btrfs_end_transaction <- decrease trans->use_count to 0
btrfs_run_delayed_refs
lock tree block we are cowing above ^^
We need to only decrease trans->use_count if it is above 1, otherwise leave it
alone. This will make nested trans be the only ones who decrease their added
ref, and will let us get rid of the trans->use_count++ hack if we have to commit
the transaction. Thanks,
Reported-by: Zach Brown <zab@redhat.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Tested-by: Zach Brown <zab@redhat.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hidetoshi Seto [Wed, 5 Feb 2014 07:34:38 +0000 (16:34 +0900)]
Btrfs: skip submitting barrier for missing device
commit
f88ba6a2a44ee98e8d59654463dc157bb6d13c43 upstream.
I got an error on v3.13:
BTRFS error (device sdf1) in write_all_supers:3378: errno=-5 IO failure (errors while submitting device barriers.)
how to reproduce:
> mkfs.btrfs -f -d raid1 /dev/sdf1 /dev/sdf2
> wipefs -a /dev/sdf2
> mount -o degraded /dev/sdf1 /mnt
> btrfs balance start -f -sconvert=single -mconvert=single -dconvert=single /mnt
The reason of the error is that barrier_all_devices() failed to submit
barrier to the missing device. However it is clear that we cannot do
anything on missing device, and also it is not necessary to care chunks
on the missing device.
This patch stops sending/waiting barrier if device is missing.
Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Tinguely [Thu, 3 Apr 2014 20:10:49 +0000 (07:10 +1100)]
xfs: fix directory hash ordering bug
commit
c88547a8119e3b581318ab65e9b72f27f23e641d upstream.
Commit
f5ea1100 ("xfs: add CRCs to dir2/da node blocks") introduced
in 3.10 incorrectly converted the btree hash index array pointer in
xfs_da3_fixhashpath(). It resulted in the the current hash always
being compared against the first entry in the btree rather than the
current block index into the btree block's hash entry array. As a
result, it was comparing the wrong hashes, and so could misorder the
entries in the btree.
For most cases, this doesn't cause any problems as it requires hash
collisions to expose the ordering problem. However, when there are
hash collisions within a directory there is a very good probability
that the entries will be ordered incorrectly and that actually
matters when duplicate hashes are placed into or removed from the
btree block hash entry array.
This bug results in an on-disk directory corruption and that results
in directory verifier functions throwing corruption warnings into
the logs. While no data or directory entries are lost, access to
them may be compromised, and attempts to remove entries from a
directory that has suffered from this corruption may result in a
filesystem shutdown. xfs_repair will fix the directory hash
ordering without data loss occuring.
[dchinner: wrote useful a commit message]
Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Mark Tinguely <tinguely@sgi.com>
Reviewed-by: Ben Myers <bpm@sgi.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Thu, 3 Apr 2014 21:46:23 +0000 (14:46 -0700)]
bdi: avoid oops on device removal
commit
5acda9d12dcf1ad0d9a5a2a7c646de3472fa7555 upstream.
After commit
839a8e8660b6 ("writeback: replace custom worker pool
implementation with unbound workqueue") when device is removed while we
are writing to it we crash in bdi_writeback_workfn() ->
set_worker_desc() because bdi->dev is NULL.
This can happen because even though bdi_unregister() cancels all pending
flushing work, nothing really prevents new ones from being queued from
balance_dirty_pages() or other places.
Fix the problem by clearing BDI_registered bit in bdi_unregister() and
checking it before scheduling of any flushing work.
Fixes:
839a8e8660b6777e7fe4e80af1a048aebe2b5977
Reviewed-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Derek Basehore <dbasehore@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Derek Basehore [Thu, 3 Apr 2014 21:46:22 +0000 (14:46 -0700)]
backing_dev: fix hung task on sync
commit
6ca738d60c563d5c6cf6253ee4b8e76fa77b2b9e upstream.
bdi_wakeup_thread_delayed() used the mod_delayed_work() function to
schedule work to writeback dirty inodes. The problem with this is that
it can delay work that is scheduled for immediate execution, such as the
work from sync_inodes_sb(). This can happen since mod_delayed_work()
can now steal work from a work_queue. This fixes the problem by using
queue_delayed_work() instead. This is a regression caused by commit
839a8e8660b6 ("writeback: replace custom worker pool implementation with
unbound workqueue").
The reason that this causes a problem is that laptop-mode will change
the delay, dirty_writeback_centisecs, to 60000 (10 minutes) by default.
In the case that bdi_wakeup_thread_delayed() races with
sync_inodes_sb(), sync will be stopped for 10 minutes and trigger a hung
task. Even if dirty_writeback_centisecs is not long enough to cause a
hung task, we still don't want to delay sync for that long.
We fix the problem by using queue_delayed_work() when we want to
schedule writeback sometime in future. This function doesn't change the
timer if it is already armed.
For the same reason, we also change bdi_writeback_workfn() to
immediately queue the work again in the case that the work_list is not
empty. The same problem can happen if the sync work is run on the
rescue worker.
[jack@suse.cz: update changelog, add comment, use bdi_wakeup_thread_delayed()]
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Alexander Viro <viro@zento.linux.org.uk>
Reviewed-by: Tejun Heo <tj@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Derek Basehore <dbasehore@chromium.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Benson Leung <bleung@chromium.org>
Cc: Sonny Rao <sonnyrao@chromium.org>
Cc: Luigi Semenzato <semenzato@chromium.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Dave Chinner <david@fromorbit.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roberto Sassu [Mon, 3 Feb 2014 12:56:04 +0000 (13:56 +0100)]
ima: restore the original behavior for sending data with ima template
commit
c019e307ad82a8ee652b8ccbacf69ae94263b07b upstream.
With the new template mechanism introduced in IMA since kernel 3.13,
the format of data sent through the binary_runtime_measurements interface
is slightly changed. Now, for a generic measurement, the format of
template data (after the template name) is:
template_len | field1_len | field1 | ... | fieldN_len | fieldN
In addition, fields containing a string now include the '\0' termination
character.
Instead, the format for the 'ima' template should be:
SHA1 digest | event name length | event name
It must be noted that while in the IMA 3.13 code 'event name length' is
'IMA_EVENT_NAME_LEN_MAX + 1' (256 bytes), so that the template digest
is calculated correctly, and 'event name' contains '\0', in the pre 3.13
code 'event name length' is exactly the string length and 'event name'
does not contain the termination character.
The patch restores the behavior of the IMA code pre 3.13 for the 'ima'
template so that legacy userspace tools obtain a consistent behavior
when receiving data from the binary_runtime_measurements interface
regardless of which kernel version is used.
Signed-off-by: Roberto Sassu <roberto.sassu@polito.it>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Claudio Takahasi [Thu, 25 Jul 2013 19:34:24 +0000 (16:34 -0300)]
Bluetooth: Fix removing Long Term Key
commit
5981a8821b774ada0be512fd9bad7c241e17657e upstream.
This patch fixes authentication failure on LE link re-connection when
BlueZ acts as slave (peripheral). LTK is removed from the internal list
after its first use causing PIN or Key missing reply when re-connecting
the link. The LE Long Term Key Request event indicates that the master
is attempting to encrypt or re-encrypt the link.
Pre-condition: BlueZ host paired and running as slave.
How to reproduce(master):
1) Establish an ACL LE encrypted link
2) Disconnect the link
3) Try to re-establish the ACL LE encrypted link (fails)
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Slave (0x01)
...
@ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
> HCI Event: LE Meta Event (0x3e) plen 13
LE Long Term Key Request (0x05)
Handle: 64
Random number:
875be18439d9aa37
Encryption diversifier: 0x76ed
< HCI Command: LE Long Term Key Request Reply (0x08|0x001a) plen 18
Handle: 64
Long term key:
2aa531db2fce9f00a0569c7d23d17409
> HCI Event: Command Complete (0x0e) plen 6
LE Long Term Key Request Reply (0x08|0x001a) ncmd 1
Status: Success (0x00)
Handle: 64
> HCI Event: Encryption Change (0x08) plen 4
Status: Success (0x00)
Handle: 64
Encryption: Enabled with AES-CCM (0x01)
...
@ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 3
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1
Advertising: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4
LE Set Advertise Enable (0x08|0x000a) ncmd 1
Status: Success (0x00)
> HCI Event: LE Meta Event (0x3e) plen 19
LE Connection Complete (0x01)
Status: Success (0x00)
Handle: 64
Role: Slave (0x01)
...
@ Device Connected: 00:02:72:DC:29:C9 (1) flags 0x0000
> HCI Event: LE Meta Event (0x3e) plen 13
LE Long Term Key Request (0x05)
Handle: 64
Random number:
875be18439d9aa37
Encryption diversifier: 0x76ed
< HCI Command: LE Long Term Key Request Neg Reply (0x08|0x001b) plen 2
Handle: 64
> HCI Event: Command Complete (0x0e) plen 6
LE Long Term Key Request Neg Reply (0x08|0x001b) ncmd 1
Status: Success (0x00)
Handle: 64
> HCI Event: Disconnect Complete (0x05) plen 4
Status: Success (0x00)
Handle: 64
Reason: Authentication Failure (0x05)
@ Device Disconnected: 00:02:72:DC:29:C9 (1) reason 0
Signed-off-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleg Nesterov [Wed, 2 Apr 2014 15:45:05 +0000 (17:45 +0200)]
pid_namespace: pidns_get() should check task_active_pid_ns() != NULL
commit
d23082257d83e4bc89727d5aedee197e907999d2 upstream.
pidns_get()->get_pid_ns() can hit ns == NULL. This task_struct can't
go away, but task_active_pid_ns(task) is NULL if release_task(task)
was already called. Alternatively we could change get_pid_ns(ns) to
check ns != NULL, but it seems that other callers are fine.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Eric W. Biederman ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Wed, 15 Jan 2014 20:37:04 +0000 (15:37 -0500)]
SCSI: sd: don't fail if the device doesn't recognize SYNCHRONIZE CACHE
commit
7aae51347b21eb738dc1981df1365b57a6c5ee4e upstream.
Evidently some wacky USB-ATA bridges don't recognize the SYNCHRONIZE
CACHE command, as shown in this email thread:
http://marc.info/?t=
138978356200002&r=1&w=2
The fact that we can't tell them to drain their caches shouldn't
prevent the system from going into suspend. Therefore sd_sync_cache()
shouldn't return an error if the device replies with an Invalid
Command ASC.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Sven Neumann <s.neumann@raumfeld.com>
Tested-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Sat, 22 Feb 2014 12:31:21 +0000 (07:31 -0500)]
tty: Fix low_latency BUG
commit
a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25 upstream.
The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.
Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit
38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.
However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.
Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.
Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.
Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.
[1] https://lkml.org/lkml/2014/2/20/434
"Yay.. thats an annoying historical pain in the butt gone."
-- Alan Cox
Reported-by: Beat Bolli <bbolli@ewanet.ch>
Reported-by: Pavel Roskin <proski@gnu.org>
Acked-by: David Sterba <dsterba@suse.cz>
Cc: Grant Edwards <grant.b.edwards@gmail.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Reinecke [Thu, 27 Feb 2014 11:30:51 +0000 (12:30 +0100)]
tty: Set correct tty name in 'active' sysfs attribute
commit
723abd87f6e536f1353c8f64f621520bc29523a3 upstream.
The 'active' sysfs attribute should refer to the currently active tty
devices the console is running on, not the currently active console. The
console structure doesn't refer to any device in sysfs, only the tty the
console is running on has. So we need to print out the tty names in
'active', not the console names.
There is one special-case, which is tty0. If the console is directed to
it, we want 'tty0' to show up in the file, so user-space knows that the
messages get forwarded to the active VT. The ->device() callback would
resolve tty0, though. Hence, treat it special and don't call into the VT
layer to resolve it (plymouth is known to depend on it).
Cc: Lennart Poettering <lennart@poettering.net>
Cc: Kay Sievers <kay@vrfy.org>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Werner Fink <werner@suse.de>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Wed, 2 Apr 2014 20:40:52 +0000 (16:40 -0400)]
kernfs: protect lazy kernfs_iattrs allocation with mutex
commit
4afddd60a770560d370d6f85c5aef57c16bf7502 upstream.
kernfs_iattrs is allocated lazily when operations which require it
take place; unfortunately, the lazy allocation and returning weren't
properly synchronized and when there are multiple concurrent
operations, it might end up returning kernfs_iattrs which hasn't
finished initialization yet or different copies to different callers.
Fix it by synchronizing with a mutex. This can be smarter with memory
barriers but let's go there if it actually turns out to be necessary.
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/g/533ABA32.9080602@oracle.com
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Cochran [Wed, 5 Mar 2014 16:10:52 +0000 (17:10 +0100)]
kernfs: fix off by one error.
commit
88391d49abb7d8dee91d405f96bd9e003cb6798d upstream.
The hash values 0 and 1 are reserved for magic directory entries, but
the code only prevents names hashing to 0. This patch fixes the test
to also prevent hash value 1.
Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Thu, 10 Apr 2014 18:41:57 +0000 (19:41 +0100)]
staging: comedi: fix circular locking dependency in comedi_mmap()
commit
b34aa86f12e8848ba453215602c8c50fa63c4cb3 upstream.
Mmapping a comedi data buffer with lockdep checking enabled produced the
following kernel debug messages:
======================================================
[ INFO: possible circular locking dependency detected ]
3.5.0-rc3-ija1+ #9 Tainted: G C
-------------------------------------------------------
comedi_test/4160 is trying to acquire lock:
(&dev->mutex#2){+.+.+.}, at: [<
ffffffffa00313f4>] comedi_mmap+0x57/0x1d9 [comedi]
but task is already holding lock:
(&mm->mmap_sem){++++++}, at: [<
ffffffff810c96fe>] vm_mmap_pgoff+0x41/0x76
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&mm->mmap_sem){++++++}:
[<
ffffffff8106d0e8>] lock_acquire+0x97/0x105
[<
ffffffff810ce3bc>] might_fault+0x6d/0x90
[<
ffffffffa0031ffb>] do_devinfo_ioctl.isra.7+0x11e/0x14c [comedi]
[<
ffffffffa003227f>] comedi_unlocked_ioctl+0x256/0xe48 [comedi]
[<
ffffffff810f7fcd>] vfs_ioctl+0x18/0x34
[<
ffffffff810f87fd>] do_vfs_ioctl+0x382/0x43c
[<
ffffffff810f88f9>] sys_ioctl+0x42/0x65
[<
ffffffff81415c62>] system_call_fastpath+0x16/0x1b
-> #0 (&dev->mutex#2){+.+.+.}:
[<
ffffffff8106c528>] __lock_acquire+0x101d/0x1591
[<
ffffffff8106d0e8>] lock_acquire+0x97/0x105
[<
ffffffff8140c894>] mutex_lock_nested+0x46/0x2a4
[<
ffffffffa00313f4>] comedi_mmap+0x57/0x1d9 [comedi]
[<
ffffffff810d5816>] mmap_region+0x281/0x492
[<
ffffffff810d5c92>] do_mmap_pgoff+0x26b/0x2a7
[<
ffffffff810c971a>] vm_mmap_pgoff+0x5d/0x76
[<
ffffffff810d493f>] sys_mmap_pgoff+0xc7/0x10d
[<
ffffffff81004d36>] sys_mmap+0x16/0x20
[<
ffffffff81415c62>] system_call_fastpath+0x16/0x1b
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&mm->mmap_sem);
lock(&dev->mutex#2);
lock(&mm->mmap_sem);
lock(&dev->mutex#2);
*** DEADLOCK ***
To avoid the circular dependency, just try to get the lock in
`comedi_mmap()` instead of blocking. Since the comedi device's main mutex
is heavily used, do a down-read of its `attach_lock` rwsemaphore
instead. Trying to down-read `attach_lock` should only fail if
some task has down-write locked it, and that is only done while the
comedi device is being attached to or detached from a low-level hardware
device.
Unfortunately, acquiring the `attach_lock` doesn't prevent another
task replacing the comedi data buffer we are trying to mmap. The
details of the buffer are held in a `struct comedi_buf_map` and pointed
to by `s->async->buf_map` where `s` is the comedi subdevice whose buffer
we are trying to map. The `struct comedi_buf_map` is already reference
counted with a `struct kref`, so we can stop it being freed prematurely.
Modify `comedi_mmap()` to call new function
`comedi_buf_map_from_subdev_get()` to read the subdevice's current
buffer map pointer and increment its reference instead of accessing
`async->buf_map` directly. Call `comedi_buf_map_put()` to decrement the
reference once the buffer map structure has been dealt with. (Note that
`comedi_buf_map_put()` does nothing if passed a NULL pointer.)
`comedi_buf_map_from_subdev_get()` checks the subdevice's buffer map
pointer has been set and the buffer map has been initialized enough for
`comedi_mmap()` to deal with it (specifically, check the `n_pages`
member has been set to a non-zero value). If all is well, the buffer
map's reference is incremented and a pointer to it is returned. The
comedi subdevice's spin-lock is used to protect the checks. Also use
the spin-lock in `__comedi_buf_alloc()` and `__comedi_buf_free()` to
protect changes to the subdevice's buffer map structure pointer and the
buffer map structure's `n_pages` member. (This checking of `n_pages` is
a bit clunky and I [Ian Abbott] plan to deal with it in the future.)
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Abbott [Thu, 13 Mar 2014 15:30:39 +0000 (15:30 +0000)]
staging: comedi: 8255_pci: initialize MITE data window
commit
268d1e799663b795cba15c64f5d29407786a9dd4 upstream.
According to National Instruments' PCI-DIO-96/PXI-6508/PCI-6503 User
Manual, the physical address in PCI BAR1 needs to be OR'ed with 0x80 and
written to register offset 0xC0 in the "MITE" registers (BAR0). Do so
during initialization of the National Instruments boards handled by the
"8255_pci" driver. The boards were previously handled by the
"ni_pcidio" driver, where the initialization was done by `mite_setup()`
in the "mite" module. The "mite" module comes with too much extra
baggage for the "8255_pci" driver to deal with so use a local, simpler
initialization function.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lan Tianyu [Sat, 15 Mar 2014 17:37:13 +0000 (13:37 -0400)]
ACPI / button: Add ACPI Button event via netlink routine
commit
0bf6368ee8f25826d0645c0f7a4f17c8845356a4 upstream.
Commit 1696d9d (ACPI: Remove the old /proc/acpi/event interface)
removed ACPI Button event which originally was sent to userspace via
/proc/acpi/event. This caused ACPI shutdown regression on gentoo
in VirtualBox. Now ACPI events are sent to userspace via netlink,
so add ACPI Button event back via netlink routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=71721
Reported-and-tested-by: Richard Musil <richard.musil@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohit Kumar [Wed, 16 Apr 2014 16:23:34 +0000 (10:23 -0600)]
PCI: designware: Fix iATU programming for cfg1, io and mem viewport
commit
017fcdc30cdae18c0946eef1ece1f14b4c7897ba upstream.
This patch corrects iATU programming for cfg1, io and mem viewport. Enable
ATU only after configuring it.
Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Ajay Khandelwal <ajay.khandelwal@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohit Kumar [Wed, 19 Feb 2014 12:04:35 +0000 (17:34 +0530)]
PCI: designware: Fix RC BAR to be single 64-bit non-prefetchable memory BAR
commit
dbffdd6862e67d60703f2df66c558bf448f81d6e upstream.
The Synopsys PCIe core provides one pair of 32-bit BARs (BAR 0 and BAR 1).
The BARs can be configured as follows:
- One 64-bit BAR: BARs 0 and 1 are combined to form a single 64-bit BAR
- Two 32-bit BARs: BARs 0 and 1 are two independent 32-bit BARs
This patch corrects 64-bit, non-prefetchable memory BAR configuration
implemented in dw driver.
Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Pratyush Anand <pratyush.anand@st.com>
Cc: Jingoo Han <jg1.han@samsung.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Horman [Wed, 12 Mar 2014 18:44:33 +0000 (14:44 -0400)]
x86: Adjust irq remapping quirk for older revisions of 5500/5520 chipsets
commit
6f8a1b335fde143b7407036e2368d3cd6eb55674 upstream.
Commit
03bbcb2e7e2 (iommu/vt-d: add quirk for broken interrupt
remapping on 55XX chipsets) properly disables irq remapping on the
5500/5520 chipsets that don't correctly perform that feature.
However, when I wrote it, I followed the errata sheet linked in that
commit too closely, and explicitly tied the activation of the quirk to
revision 0x13 of the chip, under the assumption that earlier revisions
were not in the field. Recently a system was reported to be suffering
from this remap bug and the quirk hadn't triggered, because the
revision id register read at a lower value that 0x13, so the quirk
test failed improperly. Given this, it seems only prudent to adjust
this quirk so that any revision less than 0x13 has the quirk asserted.
[ tglx: Removed the 0x12 comparison of pci id 3405 as this is covered
by the <= 0x13 check already ]
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org
Link: http://lkml.kernel.org/r/1394649873-14913-1-git-send-email-nhorman@tuxdriver.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Wang [Fri, 28 Feb 2014 03:30:29 +0000 (11:30 +0800)]
x86, hyperv: Bypass the timer_irq_works() check
commit
ca3ba2a2f4a49a308e7d78c784d51b2332064f15 upstream.
This patch bypass the timer_irq_works() check for hyperv guest since:
- It was guaranteed to work.
- timer_irq_works() may fail sometime due to the lpj calibration were inaccurate
in a hyperv guest or a buggy host.
In the future, we should get the tsc frequency from hypervisor and use preset
lpj instead.
[ hpa: I would prefer to not defer things to "the future" in the future... ]
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Acked-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Link: http://lkml.kernel.org/r/1393558229-14755-1-git-send-email-jasowang@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Slaby [Mon, 14 Apr 2014 14:46:50 +0000 (09:46 -0500)]
Char: ipmi_bt_sm, fix infinite loop
commit
a94cdd1f4d30f12904ab528152731fb13a812a16 upstream.
In read_all_bytes, we do
unsigned char i;
...
bt->read_data[0] = BMC2HOST;
bt->read_count = bt->read_data[0];
...
for (i = 1; i <= bt->read_count; i++)
bt->read_data[i] = BMC2HOST;
If bt->read_data[0] == bt->read_count == 255, we loop infinitely in the
'for' loop. Make 'i' an 'int' instead of 'char' to get rid of the
overflow and finish the loop after 255 iterations every time.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-debugged-by: Rui Hui Dian <rhdian@novell.com>
Cc: Tomas Cech <tcech@suse.cz>
Cc: Corey Minyard <minyard@acm.org>
Cc: <openipmi-developer@lists.sourceforge.net>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mikulas Patocka [Mon, 14 Apr 2014 20:58:55 +0000 (16:58 -0400)]
user namespace: fix incorrect memory barriers
commit
e79323bd87808fdfbc68ce6c5371bd224d9672ee upstream.
smp_read_barrier_depends() can be used if there is data dependency between
the readers - i.e. if the read operation after the barrier uses address
that was obtained from the read operation before the barrier.
In this file, there is only control dependency, no data dependecy, so the
use of smp_read_barrier_depends() is incorrect. The code could fail in the
following way:
* the cpu predicts that idx < entries is true and starts executing the
body of the for loop
* the cpu fetches map->extent[0].first and map->extent[0].count
* the cpu fetches map->nr_extents
* the cpu verifies that idx < extents is true, so it commits the
instructions in the body of the for loop
The problem is that in this scenario, the cpu read map->extent[0].first
and map->nr_extents in the wrong order. We need a full read memory barrier
to prevent it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 14 Apr 2014 13:50:10 +0000 (06:50 -0700)]
Linux 3.14.1
Ard Biesheuvel [Thu, 27 Mar 2014 17:14:40 +0000 (18:14 +0100)]
crypto: ghash-clmulni-intel - use C implementation for setkey()
commit
8ceee72808d1ae3fb191284afc2257a2be964725 upstream.
The GHASH setkey() function uses SSE registers but fails to call
kernel_fpu_begin()/kernel_fpu_end(). Instead of adding these calls, and
then having to deal with the restriction that they cannot be called from
interrupt context, move the setkey() implementation to the C domain.
Note that setkey() does not use any particular SSE features and is not
expected to become a performance bottleneck.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: H. Peter Anvin <hpa@linux.intel.com>
Fixes:
0e1227d356e9b (crypto: ghash - Add PCLMULQDQ accelerated implementation)
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Finn Thain [Wed, 5 Mar 2014 23:29:27 +0000 (10:29 +1100)]
m68k: Skip futex_atomic_cmpxchg_inatomic() test
commit
e571c58f313d35c56e0018470e3375ddd1fd320e upstream.
Skip the futex_atomic_cmpxchg_inatomic() test in futex_init(). It causes a
fatal exception on 68030 (and presumably 68020 also).
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Link: http://lkml.kernel.org/r/alpine.LNX.2.00.1403061006440.5525@nippy.intranet
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Sun, 2 Mar 2014 12:09:47 +0000 (13:09 +0100)]
futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test
commit
03b8c7b623c80af264c4c8d6111e5c6289933666 upstream.
If an architecture has futex_atomic_cmpxchg_inatomic() implemented and there
is no runtime check necessary, allow to skip the test within futex_init().
This allows to get rid of some code which would always give the same result,
and also allows the compiler to optimize a couple of if statements away.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Finn Thain <fthain@telegraphics.com.au>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Link: http://lkml.kernel.org/r/20140302120947.GA3641@osiris
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vineet Gupta [Sat, 5 Apr 2014 10:00:22 +0000 (15:30 +0530)]
ARC: [nsimosci] Unbork console
commit
61fb4bfc010b0d2940f7fd87acbce6a0f03217cb upstream.
Despite the switch to right UART driver (prev patch), serial console
still doesn't work due to missing CONFIG_SERIAL_OF_PLATFORM
Also fix the default cmdline in DT to not refer to out-of-tree
ARC framebuffer driver for console.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Francois Bedard <Francois.Bedard@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mischa Jonker [Thu, 16 May 2013 17:36:08 +0000 (19:36 +0200)]
ARC: [nsimosci] Change .dts to use generic 8250 UART
commit
6eda477b3c54b8236868c8784e5e042ff14244f0 upstream.
The Synopsys APB DW UART has a couple of special features that are not
in the System C model. In 3.8, the 8250_dw driver didn't really use these
features, but from 3.9 onwards, the 8250_dw driver has become incompatible
with our model.
Signed-off-by: Mischa Jonker <mjonker@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Francois Bedard <Francois.Bedard@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eyal Shapira [Sun, 16 Mar 2014 03:23:21 +0000 (05:23 +0200)]
iwlwifi: mvm: rs: fix search cycle rules
commit
8930b05090acd321b1fc7c642528c697cb105c42 upstream.
We should explore all possible columns when searching to be
as resilient as possible to changing conditions. This fixes
for example a scenario where even after a sudden creation of
rssi difference between the 2 antennas we would keep doing MIMO
at a low rate instead of switching to SISO at a higher rate using
the better antenna which was the optimal configuration.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gilles Chanteperdrix [Sun, 6 Apr 2014 18:37:44 +0000 (20:37 +0200)]
net/at91_ether: avoid NULL pointer dereference
[ Upstream commit
c293fb785bdda64d88f197e6758a3c16ae83e569 ]
The at91_ether driver calls macb_mii_init passing a 'struct macb'
structure whose tx_clk member is initialized to 0. However,
macb_handle_link_change() expects tx_clk to be the result of
a call to clk_get, and so IS_ERR(tx_clk) to be true if the clock
is invalid. This causes an oops when booting Linux 3.14 on the
csb637 board. The following changes avoids this.
Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sasha Levin [Sun, 30 Mar 2014 00:39:35 +0000 (20:39 -0400)]
rds: prevent dereference of a NULL device in rds_iw_laddr_check
[ Upstream commit
bf39b4247b8799935ea91d90db250ab608a58e50 ]
Binding might result in a NULL device which is later dereferenced
without checking.
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Tue, 8 Apr 2014 09:23:09 +0000 (12:23 +0300)]
isdnloop: several buffer overflows
[ Upstream commit
7563487cbf865284dcd35e9ef5a95380da046737 ]
There are three buffer overflows addressed in this patch.
1) In isdnloop_fake_err() we add an 'E' to a 60 character string and
then copy it into a 60 character buffer. I have made the destination
buffer 64 characters and I'm changed the sprintf() to a snprintf().
2) In isdnloop_parse_cmd(), p points to a 6 characters into a 60
character buffer so we have 54 characters. The ->eazlist[] is 11
characters long. I have modified the code to return if the source
buffer is too long.
3) In isdnloop_command() the cbuf[] array was 60 characters long but the
max length of the string then can be up to 79 characters. I made the
cbuf array 80 characters long and changed the sprintf() to snprintf().
I also removed the temporary "dial" buffer and changed it to use "p"
directly.
Unfortunately, we pass the "cbuf" string from isdnloop_command() to
isdnloop_writecmd() which truncates anything over 60 characters to make
it fit in card->omsg[]. (It can accept values up to 255 characters so
long as there is a '\n' character every 60 characters). For now I have
just fixed the memory corruption bug and left the other problems in this
driver alone.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
YOSHIFUJI Hideaki [Wed, 2 Apr 2014 03:48:42 +0000 (12:48 +0900)]
isdnloop: Validate NUL-terminated strings from user.
[ Upstream commit
77bc6bed7121936bb2e019a8c336075f4c8eef62 ]
Return -EINVAL unless all of user-given strings are correctly
NUL-terminated.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mike Rapoport [Tue, 1 Apr 2014 06:23:01 +0000 (09:23 +0300)]
net: vxlan: fix crash when interface is created with no group
[ Upstream commit
5933a7bbb5de66482ea8aa874a7ebaf8e67603c4 ]
If the vxlan interface is created without explicit group definition,
there are corner cases which may cause kernel panic.
For instance, in the following scenario:
node A:
$ ip link add dev vxlan42 address 2c:c2:60:00:10:20 type vxlan id 42
$ ip addr add dev vxlan42 10.0.0.1/24
$ ip link set up dev vxlan42
$ arp -i vxlan42 -s 10.0.0.2 2c:c2:60:00:01:02
$ bridge fdb add dev vxlan42 to 2c:c2:60:00:01:02 dst <IPv4 address>
$ ping 10.0.0.2
node B:
$ ip link add dev vxlan42 address 2c:c2:60:00:01:02 type vxlan id 42
$ ip addr add dev vxlan42 10.0.0.2/24
$ ip link set up dev vxlan42
$ arp -i vxlan42 -s 10.0.0.1 2c:c2:60:00:10:20
node B crashes:
vxlan42: 2c:c2:60:00:10:20 migrated from 4011:eca4:c0a8:6466:c0a8:6415:8e09:2118 to (invalid address)
vxlan42: 2c:c2:60:00:10:20 migrated from 4011:eca4:c0a8:6466:c0a8:6415:8e09:2118 to (invalid address)
BUG: unable to handle kernel NULL pointer dereference at
0000000000000046
IP: [<
ffffffff8143c459>] ip6_route_output+0x58/0x82
PGD
7bd89067 PUD
7bd4e067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.0-rc8-hvx-xen-00019-g97a5221-dirty #154
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
task:
ffff88007c774f50 ti:
ffff88007c79c000 task.ti:
ffff88007c79c000
RIP: 0010:[<
ffffffff8143c459>] [<
ffffffff8143c459>] ip6_route_output+0x58/0x82
RSP: 0018:
ffff88007fd03668 EFLAGS:
00010282
RAX:
0000000000000000 RBX:
ffffffff8186a000 RCX:
0000000000000040
RDX:
0000000000000000 RSI:
ffff88007b0e4a80 RDI:
ffff88007fd03754
RBP:
ffff88007fd03688 R08:
ffff88007b0e4a80 R09:
0000000000000000
R10:
0200000a0100000a R11:
0001002200000000 R12:
ffff88007fd03740
R13:
ffff88007b0e4a80 R14:
ffff88007b0e4a80 R15:
ffff88007bba0c50
FS:
0000000000000000(0000) GS:
ffff88007fd00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
0000000000000046 CR3:
000000007bb60000 CR4:
00000000000006e0
Stack:
0000000000000000 ffff88007fd037a0 ffffffff8186a000 ffff88007fd03740
ffff88007fd036c8 ffffffff814320bb 0000000000006e49 ffff88007b8b7360
ffff88007bdbf200 ffff88007bcbc000 ffff88007b8b7000 ffff88007b8b7360
Call Trace:
<IRQ>
[<
ffffffff814320bb>] ip6_dst_lookup_tail+0x2d/0xa4
[<
ffffffff814322a5>] ip6_dst_lookup+0x10/0x12
[<
ffffffff81323b4e>] vxlan_xmit_one+0x32a/0x68c
[<
ffffffff814a325a>] ? _raw_spin_unlock_irqrestore+0x12/0x14
[<
ffffffff8104c551>] ? lock_timer_base.isra.23+0x26/0x4b
[<
ffffffff8132451a>] vxlan_xmit+0x66a/0x6a8
[<
ffffffff8141a365>] ? ipt_do_table+0x35f/0x37e
[<
ffffffff81204ba2>] ? selinux_ip_postroute+0x41/0x26e
[<
ffffffff8139d0c1>] dev_hard_start_xmit+0x2ce/0x3ce
[<
ffffffff8139d491>] __dev_queue_xmit+0x2d0/0x392
[<
ffffffff813b380f>] ? eth_header+0x28/0xb5
[<
ffffffff8139d569>] dev_queue_xmit+0xb/0xd
[<
ffffffff813a5aa6>] neigh_resolve_output+0x134/0x152
[<
ffffffff813db741>] ip_finish_output2+0x236/0x299
[<
ffffffff813dc074>] ip_finish_output+0x98/0x9d
[<
ffffffff813dc749>] ip_output+0x62/0x67
[<
ffffffff813da9f2>] dst_output+0xf/0x11
[<
ffffffff813dc11c>] ip_local_out+0x1b/0x1f
[<
ffffffff813dcf1b>] ip_send_skb+0x11/0x37
[<
ffffffff813dcf70>] ip_push_pending_frames+0x2f/0x33
[<
ffffffff813ff732>] icmp_push_reply+0x106/0x115
[<
ffffffff813ff9e4>] icmp_reply+0x142/0x164
[<
ffffffff813ffb3b>] icmp_echo.part.16+0x46/0x48
[<
ffffffff813c1d30>] ? nf_iterate+0x43/0x80
[<
ffffffff813d8037>] ? xfrm4_policy_check.constprop.11+0x52/0x52
[<
ffffffff813ffb62>] icmp_echo+0x25/0x27
[<
ffffffff814005f7>] icmp_rcv+0x1d2/0x20a
[<
ffffffff813d8037>] ? xfrm4_policy_check.constprop.11+0x52/0x52
[<
ffffffff813d810d>] ip_local_deliver_finish+0xd6/0x14f
[<
ffffffff813d8037>] ? xfrm4_policy_check.constprop.11+0x52/0x52
[<
ffffffff813d7fde>] NF_HOOK.constprop.10+0x4c/0x53
[<
ffffffff813d82bf>] ip_local_deliver+0x4a/0x4f
[<
ffffffff813d7f7b>] ip_rcv_finish+0x253/0x26a
[<
ffffffff813d7d28>] ? inet_add_protocol+0x3e/0x3e
[<
ffffffff813d7fde>] NF_HOOK.constprop.10+0x4c/0x53
[<
ffffffff813d856a>] ip_rcv+0x2a6/0x2ec
[<
ffffffff8139a9a0>] __netif_receive_skb_core+0x43e/0x478
[<
ffffffff812a346f>] ? virtqueue_poll+0x16/0x27
[<
ffffffff8139aa2f>] __netif_receive_skb+0x55/0x5a
[<
ffffffff8139aaaa>] process_backlog+0x76/0x12f
[<
ffffffff8139add8>] net_rx_action+0xa2/0x1ab
[<
ffffffff81047847>] __do_softirq+0xca/0x1d1
[<
ffffffff81047ace>] irq_exit+0x3e/0x85
[<
ffffffff8100b98b>] do_IRQ+0xa9/0xc4
[<
ffffffff814a37ad>] common_interrupt+0x6d/0x6d
<EOI>
[<
ffffffff810378db>] ? native_safe_halt+0x6/0x8
[<
ffffffff810110c7>] default_idle+0x9/0xd
[<
ffffffff81011694>] arch_cpu_idle+0x13/0x1c
[<
ffffffff8107480d>] cpu_startup_entry+0xbc/0x137
[<
ffffffff8102e741>] start_secondary+0x1a0/0x1a5
Code: 24 14 e8 f1 e5 01 00 31 d2 a8 32 0f 95 c2 49 8b 44 24 2c 49 0b 44 24 24 74 05 83 ca 04 eb 1c 4d 85 ed 74 17 49 8b 85 a8 02 00 00 <66> 8b 40 46 66 c1 e8 07 83 e0 07 c1 e0 03 09 c2 4c 89 e6 48 89
RIP [<
ffffffff8143c459>] ip6_route_output+0x58/0x82
RSP <
ffff88007fd03668>
CR2:
0000000000000046
---[ end trace
4612329caab37efd ]---
When vxlan interface is created without explicit group definition, the
default_dst protocol family is initialiazed to AF_UNSPEC and the driver
assumes IPv4 configuration. On the other side, the default_dst protocol
family is used to differentiate between IPv4 and IPv6 cases and, since,
AF_UNSPEC != AF_INET, the processing takes the IPv6 path.
Making the IPv4 assumption explicit by settting default_dst protocol
family to AF_INET4 and preventing mixing of IPv4 and IPv6 addresses in
snooped fdb entries fixes the corner case crashes.
Signed-off-by: Mike Rapoport <mike.rapoport@ravellosystems.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Pieczko [Tue, 1 Apr 2014 12:10:34 +0000 (13:10 +0100)]
Call efx_set_channels() before efx->type->dimension_resources()
[ Upstream commit
52ad762b85ed7947ec9eff6b036eb985352f6874 ]
When using the "separate_tx_channels=1" module parameter, the TX queues are
initially numbered starting from the first TX-only channel number (after all the
RX-only channels). efx_set_channels() renumbers the queues so that they are
indexed from zero.
On EF10, the TX queues need to be relabelled in this way before calling the
dimension_resources NIC type operation, otherwise the TX queue PIO buffers can be
linked to the wrong VIs when using "separate_tx_channels=1".
Added comments to explain UC/WC mappings for PIO buffers
Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Liu [Tue, 1 Apr 2014 11:46:12 +0000 (12:46 +0100)]
xen-netback: disable rogue vif in kthread context
[ Upstream commit
e9d8b2c2968499c1f96563e6522c56958d5a1d0d ]
When netback discovers frontend is sending malformed packet it will
disables the interface which serves that frontend.
However disabling a network interface involving taking a mutex which
cannot be done in softirq context, so we need to defer this process to
kthread context.
This patch does the following:
1. introduce a flag to indicate the interface is disabled.
2. check that flag in TX path, don't do any work if it's true.
3. check that flag in RX path, turn off that interface if it's true.
The reason to disable it in RX path is because RX uses kthread. After
this change the behavior of netback is still consistent -- it won't do
any TX work for a rogue frontend, and the interface will be eventually
turned off.
Also change a "continue" to "break" after xenvif_fatal_tx_err, as it
doesn't make sense to continue processing packets if frontend is rogue.
This is a fix for XSA-90.
Reported-by: Török Edwin <edwin@etorok.net>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pablo Neira [Tue, 1 Apr 2014 17:38:44 +0000 (19:38 +0200)]
netlink: don't compare the nul-termination in nla_strcmp
[ Upstream commit
8b7b932434f5eee495b91a2804f5b64ebb2bc835 ]
nla_strcmp compares the string length plus one, so it's implicitly
including the nul-termination in the comparison.
int nla_strcmp(const struct nlattr *nla, const char *str)
{
int len = strlen(str) + 1;
...
d = memcmp(nla_data(nla), str, len);
However, if NLA_STRING is used, userspace can send us a string without
the nul-termination. This is a problem since the string
comparison will not match as the last byte may be not the
nul-termination.
Fix this by skipping the comparison of the nul-termination if the
attribute data is nul-terminated. Suggested by Thomas Graf.
Cc: Florian Westphal <fw@strlen.de>
Cc: Thomas Graf <tgraf@suug.ch>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hannes Frederic Sowa [Mon, 31 Mar 2014 18:14:10 +0000 (20:14 +0200)]
ipv6: some ipv6 statistic counters failed to disable bh
[ Upstream commit
43a43b6040165f7b40b5b489fe61a4cb7f8c4980 ]
After commit
c15b1ccadb323ea ("ipv6: move DAD and addrconf_verify
processing to workqueue") some counters are now updated in process context
and thus need to disable bh before doing so, otherwise deadlocks can
happen on 32-bit archs. Fabio Estevam noticed this while while mounting
a NFS volume on an ARM board.
As a compensation for missing this I looked after the other *_STATS_BH
and found three other calls which need updating:
1) icmp6_send: ip6_fragment -> icmpv6_send -> icmp6_send (error handling)
2) ip6_push_pending_frames: rawv6_sendmsg -> rawv6_push_pending_frames -> ...
(only in case of icmp protocol with raw sockets in error handling)
3) ping6_v6_sendmsg (error handling)
Fixes:
c15b1ccadb323ea ("ipv6: move DAD and addrconf_verify processing to workqueue")
Reported-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Durrant [Fri, 28 Mar 2014 11:39:07 +0000 (11:39 +0000)]
xen-netback: BUG_ON in xenvif_rx_action() not catching overflow
[ Upstream commit
1425c7a4e8d3d2eebf308bcbdc3fa3c1247686b4 ]
The BUG_ON to catch ring overflow in xenvif_rx_action() makes the assumption
that meta_slots_used == ring slots used. This is not necessarily the case
for GSO packets, because the non-prefix GSO protocol consumes one more ring
slot than meta-slot for the 'extra_info'. This patch changes the test to
actually check ring slots.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Durrant [Fri, 28 Mar 2014 11:39:06 +0000 (11:39 +0000)]
xen-netback: worse-case estimate in xenvif_rx_action is underestimating
[ Upstream commit
a02eb4732cf975d7fc71b6d1a71c058c9988b949 ]
The worse-case estimate for skb ring slot usage in xenvif_rx_action()
fails to take fragment page_offset into account. The page_offset does,
however, affect the number of times the fragmentation code calls
start_new_rx_buffer() (i.e. consume another slot) and the worse-case
should assume that will always return true. This patch adds the page_offset
into the DIV_ROUND_UP for each frag.
Unfortunately some frontends aggressively limit the number of requests
they post into the shared ring so to avoid an estimate that is 'too'
pessimal it is capped at MAX_SKB_FRAGS.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Durrant [Fri, 28 Mar 2014 11:39:05 +0000 (11:39 +0000)]
xen-netback: remove pointless clause from if statement
[ Upstream commit
0576eddf24df716d8570ef8ca11452a9f98eaab2 ]
This patch removes a test in start_new_rx_buffer() that checks whether
a copy operation is less than MAX_BUFFER_OFFSET in length, since
MAX_BUFFER_OFFSET is defined to be PAGE_SIZE and the only caller of
start_new_rx_buffer() already limits copy operations to PAGE_SIZE or less.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Sander Eikelenboom <linux@eikelenboom.it>
Reported-By: Sander Eikelenboom <linux@eikelenboom.it>
Tested-By: Sander Eikelenboom <linux@eikelenboom.it>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Tue, 8 Apr 2014 22:30:07 +0000 (15:30 -0700)]
futex: avoid race between requeue and wake
commit
69cd9eba38867a493a043bb13eb9b33cad5f1a9a upstream.
Jan Stancek reported:
"pthread_cond_broadcast/4-1.c testcase from openposix testsuite (LTP)
occasionally fails, because some threads fail to wake up.
Testcase creates 5 threads, which are all waiting on same condition.
Main thread then calls pthread_cond_broadcast() without holding mutex,
which calls:
futex(uaddr1, FUTEX_CMP_REQUEUE_PRIVATE, 1,
2147483647, uaddr2, ..)
This immediately wakes up single thread A, which unlocks mutex and
tries to wake up another thread:
futex(uaddr2, FUTEX_WAKE_PRIVATE, 1)
If thread A manages to call futex_wake() before any waiters are
requeued for uaddr2, no other thread is woken up"
The ordering constraints for the hash bucket waiter counting are that
the waiter counts have to be incremented _before_ getting the spinlock
(because the spinlock acts as part of the memory barrier), but the
"requeue" operation didn't honor those rules, and nobody had even
thought about that case.
This fairly simple patch just increments the waiter count for the target
hash bucket (hb2) when requeing a futex before taking the locks. It
then decrements them again after releasing the lock - the code that
actually moves the futex(es) between hash buckets will do the additional
required waiter count housekeeping.
Reported-and-tested-by: Jan Stancek <jstancek@redhat.com>
Acked-by: Davidlohr Bueso <davidlohr@hp.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Sat, 18 Jan 2014 11:48:17 +0000 (12:48 +0100)]
x86/efi: Make efi virtual runtime map passing more robust
commit
b7b898ae0c0a82489511a1ce1b35f26215e6beb5 upstream.
Currently, running SetVirtualAddressMap() and passing the physical
address of the virtual map array was working only by a lucky coincidence
because the memory was present in the EFI page table too. Until Toshi
went and booted this on a big HP box - the krealloc() manner of resizing
the memmap we're doing did allocate from such physical addresses which
were not mapped anymore and boom:
http://lkml.kernel.org/r/
1386806463.1791.295.camel@misato.fc.hp.com
One way to take care of that issue is to reimplement the krealloc thing
but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
and when we deplete that memory (shouldn't happen all that often but you
know firmware) we realloc the next power-of-two pages.
Having the pages, it is much more handy and easy to map them into the
EFI page table with the already existing mapping code which we're using
for building the virtual mappings.
Thanks to Toshi Kani and Matt for the great debugging help.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Sat, 18 Jan 2014 11:48:16 +0000 (12:48 +0100)]
x86, pageattr: Export page unmapping interface
commit
42a5477251f0e0f33ad5f6a95c48d685ec03191e upstream.
We will use it in efi so expose it.
Signed-off-by: Borislav Petkov <bp@suse.de>
Tested-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>