commit 7623e24478504740c32595cb987bd44a65da931b
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri Nov 14 10:10:57 2014 -0800
Linux 3.17.3
commit 4873314344ea38e95526421f445c2de473ee1be5
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Tue Oct 28 00:03:43 2014 +0200
KVM: x86: Fix far-jump to non-canonical check
commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream.
Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far
jumps") introduced a bug that caused the fix to be incomplete. Due to
incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit
segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may
not trigger #GP. As we know, this imposes a security problem.
In addition, the condition for two warnings was incorrect.
Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
[Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84b3d9d8ad70f5ec2a7893c331075d31d5f3dd9a
Author: Olivier Gay <ogay@logitech.com>
Date: Sat Oct 18 01:53:39 2014 +0200
HID: add keyboard input assist hid usages
commit f974008f07a62171a9dede08250c9a35c2b2b986 upstream.
Add keyboard input assist controls usages from approved
hid usage table request HUTTR42:
http://www.usb.org/developers/hidpage/HUTRR42c.pdf
Signed-off-by: Olivier Gay <ogay@logitech.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dfd0ae98ef7939d0257d401b966fbb72108e0e9b
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 7 08:33:52 2014 +1100
xfs: track bulkstat progress by agino
commit 002758992693ae63c04122603ea9261a0a58d728 upstream.
The bulkstat main loop progress is tracked by the "lastino"
variable, which is a full 64 bit inode. However, the loop actually
works on agno/agino pairs, and so there's a significant disconnect
between the rest of the loop and the main cursor. Convert this to
use the agino, and pass the agino into the chunk formatting function
and convert it too.
This gets rid of the inconsistency in the loop processing, and
finally makes it simple for us to skip inodes at any point in the
loop simply by incrementing the agino cursor.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4107526cb39dc85ebfe5cb5c5ee14358fc4aace9
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 7 08:31:15 2014 +1100
xfs: bulkstat error handling is broken
commit febe3cbe38b0bc0a925906dc90e8d59048851f87 upstream.
The error propagation is a horror - xfs_bulkstat() returns
a rval variable which is only set if there are formatter errors. Any
sort of btree walk error or corruption will cause the bulkstat walk
to terminate but will not pass an error back to userspace. Worse
is the fact that formatter errors will also be ignored if any inodes
were correctly formatted into the user buffer.
Hence bulkstat can fail badly yet still report success to userspace.
This causes significant issues with xfsdump not dumping everything
in the filesystem yet reporting success. It's not until a restore
fails that there is any indication that the dump was bad and tha
bulkstat failed. This patch now triggers xfsdump to fail with
bulkstat errors rather than silently missing files in the dump.
This now causes bulkstat to fail when the lastino cookie does not
fall inside an existing inode chunk. The pre-3.17 code tolerated
that error by allowing the code to move to the next inode chunk
as the agino target is guaranteed to fall into the next btree
record.
With the fixes up to this point in the series, xfsdump now passes on
the troublesome filesystem image that exposes all these bugs.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3e72efa9b34802ae25cfaa77b05d210dec600469
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 7 08:31:13 2014 +1100
xfs: bulkstat main loop logic is a mess
commit 6e57c542cb7e0e580eb53ae76a77875c7d92b4b1 upstream.
There are a bunch of variables tha tare more wildy scoped than they
need to be, obfuscated user buffer checks and tortured "next inode"
tracking. This all needs cleaning up to expose the real issues that
need fixing.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a88cdfe5ad49b966914379bef61e0ac3cfe65a2c
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 7 08:30:58 2014 +1100
xfs: bulkstat chunk-formatter has issues
commit 2b831ac6bc87d3cbcbb1a8816827b6923403e461 upstream.
The loop construct has issues:
- clustidx is completely unused, so remove it.
- the loop tries to be smart by terminating when the
"freecount" tells it that all inodes are free. Just drop
it as in most cases we have to scan all inodes in the
chunk anyway.
- move the "user buffer left" condition check to the only
point where we consume space int eh user buffer.
- move the initialisation of agino out of the loop, leaving
just a simple loop control logic using the clusteridx.
Also, double handling of the user buffer variables leads to problems
tracking the current state - use the cursor variables directly
rather than keeping local copies and then having to update the
cursor before returning.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8ee218f083fc71c742d4319a43d73e791f3d0e8b
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 7 08:30:30 2014 +1100
xfs: bulkstat chunk formatting cursor is broken
commit bf4a5af20d25ecc8876978ad34b8db83b4235f3c upstream.
The xfs_bulkstat_agichunk formatting cursor takes buffer values from
the main loop and passes them via the structure to the chunk
formatter, and the writes the changed values back into the main loop
local variables. Unfortunately, this complex dance is full of corner
cases that aren't handled correctly.
The biggest problem is that it is double handling the information in
both the main loop and the chunk formatting function, leading to
inconsistent updates and endless loops where progress is not made.
To fix this, push the struct xfs_bulkstat_agichunk outwards to be
the primary holder of user buffer information. this removes the
double handling in the main loop.
Also, pass the last inode processed by the chunk formatter as a
separate parameter as it purely an output variable and is not
related to the user buffer consumption cursor.
Finally, the chunk formatting code is not shared by anyone, so make
it local to xfs_itable.c.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6de2ef500fca4fe624b759faba57d523841f9f65
Author: Dave Chinner <dchinner@redhat.com>
Date: Fri Nov 7 08:29:57 2014 +1100
xfs: bulkstat btree walk doesn't terminate
commit afa947cb52a8e73fe71915a0b0af6fcf98dfbe1a upstream.
The bulkstat code has several different ways of detecting the end of
an AG when doing a walk. They are not consistently detected, and the
code that checks for the end of AG conditions is not consistently
coded. Hence the are conditions where the walk code can get stuck in
an endless loop making no progress and not triggering any
termination conditions.
Convert all the "tmp/i" status return codes from btree operations
to a common name (stat) and apply end-of-ag detection to these
operations consistently.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a1606786b627409d725ba211d6ac679006415ba4
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 30 10:34:52 2014 +1100
xfs: Check error during inode btree iteration in xfs_bulkstat()
commit 7a19dee116c8fae7ba7a778043c245194289f5a2 upstream.
xfs_bulkstat() doesn't check error return from xfs_btree_increment(). In
case of specific fs corruption that could result in xfs_bulkstat()
entering an infinite loop because we would be looping over the same
chunk over and over again. Fix the problem by checking the return value
and terminating the loop properly.
Coverity-id: 1231338
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Jie Liu <jeff.u.liu@gmail.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bf3017d073bfa205275bfadb912053e8160e06ba
Author: Dave Chinner <dchinner@redhat.com>
Date: Wed Oct 29 08:22:18 2014 +1100
xfs: bulkstat doesn't release AGI buffer on error
commit a6bbce54efa9145dbcf3029c885549f7ebc40a3b upstream.
The recent refactoring of the bulkstat code left a small landmine in
the code. If a inobt read fails, then the tree walk is aborted and
returns without releasing the AGI buffer or freeing the cursor. This
can lead to a subsequent bulkstat call hanging trying to grab the
AGI buffer again.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 535a914975e79ef24b3b519c52fad351f56a6f08
Author: Chris Mason <clm@fb.com>
Date: Tue Nov 4 06:59:04 2014 -0800
Btrfs: fix kfree on list_head in btrfs_lookup_csums_range error cleanup
commit 6e5aafb27419f32575b27ef9d6a31e5d54661aca upstream.
If we hit any errors in btrfs_lookup_csums_range, we'll loop through all
the csums we allocate and free them. But the code was using list_entry
incorrectly, and ended up trying to free the on-stack list_head instead.
This bug came from commit 0678b6185
btrfs: Don't BUG_ON kzalloc error in btrfs_lookup_csums_range()
Signed-off-by: Chris Mason <clm@fb.com>
Reported-by: Erik Berg <btrfs@slipsprogrammoer.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe716b704f7395459cdad92ce4c5fc83f6b55f7a
Author: Grant Likely <grant.likely@linaro.org>
Date: Mon Nov 3 15:15:35 2014 +0000
of: Fix overflow bug in string property parsing functions
commit a87fa1d81a9fb5e9adca9820e16008c40ad09f33 upstream.
The string property read helpers will run off the end of the buffer if
it is handed a malformed string property. Rework the parsers to make
sure that doesn't happen. At the same time add new test cases to make
sure the functions behave themselves.
The original implementations of of_property_read_string_index() and
of_property_count_strings() both open-coded the same block of parsing
code, each with it's own subtly different bugs. The fix here merges
functions into a single helper and makes the original functions static
inline wrappers around the helper.
One non-bugfix aspect of this patch is the addition of a new wrapper,
of_property_read_string_array(). The new wrapper is needed by the
device_properties feature that Rafael is working on and planning to
merge for v3.19. The implementation is identical both with and without
the new static inline wrapper, so it just got left in to reduce the
churn on the header file.
Signed-off-by: Grant Likely <grant.likely@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Darren Hart <darren.hart@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7322a1dde616aa0e031192fc98a1c6e85bcef424
Author: Andreas Färber <afaerber@suse.de>
Date: Thu Nov 6 18:22:10 2014 +0100
ARM: dts: zynq: Enable PL clocks for Parallella
commit 92c9e0c780e61f821ab8a08f0d4d4fd33ba1197c upstream.
The Parallella board comes with a U-Boot bootloader that loads one of
two predefined FPGA bitstreams before booting the kernel. Both define an
AXI interface to the on-board Epiphany processor.
Enable clocks FCLK0..FCLK3 for the Programmable Logic by default.
Otherwise accessing, e.g., the ESYSRESET register freezes the board,
as seen with the Epiphany SDK tools e-reset and e-hw-rev, using /dev/mem.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4199f74e534522d099bffb33c2896090493eee8d
Author: Yijing Wang <wangyijing@huawei.com>
Date: Fri Nov 7 12:05:49 2014 +0800
sysfs: driver core: Fix glue dir race condition by gdp_mutex
commit e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream.
There is a race condition when removing glue directory.
It can be reproduced in following test:
path 1: Add first child device
device_add()
get_device_parent()
/*find parent from glue_dirs.list*/
list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry)
if (k->parent == parent_kobj) {
kobj = kobject_get(k);
break;
}
....
class_dir_create_and_add()
path2: Remove last child device under glue dir
device_del()
cleanup_device_parent()
cleanup_glue_dir()
kobject_put(glue_dir);
If path2 has been called cleanup_glue_dir(), but not
call kobject_put(glue_dir), the glue dir is still
in parent's kset list. Meanwhile, path1 find the glue
dir from the glue_dirs.list. Path2 may release glue dir
before path1 call kobject_get(). So kernel will report
the warning and bug_on.
This is a "classic" problem we have of a kref in a list
that can be found while the last instance could be removed
at the same time.
This patch reuse gdp_mutex to fix this race condition.
The following calltrace is captured in kernel 3.4, but
the latest kernel still has this bug.
-----------------------------------------------------
<4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40()
<4>[ 3965.441474] Hardware name: Romley
<4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)...
...
<4>[ 3965.441605] Call Trace:
<4>[ 3965.441611] [<ffffffff8103717a>] warn_slowpath_common+0x7a/0xb0
<4>[ 3965.441615] [<ffffffff810371c5>] warn_slowpath_null+0x15/0x20
<4>[ 3965.441618] [<ffffffff81215963>] kobject_get+0x33/0x40
<4>[ 3965.441624] [<ffffffff812d1e45>] get_device_parent.isra.11+0x135/0x1f0
<4>[ 3965.441627] [<ffffffff812d22d4>] device_add+0xd4/0x6d0
<4>[ 3965.441631] [<ffffffff812d0dbc>] ? dev_set_name+0x3c/0x40
....
<2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65!
<4>[ 3965.441915] invalid opcode: 0000 [#1] SMP
...
<4>[ 3965.686743] [<ffffffff811a677e>] sysfs_create_group+0xe/0x10
<4>[ 3965.686748] [<ffffffff810cfb04>] blk_trace_init_sysfs+0x14/0x20
<4>[ 3965.686753] [<ffffffff811fcabb>] blk_register_queue+0x3b/0x120
<4>[ 3965.686756] [<ffffffff812030bc>] add_disk+0x1cc/0x490
....
-------------------------------------------------------
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Weng Meiling <wengmeiling.weng@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f6f10a638a35842b0ea0c9035d7bfbc5b71c39d5
Author: Wolfram Sang <wsa@the-dreams.de>
Date: Mon Nov 3 21:16:16 2014 +0100
i2c: at91: don't account as iowait
commit 11cfbfb098b22d3e57f1f2be217cad20e2d48463 upstream.
iowait is for blkio [1]. I2C shouldn't use it.
[1] https://lkml.org/lkml/2014/11/3/317
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 72621b91f458343c0d92ce112a46dd0944aeb9ce
Author: Grzegorz Jaszczyk <jaz@semihalf.com>
Date: Thu Sep 25 13:17:19 2014 +0200
irqchip: armada-370-xp: Fix MPIC interrupt handling
commit 758e8366754d3fa57da978fef9d2c652f7b55c02 upstream.
In both Armada-375 and Armada-38x MPIC interrupts should be identified by
reading cause register multiplied by the interrupt mask.
A lack of above mentioned multiplication resulted in a bug, caused by the
fact that in Armada-375 and Armada-38x some of the interrupts
(e.g. network interrupts) can be handled either as a GIC or MPIC interrupts.
Therefore during MPIC interrupts handling, cause register shows hits from
interrupts even if they are masked for MPIC but unmasked for a GIC.
This resulted in 'bad IRQ' error, because masked MPIC interrupt without
registered interrupt handler, was trying to be handled during interrupt
handling procedure of some other unmasked MPIC interrupt (e.g. local timer
irq).
This commit fixes that by ensuring that during MPIC interrupt handling only
interrupts that are unmasked for MPIC are processed.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1411643839-64925-3-git-send-email-jaz@semihalf.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 03090719a0da6ab35509c8037c06a2491bb64fa4
Author: Grzegorz Jaszczyk <jaz@semihalf.com>
Date: Thu Sep 25 13:17:18 2014 +0200
irqchip: armada-370-xp: Fix MSI interrupt handling
commit 298dcb2dd0267d51e4f7c94a628cd0765a50ad75 upstream.
The MSI interrupts use the 16 high doorbells, which are notified by using IRQ1
of the main interrupt controller.
The MSI interrupts were handled correctly for Armada-XP and Armada-370 but not
for Armada-375 and Armada-38x, which use chained handler for the MPIC.
This commit fixes that by checking proper interrupt number in chained handler
for the MPIC.
Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Fixes: bc69b8adfe22 ("irqchip: armada-370-xp: Setup a chained handler for the MPIC")
Acked-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Link: https://lkml.kernel.org/r/1411643839-64925-2-git-send-email-jaz@semihalf.com
Signed-off-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d676fb7ecf9f9307dcd06e91b64e930bd3e6921d
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Mon Nov 3 15:07:05 2014 +0100
regulator: max77693: Fix use of uninitialized regulator config
commit ca0c37a0b489bb14bf3e1549e7a8d0c9a17f4919 upstream.
Driver allocated on stack struct regulator_config but didn't initialize
it fully. Few fields (driver_data, ena_gpio) were left untouched. This
lead to using random ena_gpio values as GPIOs for max77693 regulators.
On occasion these values could match real GPIO numbers leading to
interfering with other drivers and to unsuccessful enable/disable of
regulator.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 80b022e29bfd ("regulator: max77693: Add max77693 regualtor driver.")
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e3761a40c3ce24b11074e2cc3cc70820ff438a53
Author: Hui Wang <hui.wang@canonical.com>
Date: Wed Nov 5 12:17:58 2014 +0800
ALSA: hda - fix mute led problem for three HP laptops
commit c922c4e87b9b5a3b50d4d17b96f189121430f511 upstream.
Without the fix, the mute led can't work on these three machines.
After apply this fix, these three machines will fall back on the led
control quirk as below, and through testing, the mute led works very
well.
PIN_QUIRK(0x10ec0282, 0x103c, "HP", ALC269_FIXUP_HP_LINE1_MIC1_LED,
ALC282_STANDARD_PINS,
{0x12, 0x90a60140},
...
BugLink: https://bugs.launchpad.net/bugs/1389497
Tested-by: TieFu Chen <tienfu.chen@canonical.com>
Cc: Kailang Yang <kailang@realtek.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>
commit ca2612cb0a0a3261a46e49997ec28ad4b029d7d8
Author: Anton Blanchard <anton@samba.org>
Date: Fri Oct 31 16:50:57 2014 +1100
powerpc: do_notify_resume can be called with bad thread_info flags argument
commit 808be31426af57af22268ef0fcb42617beb3d15b upstream.
Back in 7230c5644188 ("powerpc: Rework lazy-interrupt handling") we
added a call out to restore_interrupts() (written in c) before calling
do_notify_resume:
bl restore_interrupts
addi r3,r1,STACK_FRAME_OVERHEAD
bl do_notify_resume
Unfortunately do_notify_resume takes two arguments, the second one
being the thread_info flags:
void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags)
We do populate r4 (the second argument) earlier, but
restore_interrupts() is free to muck it up all it wants. My guess is
the gcc compiler gods shone down on us and its register allocator
never used r4. Sometimes, rarely, luck is on our side.
LLVM on the other hand did trample r4.
Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67dc5fdb8adca284a155270e7a28eee382a4ddce
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu Oct 30 16:19:13 2014 +1100
powerpc/powernv: Properly fix LPC debugfs endianness
commit 325e4114043469e5f9923d902b4d30bcc2be8163 upstream.
Endian is hard, especially when I designed a stupid FW interface, and
I should know better... oh well, this is attempt #2 at fixing this
properly. This time it seems to work with all access sizes and I
can run my flashing tool (which exercises all sort of access sizes
and types to access the SPI controller in the BMC) just fine.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b0d6e46e134a07e33743db3f24d91b315abd36f
Author: Dan Streetman <ddstreet@ieee.org>
Date: Fri Oct 31 15:41:34 2014 -0400
powerpc: use device_online/offline() instead of cpu_up/down()
commit 10ccaf178b2b961d8bca252d647ed7ed8aae2a20 upstream.
In powerpc pseries platform dlpar operations, use device_online() and
device_offline() instead of cpu_up() and cpu_down().
Calling cpu_up/down() directly does not update the cpu device offline
field, which is used to online/offline a cpu from sysfs. Calling
device_online/offline() instead keeps the sysfs cpu online value
correct. The hotplug lock, which is required to be held when calling
device_online/offline(), is already held when dlpar_online/offline_cpu()
are called, since they are called only from cpu_probe|release_store().
This patch fixes errors on phyp (PowerVM) systems that have cpu(s)
added/removed using dlpar operations; without this patch, the
/sys/devices/system/cpu/cpuN/online nodes do not correctly show the
online state of added/removed cpus.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
Fixes: 0902a9044fa5 ("Driver core: Use generic offline/online for CPU offline/online")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d66aca8be14745e389d2f28ab1ae4b3b605a01c6
Author: Robert Jarzmik <robert.jarzmik@free.fr>
Date: Tue Oct 7 21:18:14 2014 +0200
ARM: pxa: fix hang on startup with DEBUG_LL
commit cde7fc879969f933614b1256df2625d6ff637bab upstream.
The commit 2111667b4677 ("ARM: pxa: call debug_ll_io_init for
earlyprintk") triggers in the current kernel the attached backtrace on
PXA/tosa early in the boot time when DEBUG_LL is enabled.
It is due to overlap between uart virtual memory defined in
DEBUG_UART_VIRT and mapped by debug_ll_io_init() and peripheral bus
mapped by pxa_map_io at the same address, 0xf2100000.
As hinted by Arnd, map early virtual memory for low level debug on
address 0xf6200000, even if that means 2 virtual mappings will give
access to the pxa internal UARTs (FFUART, BTUART, STUART, ...).
------------[ cut here ]------------
kernel BUG at /home/lumag/linux/mm/vmalloc.c:1143!
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.17.0-00032-g8e0d202-dirty #23
task: c062a5a8 ti: c0620000 task.ti: c0620000
PC is at vm_area_add_early+0x54/0x84
LR is at add_static_vm_early+0xc/0x60
pc : [<c03e1100>] lr : [<c03d9ef4>] psr: 800001d3
sp : c0621f04 ip : c03efa74 fp : c03edf84
r10: c0637e98 r9 : 40000001 r8 : c03da57c
r7 : c3ffcfb0 r6 : 00000000 r5 : c3ffcfb0 r4 : 02000000
r3 : c3ffcfd8 r2 : f2100000 r1 : f4000000 r0 : c3ffcfb0
Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 00007977 Table: a0004000 DAC: 00000017
Process swapper (pid: 0, stack limit = 0xc06201c8)
Stack: (0xc0621f04 to 0xc0622000)
1f00: c3ffcfd8 40000001 c3ffcfd8 c03ee08c c03da570 c03db90c c0637d24
1f20: 00000000 c03ec7cc c066e654 a0700000 000a0700 c03db914 c03db90c c03daf84
1f40: 00000000 000a0000 c0000000 c03ec7cc 000a0700 c0700000 ffff1000 000a3fff
1f60: 00001000 00000007 00000000 c03ec7cc c0008000 c03ed748 c0621fd4 c03d5d18
1f80: 69052d00 a03ec48c 00000000 c03d8ad0 0000006c 00007977 c036c6e8 00000001
1fa0: c0621fd4 c03ed744 c0628000 a0004000 69052d00 a03ec48c 00000000 c03d68d4
1fc0: 00000000 00000000 00000000 00000000 00000000 c03ed748 c0649894 c062801c
1fe0: c03ed744 c062b2f0 a0004000 69052d00 a03ec48c a0008040 00000000 00000000
[<c03e1100>] (vm_area_add_early) from [<c03d9ef4>] (add_static_vm_early+0xc/0x60)
[<c03d9ef4>] (add_static_vm_early) from [<c03da570>] (iotable_init.part.6+0xa8/0xb4)
[<c03da570>] (iotable_init.part.6) from [<c03db914>] (pxa25x_map_io+0x8/0x24)
[<c03db914>] (pxa25x_map_io) from [<c03daf84>] (paging_init+0x744/0x8d8)
[<c03daf84>] (paging_init) from [<c03d8ad0>] (setup_arch+0x354/0x608)
[<c03d8ad0>] (setup_arch) from [<c03d68d4>] (start_kernel+0xa8/0x3dc)
[<c03d68d4>] (start_kernel) from [<a0008040>] (0xa0008040)
Code: e5904008 e0811004 e1520001 2a000005 (e7f001f2)
---[ end trace f24b6c88ae00fa9a ]---
Kernel panic - not syncing: Attempted to kill the idle task!
---[ end Kernel panic - not syncing: Attempted to kill the idle task!
Reported-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d86a3766e30cff28ea48b95c79329a8ab51d738f
Author: David Cohen <david.a.cohen@linux.intel.com>
Date: Tue Oct 14 10:54:37 2014 -0700
pinctrl: baytrail: show output gpio state correctly on Intel Baytrail
commit d90c33818967c5e5371961604ad98b4dea4fa3f4 upstream.
Even if a gpio pin is set to output, we still need to set INPUT_EN
functionality (by clearing INPUT_EN bit) to be able to read the pin's
level.
E.g. without this change, we'll always read low level state from sysfs.
Cc: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Reviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d9a6fc737bc6fd46a1a8fe8b243385eb80a80443
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Wed Nov 5 15:18:29 2014 -0500
fix breakage in o2net_send_tcp_msg()
commit 7e8631e8b9d4e9f698c09c7e7309c96249180ff9 upstream.
uninitialized msghdr. Broken in "ocfs2: don't open-code kernel_recvmsg()"
by me ;-/
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 719393f9e47056fc5bb10bf4d1442513d719aee5
Author: Hans de Goede <hdegoede@redhat.com>
Date: Wed Oct 22 16:06:37 2014 +0200
samsung-laptop: Add broken-acpi-video quirk for NC210/NC110
commit 5a1426c99f9b7aa11d60c4e6b7a3211bb5321696 upstream.
The acpi-video backlight interface on the NC210 does not work, blacklist it
and use the samsung-laptop interface instead.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=861573
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78655eee9ef9faba568486aef83806a15fe60337
Author: Hans de Goede <hdegoede@redhat.com>
Date: Wed Oct 22 16:06:38 2014 +0200
acer-wmi: Add acpi_backlight=video quirk for the Acer KAV80
commit 183fd8fcd7f8afb7ac5ec68f83194872f9fecc84 upstream.
The acpi-video backlight interface on the Acer KAV80 is broken, and worse
it causes the entire machine to slow down significantly after a suspend/resume.
Blacklist it, and use the acer-wmi backlight interface instead. Note that
the KAV80 is somewhat unique in that it is the only Acer model where we
fall back to acer-wmi after blacklisting, rather then using the native
(e.g. intel) backlight driver. This is done because there is no native
backlight interface on this model.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1128309
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7205c36680c5aedffbec9b49a9a7e8310da10354
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 22 09:17:24 2014 +0200
rbd: Fix error recovery in rbd_obj_read_sync()
commit a8d4205623ae965e36c68629db306ca0695a2771 upstream.
When we fail to allocate page vector in rbd_obj_read_sync() we just
basically ignore the problem and continue which will result in an oops
later. Fix the problem by returning proper error.
CC: Yehuda Sadeh <yehuda@inktank.com>
CC: Sage Weil <sage@inktank.com>
CC: ceph-devel@vger.kernel.org
Coverity-id: 1226882
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 27a7bcd561d9c79bdd427f8855f130de88dce663
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Fri Oct 24 13:18:39 2014 +0300
mm: cma: Don't crash on allocation if CMA area can't be activated
commit f022d8cb7ec70fe8edd56383d876001317ee76b1 upstream.
If activation of the CMA area fails its mutex won't be initialized,
leading to an oops at allocation time when trying to lock the mutex. Fix
this by setting the cma area count field to 0 when activation fails,
leading to allocation returning NULL immediately.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 37220fc8c02824734c6d9c59e0d0fd4e5abddb72
Author: jens stein <jens.s.stein@gmail.com>
Date: Tue Oct 28 20:25:53 2014 +0100
drm/i915: Ignore VBT backlight check on Macbook 2, 1
commit b2a9601c587dbc5536546aa54009d1130adedd72 upstream.
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Apr 9 11:31:37 2014 +0300
drm/i915: do not setup backlight if not available according to VBT
prevents backlight setup on Macbook 2,1. Apply quirk to ignore the VBT
check so backlight is set up properly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81438
Signed-off-by: Jens Stein Jørgensen <jens.s.stein@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1ca1a5f29ac0eb186cf3acb5c641d9210a78917
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Oct 16 20:52:31 2014 +0300
drm/i915: Fix GMBUSFREQ on vlv/chv
commit 6be1e3d3ea29354d7c834a3936e796e185d5c73b upstream.
vlv_cdclk_freq is in kHz but we need MHz for the GMBUSFREQ divider.
This is a regression from:
commit f8bf63fdcb1f82459dae7a3f22ee5ce92f3ea727
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Fri Jun 13 13:37:54 2014 +0300
drm/i915: Kill duplicated cdclk readout code from i2c
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f5a3f0d46a7a9539b5c2e80f24e1ae4eae9a484
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Oct 16 20:46:09 2014 +0300
drm/i915: Do a dummy DPCD read before the actual read
commit f6a1906674005377b64ee5431c1418077c1b2425 upstream.
Sometimes we seem to get utter garbage from DPCD reads. The resulting
buffer is filled with the same byte, and the operation completed without
errors. My HP ZR24w monitor seems particularly susceptible to this
problem once it's gone into a sleep mode.
The issue seems to happen only for the first AUX message that wakes the
sink up. But as the first AUX read we often do is the DPCD receiver
cap it does wreak a bit of havoc with subsequent link training etc. when
the receiver cap bw/lane/etc. information is garbage.
A sufficient workaround seems to be to perform a single byte dummy read
before reading the actual data. I suppose that just wakes up the sink
sufficiently and we can just throw away the returned data in case it's
crap. DP_DPCD_REV seems like a sufficiently safe location to read here.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Todd Previte <tprevite@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14fee5dab7267bb8063f88f3664fd392156889be
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Sun Oct 26 15:18:42 2014 -0400
drm/radeon: remove invalid pci id
commit 8c3e434769b1707fd2d24de5a2eb25fedc634c4a upstream.
0x4c6e is a secondary device id so should not be used
by the driver.
Noticed-by: Mark Kettenis <mark.kettenis@xs4all.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7690d59e4fac284ec02d1d80b7b04a060838592e
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Sun Oct 26 15:10:21 2014 -0400
drm/radeon: dpm fixes for asrock systems
commit 72b3f9183ed57e4a2f0601a1c25ae2fd39855952 upstream.
- bapm seems to cause CPU stuck messages so disable it.
- nb dpm seems to prevent GPU dpm from getting enabled, so
disable it.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=85107
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84d0dd93d26757952d8cc5cbc0153f35582f2fe8
Author: Michel Dänzer <michel.daenzer@amd.com>
Date: Mon Oct 20 18:40:54 2014 +0900
drm/radeon: Use drm_malloc_ab instead of kmalloc_array
commit e5a5fd4df21b9c4acb67e815ec949cce594860f8 upstream.
Should avoid kmalloc failures due to large number of array entries.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81991
Reviewed-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cd335786eb9f09a16c82106ec0bbceb62de44877
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Oct 13 12:44:49 2014 -0400
drm/radeon/dpm: disable ulv support on SI
commit 6fa455935ab956248b165f150ec6ae9106210077 upstream.
Causes problems on some boards.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=82889
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01761ad1961e2c700cedae3ee84b7e492f53d33d
Author: Sinclair Yeh <syeh@vmware.com>
Date: Fri Oct 31 09:58:06 2014 +0100
drm/vmwgfx: Filter out modes those cannot be supported by the current VRAM size.
commit 9a72384d86b26cb8a2b25106677e1197f606668f upstream.
When screen objects are enabled, the bpp is assumed to be 32, otherwise
it is set to 16.
v2:
* Use u32 instead of u64 for assumed_bpp.
* Fixed mechanism to check for screen objects
* Limit the back buffer size to VRAM.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5f5ff5f2f5a6a5431823534392a707242cb8bc80
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Mon Oct 27 13:21:32 2014 +0800
x86, intel-mid: Create IRQs for APB timers and RTC timers
commit f18298595aefa2c836a128ec6e0f75f39965dd81 upstream.
Intel MID platforms has no legacy interrupts, so no IRQ descriptors
preallocated. We need to call mp_map_gsi_to_irq() to create IRQ
descriptors for APB timers and RTC timers, otherwise it may cause
invalid memory access as:
[ 0.116839] BUG: unable to handle kernel NULL pointer dereference at
0000003a
[ 0.123803] IP: [<c1071c0e>] setup_irq+0xf/0x4d
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: H. Peter Anvin <hpa@linux.intel.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: David Cohen <david.a.cohen@linux.intel.com>
Link: http://lkml.kernel.org/r/1414387308-27148-3-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f2a33364ae9eea8aabdf6cc9cae50eca77981ed
Author: Kirill Tkhai <ktkhai@parallels.com>
Date: Mon Sep 22 22:36:36 2014 +0400
sched: Use rq->rd in sched_setaffinity() under RCU read lock
commit f1e3a0932f3a9554371792a7daaf1e0eb19f66d5 upstream.
Probability of use-after-free isn't zero in this place.
Signed-off-by: Kirill Tkhai <ktkhai@parallels.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140922183636.11015.83611.stgit@localhost
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4ff772faf6c9a419c84997f6f1ff7409354d3b8
Author: Felipe Balbi <balbi@ti.com>
Date: Mon Nov 10 08:56:40 2014 -0600
usb: gadget: function: acm: make f_acm pass USB20CV Chapter9
[ Upstream commit 52ec49a5e56a27c5b6f8217708783eff39f24c16 ]
During Halt Endpoint Test, our interrupt endpoint
will be disabled, which will clear out ep->desc
to NULL. Unless we call config_ep_by_speed() again,
we will not be able to enable this endpoint which
will make us fail that test.
Fixes: f9c56cd (usb: gadget: Clear usb_endpoint_descriptor
inside the struct usb_ep on disable)
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 175b226e597820f450d11ad437d8aa084c37ad80
Author: Felipe Balbi <balbi@ti.com>
Date: Mon Nov 10 08:55:44 2014 -0600
usb: dwc3: gadget: fix set_halt() bug with pending transfers
[ Upstream commit 7a60855972f0d3c014093046cb6f013a1ee5bb19 ]
According to our Gadget Framework API documentation,
->set_halt() *must* return -EAGAIN if we have pending
transfers (on either direction) or FIFO isn't empty (on
TX endpoints).
Fix this bug so that the mass storage gadget can be used
without stall=0 parameter.
This patch should be backported to all kernels since v3.2.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89b0d0d828f84827f248db70a8f3da08c019b662
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Nov 11 14:11:52 2014 -0800
mtd: m25p80: Fix module aliases for m25p80
Based on a5b7616c55e188fe3d6ef686bef402d4703ecb62, but backported so
that a bunch of dependencies are not needed.
m25p80's device ID table is now spi_nor_ids, defined in spi-nor. The
MODULE_DEVICE_TABLE() macro doesn't work with extern definitions, but
its use was also removed at the same time. Now if m25p80 is built as
a module it doesn't get the necessary aliases to be loaded
automatically.
A clean solution to this will involve defining the list of device
IDs in spi-nor.h and removing struct spi_device_id from the spi-nor
API, but this is quite a large change.
As a quick fix suitable for stable, copy the device IDs back into
m25p80.
Fixes: 03e296f613af ("mtd: m25p80: use the SPI nor framework")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Brian: backport without the dependencies]
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 16b5dbc6323d3293004671b864bf2f1768b91504
Author: Ondrej Kozina <okozina@redhat.com>
Date: Mon Aug 25 11:49:54 2014 +0200
crypto: algif - avoid excessive use of socket buffer in skcipher
commit e2cffb5f493a8b431dc87124388ea59b79f0bccb upstream.
On archs with PAGE_SIZE >= 64 KiB the function skcipher_alloc_sgl()
fails with -ENOMEM no matter what user space actually requested.
This is caused by the fact sock_kmalloc call inside the function tried
to allocate more memory than allowed by the default kernel socket buffer
size (kernel param net.core.optmem_max).
Signed-off-by: Ondrej Kozina <okozina@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e6b72a32005b1120cf07b248f871bfe554a0682f
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date: Mon Oct 6 13:08:06 2014 -0300
media: Remove references to non-existent PLAT_S5P symbol
commit 098bcd2335f0824e76dd835e4e2b7ae8e38fc281 upstream.
The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). However, there
are still some references to that symbol left, fix that by
substituting them with ARCH_S5PV210.
Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 020882d3716211e0801c9c0543bf69580895c225
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 30 10:35:00 2014 +1100
mm: Remove false WARN_ON from pagecache_isize_extended()
commit f55fefd1a5a339b1bd08c120b93312d6eb64a9fb upstream.
The WARN_ON checking whether i_mutex is held in
pagecache_isize_extended() was wrong because some filesystems (e.g.
XFS) use different locks for serialization of truncates / writes. So
just remove the check.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f3cacd25d3b3f626dcd12df1bd93851e48076a36
Author: Andy Lutomirski <luto@amacapital.net>
Date: Wed Oct 15 10:12:07 2014 -0700
x86, apic: Handle a bad TSC more gracefully
commit b47dcbdc5161d3d5756f430191e2840d9b855492 upstream.
If the TSC is unusable or disabled, then this patch fixes:
- Confusion while trying to clear old APIC interrupts.
- Division by zero and incorrect programming of the TSC deadline
timer.
This fixes boot if the CPU has a TSC deadline timer but a missing or
broken TSC. The failure to boot can be observed with qemu using
-cpu qemu64,-tsc,+tsc-deadline
This also happens to me in nested KVM for unknown reasons.
With this patch, I can boot cleanly (although without a TSC).
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Cc: Bandan Das <bsd@redhat.com>
Link: http://lkml.kernel.org/r/e2fa274e498c33988efac0ba8b7e3120f7f92d78.1413393027.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a91da4eefe313bbd39c855fdb5b1765c85731d7a
Author: Mathias Krause <minipli@googlemail.com>
Date: Sat Oct 4 23:06:39 2014 +0200
posix-timers: Fix stack info leak in timer_create()
commit 6891c4509c792209c44ced55a60f13954cb50ef4 upstream.
If userland creates a timer without specifying a sigevent info, we'll
create one ourself, using a stack local variable. Particularly will we
use the timer ID as sival_int. But as sigev_value is a union containing
a pointer and an int, that assignment will only partially initialize
sigev_value on systems where the size of a pointer is bigger than the
size of an int. On such systems we'll copy the uninitialized stack bytes
from the timer_create() call to userland when the timer actually fires
and we're going to deliver the signal.
Initialize sigev_value with 0 to plug the stack info leak.
Found in the PaX patch, written by the PaX Team.
Fixes: 5a9fa7307285 ("posix-timers: kill ->it_sigev_signo and...")
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Brad Spengler <spender@grsecurity.net>
Cc: PaX Team <pageexec@freemail.hu>
Link: http://lkml.kernel.org/r/1412456799-32339-1-git-send-email-minipli@googlemail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 255a8e963ea7d9d856d224a76b8a2fb99f0682fe
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu Oct 23 01:23:01 2014 +0200
mtd: cfi_cmdset_0001.c: fix resume for LH28F640BF chips
commit 89cf38dd536a7301d6b5f5ddd73f42074c01bfaa upstream.
After '#echo mem > /sys/power/state' some devices can not be properly resumed
because apparently the MTD Partition Configuration Register has been reset
to default thus the rootfs cannot be mounted cleanly on resume.
An example of this can be found in the SA-1100 Developer's Manual at 9.5.3.3
where the second step of the Sleep Shutdown Sequence is described:
"An internal reset is applied to the SA-1100. All units are reset...".
As workaround we refresh the PCR value as done initially on chip setup.
This behavior and the fix are confirmed by our tests done on 2 different Zaurus
collie units with kernel 3.17.
Fixes: 812c5fa82bae: ("mtd: cfi_cmdset_0001.c: add support for Sharp LH28F640BF NOR")
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b68f7682f44451c86c693452aabb2226a69c8efc
Author: Karl Beldan <karl.beldan@rivierawaves.com>
Date: Mon Oct 13 14:34:41 2014 +0200
mac80211: fix typo in starting baserate for rts_cts_rate_idx
commit c7abf25af0f41be4b50d44c5b185d52eea360cb8 upstream.
It affects non-(V)HT rates and can lead to selecting an rts_cts rate
that is not a basic rate or way superior to the reference rate (ATM
rates[0] used for the 1st attempt of the protected frame data).
E.g, assuming drivers register growing (bitrate) sorted tables of
ieee80211_rate-s, having :
- rates[0].idx == d'2 and basic_rates == b'10100
will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise
- rates[0].idx == d'2 and basic_rates == b'10001
will select rts_cts idx b'10000
The first is not a basic rate and the second is > rates[0].
Also, wrt severity of the addressed misbehavior, ATM we only have one
rts_cts_rate_idx rather than one per rate table entry, so this idx might
still point to bitrates > rates[1..MAX_RATES].
Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates")
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2894a3a2bcb91959207376484c6c4d01ce605e73
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Mon Oct 20 15:10:40 2014 +0100
staging: comedi: fix memory leak / bad pointer freeing for chanlist
commit 238b5ad855924919e5b98d0c772d9dc78795639b upstream.
As a follow-up to commit 6cab7a37f5c04 ("staging: comedi: (regression)
channel list must be set for COMEDI_CMD ioctl"), Hartley Sweeten pointed
out another couple of bugs stemming from commit 6cab7a37f5c04 ("staging:
comedi: comedi_fops: introduce __comedi_get_user_chanlist()").
Firstly, `do_cmdtest_ioctl()` never frees the kernel copy of the user
chanlist allocated by `__comedi_get_user_chanlist()`, so that memory is
leaked. Fix it by freeing the allocated kernel memory pointed to by
`cmd.chanlist` before that pointer is overwritten with its original
pointer to user memory before `cmd` is copied back to user-space.
Secondly, if `__comedi_get_user_chanlist()` returns an error,
`cmd->chanlist` is left unchanged and in fact will be a pointer to user
memory. This causes `do_cmd_ioctl()` to `goto cleanup` and call
`do_become_nonbusy()` which would attempt to free the memory pointed to
by the user-space pointer. Fix it by setting `cmd->chanlist` to NULL at
the start of `__comedi_get_user_chanlist()`.
Fixes: c6cd0eefb27b ("staging: comedi: comedi_fops: introduce __comedi_get_user_chanlist()")
Reported-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 50b784c20405c44f5d3b3444dc66915d4901f790
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Wed Oct 8 16:09:14 2014 +0100
staging: comedi: (regression) channel list must be set for COMEDI_CMD ioctl
commit 6cab7a37f5c048bb2a768f24b0ec748b052fda09 upstream.
`do_cmd_ioctl()`, the handler for the `COMEDI_CMD` ioctl can incorrectly
call the Comedi subdevice's `do_cmd()` handler with a NULL channel list
pointer. This is a regression as the `do_cmd()` handler has never been
expected to deal with that, leading to a kernel OOPS when it tries to
dereference it.
A NULL channel list pointer is allowed for the `COMEDI_CMDTEST` ioctl,
handled by `do_cmdtest_ioctl()` and the subdevice's `do_cmdtest()`
handler, but not for the `COMEDI_CMD` ioctl and its handlers.
Both `do_cmd_ioctl()` and `do_cmdtest_ioctl()` call
`__comedi_get_user_chanlist()` to copy the channel list from user memory
into dynamically allocated kernel memory and check it for consistency.
That function currently returns 0 if the `user_chanlist` parameter
(pointing to the channel list in user memory) is NULL. That's fine for
`do_cmdtest_ioctl()`, but `do_cmd_ioctl()` incorrectly assumes the
kernel copy of the channel list has been set-up correctly.
Fix it by not allowing the `user_chanlist` parameter to be NULL in
`__comedi_get_user_chanlist()`, and only calling it from
`do_cmdtest_ioctl()` if the parameter is non-NULL.
Thanks to Bernd Porr for reporting the bug via an initial patch sent
privately.
Fixes: c6cd0eefb27b ("staging: comedi: comedi_fops: introduce __comedi_get_user_chanlist()")
Reported-by: Bernd Porr <mail@berndporr.me.uk>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Bernd Porr <mail@berndporr.me.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0d069ea06ee8c0ff6441ff8c37d494b6b8d26a7
Author: Imre Deak <imre.deak@intel.com>
Date: Fri Oct 24 20:29:10 2014 +0300
PM / Sleep: fix recovery during resuming from hibernation
commit 94fb823fcb4892614f57e59601bb9d4920f24711 upstream.
If a device's dev_pm_ops::freeze callback fails during the QUIESCE
phase, we don't rollback things correctly calling the thaw and complete
callbacks. This could leave some devices in a suspended state in case of
an error during resuming from hibernation.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1e08aeb6b8b2f414f9143f1644d2d6d5ae728b4c
Author: Imre Deak <imre.deak@intel.com>
Date: Fri Oct 24 20:29:09 2014 +0300
PM / Sleep: fix async suspend_late/freeze_late error handling
commit 246ef766743618a7cab059d6c4993270075b173e upstream.
If an asynchronous suspend_late or freeze_late callback fails
during the SUSPEND, FREEZE or QUIESCE phases, we don't propagate the
corresponding error correctly, in effect ignoring the error and
continuing the suspend-to-ram/hibernation. During suspend-to-ram this
could leave some devices without a valid saved context, leading to a
failure to reinitialize them during resume. During hibernation this
could leave some devices active interfeering with the creation /
restoration of the hibernation image. Also this could leave the
corresponding devices without a valid saved context and failure to
reinitialize them during resume.
Fixes: de377b397272 (PM / sleep: Asynchronous threads for suspend_late)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 256f2021526c801377ce633da45617b5fc51d5d3
Author: Peter Hurley <peter@hurleysoftware.com>
Date: Thu Oct 16 13:51:30 2014 -0400
tty: Fix high cpu load if tty is unreleaseable
commit 37b164578826406a173ca7c20d9ba7430134d23e upstream.
Kernel oops can cause the tty to be unreleaseable (for example, if
n_tty_read() crashes while on the read_wait queue). This will cause
tty_release() to endlessly loop without sleeping.
Use a killable sleep timeout which grows by 2n+1 jiffies over the interval
[0, 120 secs.) and then jumps to forever (but still killable).
NB: killable just allows for the task to be rewoken manually, not
to be terminated.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 13969e13b09009c2f56082954b4dc0ce9dea39e3
Author: Imre Deak <imre.deak@intel.com>
Date: Thu Oct 2 16:34:31 2014 +0300
tty/vt: don't set font mappings on vc not supporting this
commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream.
We can call this function for a dummy console that doesn't support
setting the font mapping, which will result in a null ptr BUG. So check
for this case and return error for consoles w/o font mapping support.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1f4f91373870dcbb80bcce2702b9ad84c9740680
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 22 09:06:49 2014 +0200
quota: Properly return errors from dquot_writeback_dquots()
commit 474d2605d119479e5aa050f738632e63589d4bb5 upstream.
Due to a switched left and right side of an assignment,
dquot_writeback_dquots() never returned error. This could result in
errors during quota writeback to not be reported to userspace properly.
Fix it.
Coverity-id: 1226884
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bfa72302e63fc374c706495b53a5b2e69db043a8
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Oct 30 09:30:28 2014 -0700
PCI: Rename sysfs 'enabled' file back to 'enable'
commit d8e7d53a2fc14e0830ab728cb84ee19933d3ac8d upstream.
Back in commit 5136b2da770d ("PCI: convert bus code to use dev_groups"),
I misstyped the 'enable' sysfs filename as 'enabled', which broke the
userspace API. This patch fixes that issue by renaming the file back.
Fixes: 5136b2da770d ("PCI: convert bus code to use dev_groups")
Reported-by: Jeff Epler <jepler@unpythonic.net>
Tested-by: Jeff Epler <jepler@unpythonic.net> # on v3.14-rt
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
commit 86b33722a8fe7c34ebebfa943c0712ef4f83f42f
Author: Jan Kara <jack@suse.cz>
Date: Tue Sep 16 22:23:10 2014 +0200
ext3: Don't check quota format when there are no quota files
commit 7938db449bbc55bbeb164bec7af406212e7e98f1 upstream.
The check whether quota format is set even though there are no
quota files with journalled quota is pointless and it actually
makes it impossible to turn off journalled quotas (as there's
no way to unset journalled quota format). Just remove the check.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0965c1e9446deea8190c4ebeec5e1d22a3b15b1f
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Mon Oct 20 08:29:55 2014 +0300
Revert "iwlwifi: mvm: treat EAPOLs like mgmt frames wrt rate"
commit 1ffde699aae127e7abdb98dbdedc2cc6a973a1a1 upstream.
This reverts commit aa11bbf3df026d6b1c6b528bef634fd9de7c2619.
This commit was causing connection issues and is not needed
if IWL_MVM_RS_RSSI_BASED_INIT_RATE is set to false by default.
Regardless of the issues mentioned above, this patch added the
following WARNING:
WARNING: CPU: 0 PID: 3946 at drivers/net/wireless/iwlwifi/mvm/tx.c:190 iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]()
Got an HT rate for a non data frame 0x8
CPU: 0 PID: 3946 Comm: wpa_supplicant Tainted: G O 3.17.0+ #6
Hardware name: LENOVO 20ANCTO1WW/20ANCTO1WW, BIOS GLET71WW (2.25 ) 07/02/2014
0000000000000009 ffffffff814fa911 ffff8804288db8f8 ffffffff81064f52
0000000000001808 ffff8804288db948 ffff88040add8660 ffff8804291b5600
0000000000000000 ffffffff81064fb7 ffffffffa07b73d0 0000000000000020
Call Trace:
[<ffffffff814fa911>] ? dump_stack+0x41/0x51
[<ffffffff81064f52>] ? warn_slowpath_common+0x72/0x90
[<ffffffff81064fb7>] ? warn_slowpath_fmt+0x47/0x50
[<ffffffffa07a39ea>] ? iwl_mvm_set_tx_params+0x60a/0x6f0 [iwlmvm]
[<ffffffffa07a3cf8>] ? iwl_mvm_tx_skb+0x48/0x3c0 [iwlmvm]
[<ffffffffa079cb9b>] ? iwl_mvm_mac_tx+0x7b/0x180 [iwlmvm]
[<ffffffffa0746ce9>] ? __ieee80211_tx+0x2b9/0x3c0 [mac80211]
[<ffffffffa07492f3>] ? ieee80211_tx+0xb3/0x100 [mac80211]
[<ffffffffa0749c49>] ? ieee80211_subif_start_xmit+0x459/0xca0 [mac80211]
[<ffffffff814116e7>] ? dev_hard_start_xmit+0x337/0x5f0
[<ffffffff81430d46>] ? sch_direct_xmit+0x96/0x1f0
[<ffffffff81411ba3>] ? __dev_queue_xmit+0x203/0x4f0
[<ffffffff8142f670>] ? ether_setup+0x70/0x70
[<ffffffff814e96a1>] ? packet_sendmsg+0xf81/0x1110
[<ffffffff8140625c>] ? skb_free_datagram+0xc/0x40
[<ffffffff813f7538>] ? sock_sendmsg+0x88/0xc0
[<ffffffff813f7274>] ? move_addr_to_kernel.part.20+0x14/0x60
[<ffffffff811c47c2>] ? __inode_wait_for_writeback+0x62/0xb0
[<ffffffff813f7a91>] ? SYSC_sendto+0xf1/0x180
[<ffffffff813f88f9>] ? __sys_recvmsg+0x39/0x70
[<ffffffff8150066d>] ? system_call_fastpath+0x1a/0x1f
---[ end trace cc19a150d311fc63 ]---
which was reported here: https://bugzilla.kernel.org/show_bug.cgi?id=85691
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 989d3425e2b1ecf7f24635faa09f13d8a6e90085
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Sun Oct 5 09:11:14 2014 +0300
iwlwifi: dvm: drop non VO frames when flushing
commit a0855054e59b0c5b2b00237fdb5147f7bcc18efb upstream.
When mac80211 wants to ensure that a frame is sent, it calls
the flush() callback. Until now, iwldvm implemented this by
waiting that all the frames are sent (ACKed or timeout).
In case of weak signal, this can take a significant amount
of time, delaying the next connection (in case of roaming).
Many users have reported that the flush would take too long
leading to the following error messages to be printed:
iwlwifi 0000:03:00.0: fail to flush all tx fifo queues Q 2
iwlwifi 0000:03:00.0: Current SW read_ptr 161 write_ptr 201
iwl data: 00000000: 00 00 00 00 00 00 00 00 fe ff 01 00 00 00 00 00
[snip]
iwlwifi 0000:03:00.0: FH TRBs(0) = 0x00000000
[snip]
iwlwifi 0000:03:00.0: Q 0 is active and mapped to fifo 3 ra_tid 0x0000 [9,9]
[snip]
Instead of waiting for these packets, simply drop them. This
significantly improves the responsiveness of the network.
Note that all the queues are flushed, but the VO one. This
is not typically used by the applications and it likely
contains management frames that are useful for connection
or roaming.
This bug is tracked here:
https://bugzilla.kernel.org/show_bug.cgi?id=56581
But it is duplicated in distributions' trackers.
A simple search in Ubuntu's database led to these bugs:
https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1270808
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305406
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1356236
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1360597
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1361809
Depends-on: 77be2c54c5bd ("mac80211: add vif to flush call")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 00a34d9966420ef526dc921737b251132d9230bb
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Tue Sep 23 23:02:41 2014 +0300
iwlwifi: configure the LTR
commit 9180ac50716a097a407c6d7e7e4589754a922260 upstream.
The LTR is the handshake between the device and the root
complex about the latency allowed when the bus exits power
save. This configuration was missing and this led to high
latency in the link power up. The end user could experience
high latency in the network because of this.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b910c294ca00c9ccb7de775159d5b1a49e4076da
Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Date: Mon Sep 22 16:12:24 2014 +0300
iwlwifi: mvm: BT Coex - update the MPLUT Boost register value
commit d14b28fd2c61af0bf310230472e342864d799c98 upstream.
Fixes: 2adc8949efab ("iwlwifi: mvm: BT Coex - fix boost register / LUT values")
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b64b8390ffc305631302e6f9f3b5c1f7fe5efa4f
Author: Will Deacon <will.deacon@arm.com>
Date: Tue Oct 28 13:16:28 2014 -0700
zap_pte_range: update addr when forcing flush after TLB batching faiure
commit ce9ec37bddb633404a0c23e1acb181a264e7f7f2 upstream.
When unmapping a range of pages in zap_pte_range, the page being
unmapped is added to an mmu_gather_batch structure for asynchronous
freeing. If we run out of space in the batch structure before the range
has been completely unmapped, then we break out of the loop, force a
TLB flush and free the pages that we have batched so far. If there are
further pages to unmap, then we resume the loop where we left off.
Unfortunately, we forget to update addr when we break out of the loop,
which causes us to truncate the range being invalidated as the end
address is exclusive. When we re-enter the loop at the same address, the
page has already been freed and the pte_present test will fail, meaning
that we do not reconsider the address for invalidation.
This patch fixes the problem by incrementing addr by the PAGE_SIZE
before breaking out of the loop on batch failure.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5880e5b33ad72055ade94aa052b384326a8aad54
Author: J. Bruce Fields <bfields@redhat.com>
Date: Wed Oct 22 14:46:29 2014 -0400
nfsd4: fix crash on unknown operation number
commit 51904b08072a8bf2b9ed74d1bd7a5300a614471d upstream.
Unknown operation numbers are caught in nfsd4_decode_compound() which
sets op->opnum to OP_ILLEGAL and op->status to nfserr_op_illegal. The
error causes the main loop in nfsd4_proc_compound() to skip most
processing. But nfsd4_proc_compound also peeks ahead at the next
operation in one case and doesn't take similar precautions there.
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6aba9ec80f4f80302af41c83033b5c45540fc092
Author: J. Bruce Fields <bfields@redhat.com>
Date: Thu Aug 21 15:04:31 2014 -0400
nfsd4: fix response size estimation for OP_SEQUENCE
commit d1d84c9626bb3a519863b3ffc40d347166f9fb83 upstream.
We added this new estimator function but forgot to hook it up. The
effect is that NFSv4.1 (and greater) won't do zero-copy reads.
The estimate was also wrong by 8 bytes.
Fixes: ccae70a9ee41 "nfsd4: estimate sequence response size"
Reported-by: Chuck Lever <chucklever@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ff3483aa1cf792438351a443a7c78e6e3c227c91
Author: Jason Baron <jbaron@akamai.com>
Date: Wed Oct 15 20:47:28 2014 +0000
cpc925_edac: Report UE events properly
commit fa19ac4b92bc2b5024af3e868f41f81fa738567a upstream.
Fix UE event being reported as HW_EVENT_ERR_CORRECTED.
Signed-off-by: Jason Baron <jbaron@akamai.com>
Link: http://lkml.kernel.org/r/8beb13803500076fef827eab33d523e355d83759.1413405053.git.jbaron@akamai.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0132e4c042dcba59fd626f35f572d2791a1ea122
Author: Jason Baron <jbaron@akamai.com>
Date: Sat Oct 18 16:06:32 2014 +0200
e7xxx_edac: Report CE events properly
commit 8030122a9ccf939186f8db96c318dbb99b5463f6 upstream.
Fix CE event being reported as HW_EVENT_ERR_UNCORRECTED.
Signed-off-by: Jason Baron <jbaron@akamai.com>
Link: http://lkml.kernel.org/r/e6dd616f2cd51583a7e77af6f639b86313c74144.1413405053.git.jbaron@akamai.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5142ef1457b6aa2b7afc84e0ac13ee132d7e32d4
Author: Jason Baron <jbaron@akamai.com>
Date: Wed Oct 15 20:47:21 2014 +0000
i3200_edac: Report CE events properly
commit 8a3f075d6c9b3612b4a5fb2af8db82b38b20caf0 upstream.
Fix CE event being reported as HW_EVENT_ERR_UNCORRECTED.
Signed-off-by: Jason Baron <jbaron@akamai.com>
Link: http://lkml.kernel.org/r/d02465b4f30314b390c12c061502eda5e9d29c52.1413405053.git.jbaron@akamai.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 279df118a9f3e5cd2c0172740f92c71eaa74fc81
Author: Jason Baron <jbaron@akamai.com>
Date: Wed Oct 15 20:47:24 2014 +0000
i82860_edac: Report CE events properly
commit ab0543de6ff0877474f57a5aafbb51a61e88676f upstream.
Fix CE event being reported as HW_EVENT_ERR_UNCORRECTED.
Signed-off-by: Jason Baron <jbaron@akamai.com>
Link: http://lkml.kernel.org/r/7aee8e244a32ff86b399a8f966c4aae70296aae0.1413405053.git.jbaron@akamai.com
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69700c4380479d395fee66d56d6d0ba8f1d22d07
Author: Christoph Hellwig <hch@lst.de>
Date: Sun Oct 19 17:13:58 2014 +0200
scsi: set REQ_QUEUE for the blk-mq case
commit b1dd2aac4cc0892b82ec60232ed37e3b0af776cc upstream.
To generate the right SPI tag messages we need to properly set
QUEUE_FLAG_QUEUED in the request_queue and mirror it to the
request.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a58c28f66aca396c19f297b6c29835971a1e2886
Author: Tony Battersby <tonyb@cybernetics.com>
Date: Thu Oct 23 15:10:21 2014 -0400
lib/scatterlist: fix memory leak with scsi-mq
commit c21e59d8dc04b2107bdb4ff0f412a9b7ae3349f3 upstream.
Fix a memory leak with scsi-mq triggered by commands with large data
transfer length.
Fixes: c53c6d6a68b1 ("scatterlist: allow chaining to preallocated chunks")
Signed-off-by: Tony Battersby <tonyb@cybernetics.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 37ca06e5d8cfe85d810c93a58fd429265adf8935
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 22 20:13:39 2014 -0600
scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND
commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream.
When sg_scsi_ioctl() fails to prepare request to submit in
blk_rq_map_kern() we jump to a label where we just end up copying
(luckily zeroed-out) kernel buffer to userspace instead of reporting
error. Fix the problem by jumping to the right label.
CC: Jens Axboe <axboe@kernel.dk>
CC: linux-scsi@vger.kernel.org
Coverity-id: 1226871
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed up the, now unused, out label.
Signed-off-by: Jens Axboe <axboe@fb.com>
commit 0a6a5ef4b5562059929955a614643275f7543e53
Author: Hans de Goede <hdegoede@redhat.com>
Date: Tue Oct 28 11:05:29 2014 +0100
xhci: Disable streams on Asmedia 1042 xhci controllers
commit 2391eacbd00b706ff4902db7dbee21e33b6f1850 upstream.
Streams seem to be broken on the Asmedia 1042. An uas capable Seagate disk
which is known to work fine with other controllers causes the system to freeze
when connected over usb-3 with this controller, where as it works fine with
uas in usb-2 ports, indicating a problem with streams.
This is a bit bigger hammer then I would like to use for this, but for now it
will have to make do. I've ordered a pci-e usb controller card with an Asmedia
1042, once that arrives I'll try to get streams to work (with a quirk flag if
necessary) and then we can re-enable them. For now this at least makes uas
capable disk enclosures work again by forcing fallback to the usb-storage
driver.
Reported-by: Bogdan Mihalcea <bogdan.mihalcea@infim.ro>
Cc: Bogdan Mihalcea <bogdan.mihalcea@infim.ro>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e47dc24f7a439afe500560ac78f072ecccd87dcd
Author: Oliver Neukum <oneukum@suse.de>
Date: Mon Oct 27 14:53:29 2014 +0100
xhci: no switching back on non-ULT Haswell
commit b45abacde3d551c6696c6738bef4a1805d0bf27a upstream.
The switch back is limited to ULT even on HP. The contrary
finding arose by bad luck in BIOS versions for testing.
This fixes spontaneous resume from S3 on some HP laptops.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 059bbdea07f9d0754ff2bcae3b9022fa438d5a32
Author: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Date: Wed Oct 29 14:51:02 2014 -0700
mm/balloon_compaction: fix deflation when compaction is disabled
commit 4d88e6f7d5ffc84e6094a47925870f4a130555c2 upstream.
If CONFIG_BALLOON_COMPACTION=n balloon_page_insert() does not link pages
with balloon and doesn't set PagePrivate flag, as a result
balloon_page_dequeue() cannot get any pages because it thinks that all
of them are isolated. Without balloon compaction nobody can isolate
ballooned pages. It's safe to remove this check.
Fixes: d6d86c0a7f8d ("mm/balloon_compaction: redesign ballooned pages management").
Signed-off-by: Konstantin Khlebnikov <k.khlebnikov@samsung.com>
Reported-by: Matt Mullins <mmullins@mmlx.us>
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>
commit 9acc5316a7059f2bcdac2cb37c1d95a8b0702b26
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 29 14:50:44 2014 -0700
lib/bitmap.c: fix undefined shift in __bitmap_shift_{left|right}()
commit ea5d05b34aca25c066e0699512d0ffbd8ee6ac3e upstream.
If __bitmap_shift_left() or __bitmap_shift_right() are asked to shift by
a multiple of BITS_PER_LONG, they will try to shift a long value by
BITS_PER_LONG bits which is undefined. Change the functions to avoid
the undefined shift.
Coverity id: 1192175
Coverity id: 1192174
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.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>
commit ad4f6f87fd8a2d62a095203c42f460e07c8e9523
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Wed Oct 29 14:50:48 2014 -0700
mm: memcontrol: fix missed end-writeback page accounting
commit d7365e783edb858279be1d03f61bc8d5d3383d90 upstream.
Commit 0a31bc97c80c ("mm: memcontrol: rewrite uncharge API") changed
page migration to uncharge the old page right away. The page is locked,
unmapped, truncated, and off the LRU, but it could race with writeback
ending, which then doesn't unaccount the page properly:
test_clear_page_writeback() migration
wait_on_page_writeback()
TestClearPageWriteback()
mem_cgroup_migrate()
clear PCG_USED
mem_cgroup_update_page_stat()
if (PageCgroupUsed(pc))
decrease memcg pages under writeback
release pc->mem_cgroup->move_lock
The per-page statistics interface is heavily optimized to avoid a
function call and a lookup_page_cgroup() in the file unmap fast path,
which means it doesn't verify whether a page is still charged before
clearing PageWriteback() and it has to do it in the stat update later.
Rework it so that it looks up the page's memcg once at the beginning of
the transaction and then uses it throughout. The charge will be
verified before clearing PageWriteback() and migration can't uncharge
the page as long as that is still set. The RCU lock will protect the
memcg past uncharge.
As far as losing the optimization goes, the following test results are
from a microbenchmark that maps, faults, and unmaps a 4GB sparse file
three times in a nested fashion, so that there are two negative passes
that don't account but still go through the new transaction overhead.
There is no actual difference:
old: 33.195102545 seconds time elapsed ( +- 0.01% )
new: 33.199231369 seconds time elapsed ( +- 0.03% )
The time spent in page_remove_rmap()'s callees still adds up to the
same, but the time spent in the function itself seems reduced:
# Children Self Command Shared Object Symbol
old: 0.12% 0.11% filemapstress [kernel.kallsyms] [k] page_remove_rmap
new: 0.12% 0.08% filemapstress [kernel.kallsyms] [k] page_remove_rmap
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Vladimir Davydov <vdavydov@parallels.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>
commit 48c8f5c0326205aac6b12e8cec2c9e26659d49dc
Author: Johannes Weiner <hannes@cmpxchg.org>
Date: Wed Oct 29 14:50:46 2014 -0700
mm: page-writeback: inline account_page_dirtied() into single caller
commit 3a3c02ecf7f2852f122d6d16fb9b3d9cb0c6f201 upstream.
A follow-up patch would have changed the call signature. To save the
trouble, just fold it instead.
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Vladimir Davydov <vdavydov@parallels.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>
commit b2859290da744942fba7cf8f52e533a51aaecd8d
Author: Wang Nan <wangnan0@huawei.com>
Date: Wed Oct 29 14:50:18 2014 -0700
cgroup/kmemleak: add kmemleak_free() for cgroup deallocations.
commit 401507d67d5c2854f5a88b3f93f64fc6f267bca5 upstream.
Commit ff7ee93f4715 ("cgroup/kmemleak: Annotate alloc_page() for cgroup
allocations") introduces kmemleak_alloc() for alloc_page_cgroup(), but
corresponding kmemleak_free() is missing, which makes kmemleak be
wrongly disabled after memory offlining. Log is pasted at the end of
this commit message.
This patch add kmemleak_free() into free_page_cgroup(). During page
offlining, this patch removes corresponding entries in kmemleak rbtree.
After that, the freed memory can be allocated again by other subsystems
without killing kmemleak.
bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak
Offlined Pages 32768
kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing)
CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86
Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
Call Trace:
dump_stack+0x46/0x58
create_object+0x266/0x2c0
kmemleak_alloc+0x26/0x50
kmem_cache_alloc+0xd3/0x160
__sigqueue_alloc+0x49/0xd0
__send_signal+0xcb/0x410
send_signal+0x45/0x90
__group_send_sig_info+0x13/0x20
do_notify_parent+0x1bb/0x260
do_exit+0x767/0xa40
do_group_exit+0x44/0xa0
SyS_exit_group+0x17/0x20
system_call_fastpath+0x16/0x1b
kmemleak: Kernel memory leak detector disabled
kmemleak: Object 0xffff880016900000 (size 524288):
kmemleak: comm "swapper/0", pid 0, jiffies 4294667296
kmemleak: min_count = 0
kmemleak: count = 0
kmemleak: flags = 0x1
kmemleak: checksum = 0
kmemleak: backtrace:
log_early+0x63/0x77
kmemleak_alloc+0x4b/0x50
init_section_page_cgroup+0x7f/0xf5
page_cgroup_init+0xc5/0xd0
start_kernel+0x333/0x408
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0xf5/0xfc
Fixes: ff7ee93f4715 (cgroup/kmemleak: Annotate alloc_page() for cgroup allocations)
Signed-off-by: Wang Nan <wangnan0@huawei.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Michal Hocko <mhocko@suse.cz>
Cc: Steven Rostedt <rostedt@goodmis.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>
commit 6224c2ff6109c817f17400ed9f85ffbd0790b20d
Author: Yu Zhao <yuzhao@google.com>
Date: Wed Oct 29 14:50:26 2014 -0700
mm: free compound page with correct order
commit 5ddacbe92b806cd5b4f8f154e8e46ac267fff55c upstream.
Compound page should be freed by put_page() or free_pages() with correct
order. Not doing so will cause tail pages leaked.
The compound order can be obtained by compound_order() or use
HPAGE_PMD_ORDER in our case. Some people would argue the latter is
faster but I prefer the former which is more general.
This bug was observed not just on our servers (the worst case we saw is
11G leaked on a 48G machine) but also on our workstations running Ubuntu
based distro.
$ cat /proc/vmstat | grep thp_zero_page_alloc
thp_zero_page_alloc 55
thp_zero_page_alloc_failed 0
This means there is (thp_zero_page_alloc - 1) * (2M - 4K) memory leaked.
Fixes: 97ae17497e99 ("thp: implement refcounting for huge zero page")
Signed-off-by: Yu Zhao <yuzhao@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: David Rientjes <rientjes@google.com>
Cc: Bob Liu <lliubbo@gmail.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>
commit 2d84e2a9cacd6dcf3fb440bfd06780772b59efcc
Author: Andriy Skulysh <askulysh@gmail.com>
Date: Wed Oct 29 14:50:59 2014 -0700
sh: fix sh770x SCIF memory regions
commit 5417421b270229bfce0795ccc99a4b481e4954ca upstream.
Resources scif1_resources & scif2_resources overlap. Actual SCIF region
size is 0x10.
This is regression from commit d850acf975be ("sh: Declare SCIF register
base and IRQ as resources")
Signed-off-by: Andriy Skulysh <askulysh@gmail.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.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>
commit 8b73572a1ee99496ef3b78e681205ec8a59e7f17
Author: Dmitry Kasatkin <d.kasatkin@samsung.com>
Date: Tue Oct 28 13:31:22 2014 +0200
ima: check xattr value length and type in the ima_inode_setxattr()
commit a48fda9de94500a3152a56b723d0a64ae236547c upstream.
ima_inode_setxattr() can be called with no value. Function does not
check the length so that following command can be used to produce
kernel oops: setfattr -n security.ima FOO. This patch fixes it.
Changes in v3:
* for stable reverted "allow setting hash only in fix or log mode"
It will be a separate patch.
Changes in v2:
* testing validity of xattr type
* allow setting hash only in fix or log mode (Mimi)
[ 261.562522] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 261.564109] IP: [<ffffffff812af272>] ima_inode_setxattr+0x3e/0x5a
[ 261.564109] PGD 3112f067 PUD 42965067 PMD 0
[ 261.564109] Oops: 0000 [#1] SMP
[ 261.564109] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse
[ 261.564109] CPU: 0 PID: 3299 Comm: setxattr Not tainted 3.16.0-kds+ #2924
[ 261.564109] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 261.564109] task: ffff8800428c2430 ti: ffff880042be0000 task.ti: ffff880042be0000
[ 261.564109] RIP: 0010:[<ffffffff812af272>] [<ffffffff812af272>] ima_inode_setxattr+0x3e/0x5a
[ 261.564109] RSP: 0018:ffff880042be3d50 EFLAGS: 00010246
[ 261.564109] RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000015
[ 261.564109] RDX: 0000001500000000 RSI: 0000000000000000 RDI: ffff8800375cc600
[ 261.564109] RBP: ffff880042be3d68 R08: 0000000000000000 R09: 00000000004d6256
[ 261.564109] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88002149ba00
[ 261.564109] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 261.564109] FS: 00007f6c1e219740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000
[ 261.564109] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 261.564109] CR2: 0000000000000000 CR3: 000000003b35a000 CR4: 00000000000006f0
[ 261.564109] Stack:
[ 261.564109] ffff88002149ba00 ffff880042be3df8 0000000000000000 ffff880042be3d98
[ 261.564109] ffffffff812a101b ffff88002149ba00 ffff880042be3df8 0000000000000000
[ 261.564109] 0000000000000000 ffff880042be3de0 ffffffff8116d08a ffff880042be3dc8
[ 261.564109] Call Trace:
[ 261.564109] [<ffffffff812a101b>] security_inode_setxattr+0x48/0x6a
[ 261.564109] [<ffffffff8116d08a>] vfs_setxattr+0x6b/0x9f
[ 261.564109] [<ffffffff8116d1e0>] setxattr+0x122/0x16c
[ 261.564109] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45
[ 261.564109] [<ffffffff8114d011>] ? __sb_start_write+0x10f/0x143
[ 261.564109] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45
[ 261.564109] [<ffffffff811687c0>] ? __mnt_want_write+0x48/0x4f
[ 261.564109] [<ffffffff8116d3e6>] SyS_setxattr+0x6e/0xb0
[ 261.564109] [<ffffffff81529da9>] system_call_fastpath+0x16/0x1b
[ 261.564109] Code: 48 89 f7 48 c7 c6 58 36 81 81 53 31 db e8 73 27 04 00 85 c0 75 28 bf 15 00 00 00 e8 8a a5 d9 ff 84 c0 75 05 83 cb ff eb 15 31 f6 <41> 80 7d 00 03 49 8b 7c 24 68 40 0f 94 c6 e8 e1 f9 ff ff 89 d8
[ 261.564109] RIP [<ffffffff812af272>] ima_inode_setxattr+0x3e/0x5a
[ 261.564109] RSP <ffff880042be3d50>
[ 261.564109] CR2: 0000000000000000
[ 261.599998] ---[ end trace 39a89a3fc267e652 ]---
Reported-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2bedd937c98ebd1ec3d749b436738acd473e3cb4
Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
Date: Tue Oct 7 11:12:07 2014 +0200
usb: Remove references to non-existent PLAT_S5P symbol
commit cd6e245a2d061a8367e37aaece32cf3fc922de80 upstream.
The PLAT_S5P Kconfig symbol was removed in commit d78c16ccde96
("ARM: SAMSUNG: Remove remaining legacy code"). There are still
some references left, fix that by replacing them with ARCH_S5PV210.
Fixes: d78c16ccde96 ("ARM: SAMSUNG: Remove remaining legacy code")
Reported-by: Paul Bolle <pebolle@tiscali.nl>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d3d02c1696542928b5743ab14de6c7024036a172
Author: Johan Hovold <johan@kernel.org>
Date: Wed Oct 29 09:07:30 2014 +0100
USB: kobil_sct: fix non-atomic allocation in write path
commit 191252837626fca0de694c18bb2aa64c118eda89 upstream.
Write may be called from interrupt context so make sure to use
GFP_ATOMIC for all allocations in write.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce3261f9f1f190a296ef27b578e3d36c2fe75d6d
Author: Hans de Goede <hdegoede@redhat.com>
Date: Wed Oct 1 11:29:14 2014 +0200
usb: Do not allow usb_alloc_streams on unconfigured devices
commit 90a646c770c50cc206ceba0d7b50453c46c13c36 upstream.
This commit fixes the following oops:
[10238.622067] scsi host3: uas_eh_bus_reset_handler start
[10240.766164] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
[10245.779365] usb 3-4: device descriptor read/8, error -110
[10245.883331] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd
[10250.897603] usb 3-4: device descriptor read/8, error -110
[10251.058200] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
[10251.058244] IP: [<ffffffff815ac6e1>] xhci_check_streams_endpoint+0x91/0x140
<snip>
[10251.059473] Call Trace:
[10251.059487] [<ffffffff815aca6c>] xhci_calculate_streams_and_bitmask+0xbc/0x130
[10251.059520] [<ffffffff815aeb5f>] xhci_alloc_streams+0x10f/0x5a0
[10251.059548] [<ffffffff810a4685>] ? check_preempt_curr+0x75/0xa0
[10251.059575] [<ffffffff810a46dc>] ? ttwu_do_wakeup+0x2c/0x100
[10251.059601] [<ffffffff810a49e6>] ? ttwu_do_activate.constprop.111+0x66/0x70
[10251.059635] [<ffffffff815779ab>] usb_alloc_streams+0xab/0xf0
[10251.059662] [<ffffffffc0616b48>] uas_configure_endpoints+0x128/0x150 [uas]
[10251.059694] [<ffffffffc0616bac>] uas_post_reset+0x3c/0xb0 [uas]
[10251.059722] [<ffffffff815727d9>] usb_reset_device+0x1b9/0x2a0
[10251.059749] [<ffffffffc0616f42>] uas_eh_bus_reset_handler+0xb2/0x190 [uas]
[10251.059781] [<ffffffff81514293>] scsi_try_bus_reset+0x53/0x110
[10251.059808] [<ffffffff815163b7>] scsi_eh_bus_reset+0xf7/0x270
<snip>
The problem is the following call sequence (simplified):
1) usb_reset_device
2) usb_reset_and_verify_device
2) hub_port_init
3) hub_port_finish_reset
3) xhci_discover_or_reset_device
This frees xhci->devs[slot_id]->eps[ep_index].ring for all eps but 0
4) usb_get_device_descriptor
This fails
5) hub_port_init fails
6) usb_reset_and_verify_device fails, does not restore device config
7) uas_post_reset
8) xhci_alloc_streams
NULL deref on the free-ed ring
This commit fixes this by not allowing usb_alloc_streams to continue if
the device is not configured.
Note that we do allow usb_free_streams to continue after a (logical)
disconnect, as it is necessary to explicitly free the streams at the xhci
controller level.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c75f52339e8b9921ff79d88f9867f9df5f331bb
Author: Johan Hovold <johan@kernel.org>
Date: Wed Oct 29 09:07:31 2014 +0100
USB: opticon: fix non-atomic allocation in write path
commit e681286de221af78fc85db9222b6a203148c005a upstream.
Write may be called from interrupt context so make sure to use
GFP_ATOMIC for all allocations in write.
Fixes: 0d930e51cfe6 ("USB: opticon: Add Opticon OPN2001 write support")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74f2ad9e96349debc347c514eac1905d7e2038ac
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Fri Oct 31 14:49:47 2014 -0400
usb-storage: handle a skipped data phase
commit 93c9bf4d1838d5851a18ca398b0ad66397f05056 upstream.
Sometimes mass-storage devices using the Bulk-only transport will
mistakenly skip the data phase of a command. Rather than sending the
data expected by the host or sending a zero-length packet, they go
directly to the status phase and send the CSW.
This causes problems for usb-storage, for obvious reasons. The driver
will interpret the CSW as a short data transfer and will wait to
receive a CSW. The device won't have anything left to send, so the
command eventually times out.
The SCSI layer doesn't retry commands after they time out (this is a
relatively recent change). Therefore we should do our best to detect
a skipped data phase and handle it promptly.
This patch adds code to do that. If usb-storage receives a short
13-byte data transfer from the device, and if the first four bytes of
the data match the CSW signature, the driver will set the residue to
the full transfer length and interpret the data as a CSW.
This fixes Bugzilla #86611.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Tested-by: Paul Osmialowski <newchief@king.net.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb8c0789abe44956b9f3aeb6d545b516539a6623
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Nov 5 15:08:49 2014 +0100
ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect
commit 0725dda207e95ff25f1aa01432250323e0ec49d6 upstream.
Some USB-audio devices show weird sysfs warnings at disconnecting the
devices, e.g.
usb 1-3: USB disconnect, device number 3
------------[ cut here ]------------
WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180()
sysfs group ffffffff8183df40 not found for kobject 'midiC1D0'
Call Trace:
[<ffffffff814a3e38>] ? dump_stack+0x49/0x71
[<ffffffff8103cb72>] ? warn_slowpath_common+0x82/0xb0
[<ffffffff8103cc55>] ? warn_slowpath_fmt+0x45/0x50
[<ffffffff813521e9>] ? device_del+0x39/0x180
[<ffffffff81352339>] ? device_unregister+0x9/0x20
[<ffffffff81352384>] ? device_destroy+0x34/0x40
[<ffffffffa00ba29f>] ? snd_unregister_device+0x7f/0xd0 [snd]
[<ffffffffa025124e>] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi]
[<ffffffffa00c0192>] ? snd_device_disconnect+0x62/0x90 [snd]
[<ffffffffa00c025c>] ? snd_device_disconnect_all+0x3c/0x60 [snd]
[<ffffffffa00bb574>] ? snd_card_disconnect+0x124/0x1a0 [snd]
[<ffffffffa02e54e8>] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio]
[<ffffffffa015260e>] ? usb_unbind_interface+0x5e/0x1b0 [usbcore]
[<ffffffff813553e9>] ? __device_release_driver+0x79/0xf0
[<ffffffff81355485>] ? device_release_driver+0x25/0x40
[<ffffffff81354e11>] ? bus_remove_device+0xf1/0x130
[<ffffffff813522b9>] ? device_del+0x109/0x180
[<ffffffffa01501d5>] ? usb_disable_device+0x95/0x1f0 [usbcore]
[<ffffffffa014634f>] ? usb_disconnect+0x8f/0x190 [usbcore]
[<ffffffffa0149179>] ? hub_thread+0x539/0x13a0 [usbcore]
[<ffffffff810669f5>] ? sched_clock_local+0x15/0x80
[<ffffffff81066c98>] ? sched_clock_cpu+0xb8/0xd0
[<ffffffff81070730>] ? bit_waitqueue+0xb0/0xb0
[<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
[<ffffffffa0148c40>] ? usb_port_resume+0x430/0x430 [usbcore]
[<ffffffff8105973e>] ? kthread+0xce/0xf0
[<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
[<ffffffff814a8b7c>] ? ret_from_fork+0x7c/0xb0
[<ffffffff81059670>] ? kthread_create_on_node+0x1c0/0x1c0
---[ end trace 40b1928d1136b91e ]---
This comes from the fact that usb-audio driver may receive the
disconnect callback multiple times, per each usb interface. When a
device has both audio and midi interfaces, it gets called twice, and
currently the driver tries to release resources at the last call.
At this point, the first parent interface has been already deleted,
thus deleting a child of the first parent hits such a warning.
For fixing this problem, we need to call snd_card_disconnect() and
cancel pending operations at the very first disconnect while the
release of the whole objects waits until the last disconnect call.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931
Reported-and-tested-by: Tomas Gayoso <tgayoso@gmail.com>
Reported-and-tested-by: Chris J Arges <chris.j.arges@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 400447e8ab1f6b50d94104765e7d6d927bac8ab7
Author: Felipe Balbi <balbi@ti.com>
Date: Fri Oct 17 11:10:25 2014 -0500
usb: gadget: udc: core: fix kernel oops with soft-connect
commit bfa6b18c680450c17512c741ed1d818695747621 upstream.
Currently, there's no guarantee that udc->driver
will be valid when using soft_connect sysfs
interface. In fact, we can very easily trigger
a NULL pointer dereference by trying to disconnect
when a gadget driver isn't loaded.
Fix this bug:
~# echo disconnect > soft_connect
[ 33.685743] Unable to handle kernel NULL pointer dereference at virtual address 00000014
[ 33.694221] pgd = ed0cc000
[ 33.697174] [00000014] *pgd=ae351831, *pte=00000000, *ppte=00000000
[ 33.703766] Internal error: Oops: 17 [#1] SMP ARM
[ 33.708697] Modules linked in: xhci_plat_hcd xhci_hcd snd_soc_davinci_mcasp snd_soc_tlv320aic3x snd_soc_edma snd_soc_omap snd_soc_evm snd_soc_core dwc3 snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd lis3lv02d_i2c matrix_keypad lis3lv02d dwc3_omap input_polldev soundcore
[ 33.734372] CPU: 0 PID: 1457 Comm: bash Not tainted 3.17.0-09740-ga93416e-dirty #345
[ 33.742457] task: ee71ce00 ti: ee68a000 task.ti: ee68a000
[ 33.748116] PC is at usb_udc_softconn_store+0xa4/0xec
[ 33.753416] LR is at mark_held_locks+0x78/0x90
[ 33.758057] pc : [<c04df128>] lr : [<c00896a4>] psr: 20000013
[ 33.758057] sp : ee68bec8 ip : c0c00008 fp : ee68bee4
[ 33.770050] r10: ee6b394c r9 : ee68bf80 r8 : ee6062c0
[ 33.775508] r7 : 00000000 r6 : ee6062c0 r5 : 0000000b r4 : ee739408
[ 33.782346] r3 : 00000000 r2 : 00000000 r1 : ee71d390 r0 : ee664170
[ 33.789168] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 33.796636] Control: 10c5387d Table: ad0cc059 DAC: 00000015
[ 33.802638] Process bash (pid: 1457, stack limit = 0xee68a248)
[ 33.808740] Stack: (0xee68bec8 to 0xee68c000)
[ 33.813299] bec0: 0000000b c0411284 ee6062c0 00000000 ee68bef4 ee68bee8
[ 33.821862] bee0: c04112ac c04df090 ee68bf14 ee68bef8 c01c2868 c0411290 0000000b ee6b3940
[ 33.830419] bf00: 00000000 00000000 ee68bf4c ee68bf18 c01c1a24 c01c2818 00000000 00000000
[ 33.838990] bf20: ee61b940 ee2f47c0 0000000b 000ce408 ee68bf80 c000f304 ee68a000 00000000
[ 33.847544] bf40: ee68bf7c ee68bf50 c0152dd8 c01c1960 ee68bf7c c0170af8 ee68bf7c ee2f47c0
[ 33.856099] bf60: ee2f47c0 000ce408 0000000b c000f304 ee68bfa4 ee68bf80 c0153330 c0152d34
[ 33.864653] bf80: 00000000 00000000 0000000b 000ce408 b6e7fb50 00000004 00000000 ee68bfa8
[ 33.873204] bfa0: c000f080 c01532e8 0000000b 000ce408 00000001 000ce408 0000000b 00000000
[ 33.881763] bfc0: 0000000b 000ce408 b6e7fb50 00000004 0000000b 00000000 000c5758 00000000
[ 33.890319] bfe0: 00000000 bec2c924 b6de422d b6e1d226 40000030 00000001 75716d2f 00657565
[ 33.898890] [<c04df128>] (usb_udc_softconn_store) from [<c04112ac>] (dev_attr_store+0x28/0x34)
[ 33.907920] [<c04112ac>] (dev_attr_store) from [<c01c2868>] (sysfs_kf_write+0x5c/0x60)
[ 33.916200] [<c01c2868>] (sysfs_kf_write) from [<c01c1a24>] (kernfs_fop_write+0xd0/0x194)
[ 33.924773] [<c01c1a24>] (kernfs_fop_write) from [<c0152dd8>] (vfs_write+0xb0/0x1bc)
[ 33.932874] [<c0152dd8>] (vfs_write) from [<c0153330>] (SyS_write+0x54/0xb0)
[ 33.940247] [<c0153330>] (SyS_write) from [<c000f080>] (ret_fast_syscall+0x0/0x48)
[ 33.948160] Code: e1a01007 e12fff33 e5140004 e5143008 (e5933014)
[ 33.954625] ---[ end trace f849bead94eab7ea ]---
Fixes: 2ccea03 (usb: gadget: introduce UDC Class)
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 63590028963a7d4782114b2acc5efe54affe6c95
Author: Adel Gadllah <adel.gadllah@gmail.com>
Date: Thu Oct 9 08:05:53 2014 +0200
HID: usbhid: enable always-poll quirk for Elan Touchscreen 016f
commit 1af39588f84c7c18f8c6d88342f36513a4ce383c upstream.
This device needs the quirk as well.
Tested-by: Kevin Fenzi <kevin@scrye.com>
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c442333e7f53070a0c7c8e725dad258facee2fc
Author: Adel Gadllah <adel.gadllah@gmail.com>
Date: Thu Oct 9 08:05:52 2014 +0200
HID: usbhid: enable always-poll quirk for Elan Touchscreen 009b
commit 29d05c2ecf396161ef2938a0635707ef5685ef58 upstream.
This device needs the quirk as well.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f41c09a2fc5881f0f4797e2f9cf4774b7be27c43
Author: Oliver Neukum <oneukum@suse.de>
Date: Tue Sep 30 12:54:56 2014 +0200
HID: usbhid: add another mouse that needs QUIRK_ALWAYS_POLL
commit 5235166fbc332c8b5dcf49e3a498a8b510a77449 upstream.
There is a second mouse sharing the same vendor strings but different IDs.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d1649413b6a4f0d6916028a8bcbae420ed1cb861
Author: Oliver Neukum <oneukum@suse.de>
Date: Mon Sep 8 11:21:49 2014 +0200
HID: usbhid: fix PIXART optical mouse
commit 4980f95755e2966b30ac70d1841f4db66d1a8a22 upstream.
This mouse keeps disconnecting in runlevel 3. It needs the ALWAYS_POLL quirk.
Signed-off-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f37f1996e2e86fb60f2fd8c182e74bdf05e56e7
Author: Johan Hovold <johan@kernel.org>
Date: Fri Sep 5 18:08:48 2014 +0200
HID: usbhid: enable always-poll quirk for Elan Touchscreen
commit bfe3c873e978d78b542a5852575dd74f4d1a5838 upstream.
Enable the always-poll quirk for Elan Touchscreens found on some recent
Samsung laptops.
Without this quirk the device keeps disconnecting from the bus (and is
re-enumerated) unless opened (and kept open, should an input event
occur).
Note that while the device can be run-time suspended, the autosuspend
timeout must be high enough to allow the device to be polled at least
once before being suspended. Specifically, using autosuspend_delay_ms=0
will still cause the device to disconnect on input events.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 79bdacac68dec2118bfe4bc08ff63755d95b2b4d
Author: Johan Hovold <johan@kernel.org>
Date: Fri Sep 5 18:08:47 2014 +0200
HID: usbhid: add always-poll quirk
commit 0b750b3baa2d64f1b77aecc10f20deeb28efe60d upstream.
Add quirk to make sure that a device is always polled for input events
even if it hasn't been opened.
This is needed for devices that disconnects from the bus unless the
interrupt endpoint has been polled at least once or when not responding
to an input event (e.g. after having shut down X).
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 27cb5c87fc286e7edfad275dad90ea0e7e229d5b
Author: Adel Gadllah <adel.gadllah@gmail.com>
Date: Thu Oct 9 09:29:30 2014 +0200
USB: quirks: enable device-qualifier quirk for yet another Elan touchscreen
commit d749947561af5996ccc076b2ffcc5f48b1be5d74 upstream.
Yet another device affected by this.
Tested-by: Kevin Fenzi <kevin@scrye.com>
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4faaec81d9c5450c5ecbe1254432cf5c64b92d5
Author: Adel Gadllah <adel.gadllah@gmail.com>
Date: Thu Oct 9 09:29:29 2014 +0200
USB: quirks: enable device-qualifier quirk for another Elan touchscreen
commit 876af5d454548be40327ba9efea4bc92a8575019 upstream.
Currently this quirk is enabled for the model with the device id 0x0089, it
is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904
as well.
Signed-off-by: Adel Gadllah <adel.gadllah@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 85bde4b3562050424b2106f6f4101de8edca4b28
Author: Johan Hovold <johan@kernel.org>
Date: Mon Aug 25 17:51:27 2014 +0200
USB: quirks: enable device-qualifier quirk for Elan Touchscreen
commit c68929f75dfcb6354918862b91b5778585de1fa5 upstream.
Enable device-qualifier quirk for Elan Touchscreen, which often fails to
handle requests for the device_descriptor.
Note that the device sometimes do respond properly with a Request Error
(three times as USB core retries), but usually fails to respond at all.
When this happens any further descriptor requests also fails, for
example:
[ 1528.688934] usb 2-7: new full-speed USB device number 4 using xhci_hcd
[ 1530.945588] usb 2-7: unable to read config index 0 descriptor/start: -71
[ 1530.945592] usb 2-7: can't read configurations, error -71
This has been observed repeating for over a minute before eventual
successful enumeration.
Reported-by: Drew Von Spreecken <drewvs@gmail.com>
Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 979562c45fe6eec1e463dc8333b92c4d5b34ae93
Author: Johan Hovold <johan@kernel.org>
Date: Mon Aug 25 17:51:26 2014 +0200
USB: core: add device-qualifier quirk
commit 2a159389bf5d962359349a76827b2f683276a1c7 upstream.
Add new quirk for devices that cannot handle requests for the
device_qualifier descriptor.
A USB-2.0 compliant device must respond to requests for the
device_qualifier descriptor (even if it's with a request error), but at
least one device is known to misbehave after such a request.
Suggested-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4afc5f5df26932047569445f63c6eabdcc699542
Author: Torsten Fleischer <to-fleischer@t-online.de>
Date: Sun Oct 26 19:33:13 2014 +0800
usb: chipidea: Fix oops when removing the ci_hdrc module
commit 9680b60ed79edaf52f84b65cbb20859bbb26cb68 upstream.
The call of 'kfree(ci->hw_bank.regmap)' in ci_hdrc_remove() sometimes causes
a kernel oops when removing the ci_hdrc module.
Since there is no separate memory allocated for the ci->hw_bank.regmap array,
there is no need to free it.
Signed-off-by: Torsten Fleischer <to-fleischer@t-online.de>
Signed-off-by: Peter Chen <peter.chen@freescale.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67d0ba2ec828e3ab0d6c365d2719766829982aa3
Author: David Cohen <david.a.cohen@linux.intel.com>
Date: Mon Oct 13 11:15:54 2014 -0700
usb: ffs: fix regression when quirk_ep_out_aligned_size flag is set
commit c0d31b3c3d9a025b8d5a57c35671e60c5f388bf7 upstream.
The commit '2e4c7553cd usb: gadget: f_fs: add aio support' broke the
quirk implemented to align buffer size to maxpacketsize on out endpoint.
As result, functionfs does not work on Intel platforms using dwc3 driver
(i.e. Bay Trail and Merrifield). This patch fixes the issue.
This code is based on a previous Qiuxu's patch.
Fixes: 2e4c7553cd (usb: gadget: f_fs: add aio support)
Signed-off-by: David Cohen <david.a.cohen@linux.intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7591876f31136b3500336e26d2e756a8d2465b56
Author: Robert Baldyga <r.baldyga@samsung.com>
Date: Thu Oct 9 09:41:16 2014 +0200
usb: gadget: f_fs: remove redundant ffs_data_get()
commit a3058a5d82e296daaca07411c3738a9ddd79f302 upstream.
During FunctionFS bind, ffs_data_get() function was called twice
(in functionfs_bind() and in ffs_do_functionfs_bind()), while on unbind
ffs_data_put() was called once (in functionfs_unbind() function).
In result refcount never reached value 0, and ffs memory resources has
been never released.
Since ffs_data_get() call in ffs_do_functionfs_bind() is redundant
and not neccessary, we remove it to have equal number of gets ans puts,
and free allocated memory after refcount reach 0.
Fixes: 5920cda (usb: gadget: FunctionFS: convert to new function
interface with backward compatibility)
Signed-off-by: Robert Baldyga <r.baldyga@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d934b90e162cd7f0d4b28e5d65df35a065bdbdd4
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Oct 13 12:16:13 2014 +0200
usb: musb: dsps: start OTG timer on resume again
commit 53185b3a441a6cc9bb3f57e924342d249138dcd6 upstream.
Commit 468bcc2a2ca ("usb: musb: dsps: kill OTG timer on suspend") stopped
the timer in suspend path but forgot the re-enable it in the resume
path. This patch fixes the behaviour.
Fixes 468bcc2a2ca "usb: musb: dsps: kill OTG timer on suspend"
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1a7d35826cc61d8a00ae1025363ae4e37d70d955
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Thu Oct 2 17:32:16 2014 +0200
usb: musb: cppi41: restart hrtimer only if not yet done
commit d2e6d62c9cbbc2da4211f672dbeea08960e29a80 upstream.
commit c58d80f52 ("usb: musb: Ensure that cppi41 timer gets armed on
premature DMA TX irq") fixed hrtimer scheduling bug. There is one left
which does not trigger that often.
The following scenario is still possible:
lock(&x->lock);
hrtimer_start(&x->t);
unlock(&x->lock);
expires:
t->function();
lock(&x->lock);
lock(&x->lock); if (!hrtimer_queued(&x->t))
hrtimer_start(&x->t);
unlock(&x->lock);
if (!list_empty(x->early_tx_list))
ret = HRTIMER_RESTART;
-> hrtimer_forward_now(...)
} else
ret = HRTIMER_NORESTART;
unlock(&x->lock);
and the timer callback returns HRTIMER_RESTART for an armed timer. This
is wrong and we run into the BUG_ON() in __run_hrtimer().
This can happens on SMP or PREEMPT-RT.
The patch fixes the problem by only starting the timer if the timer is
not yet queued.
Reported-by: Torben Hohn <torbenh@linutronix.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[bigeasy: collected information and created a patch + description based
on it]
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba466fe5b54d11b4157b86231586b85da438e859
Author: Hans de Goede <hdegoede@redhat.com>
Date: Fri Oct 31 14:37:32 2014 +0100
uas: Add US_FL_NO_ATA_1X quirk for 1 more Seagate model
commit aee0ce3ae73c566ace9958302e001d3cbbb0a623 upstream.
These drives hang when receiving ATA12 commands, so set the US_FL_NO_ATA_1X
quirk to filter these out.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 77df17ed8a48dba80cf0bd593612bac8a6c221dd
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Oct 23 14:40:57 2014 +0200
uas: Add US_FL_NO_ATA_1X quirk for 2 more Seagate models
commit d1d9548256fbdf2e049d6413a5266c41e73658ee upstream.
These drives hang when receiving ATA12 commands, so set the US_FL_NO_ATA_1X
quirk to filter these out.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8a40839214a902cb2839e51e7ce7972d18493c7a
Author: Hans de Goede <hdegoede@redhat.com>
Date: Thu Oct 9 17:27:56 2014 +0200
uas: Add NO_ATA_1X for VIA VL711 devices
commit 673029fe9c16c95600bdaca4760673527af32edf upstream.
Just like some Seagate enclosures, these devices do not seem to grok ata
pass through commands.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 15e9f1d69c64b0a18c32867f8821c8dfe450b7ed
Author: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Thu Nov 6 14:08:29 2014 +0300
spi: pxa2xx: toggle clocks on suspend if not disabled by runtime PM
commit 2b9375b91bef65b837bed61a05fb387159b38ddf upstream.
If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
on pxa2xx hosts:
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104
[<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
[<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
[<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
[<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
[<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
[<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
[<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
[<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
[<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
[<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
[<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
[<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
[<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
[<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
[<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
[<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
---[ end trace 46524156d8faa4f6 ]---
This happens because suspend function tries to disable a clock that is
already disabled by runtime_suspend callback. Add if
(!pm_runtime_suspended()) checks to suspend/resume path.
Fixes: 7d94a505858 (spi/pxa2xx: add support for runtime PM)
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Reported-by: Andrea Adami <andrea.adami@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6449244edf8283f17e452465b24aabd8684bce04
Author: Alexander Stein <alexander.stein@systec-electronic.com>
Date: Tue Nov 4 09:20:18 2014 +0100
spi: fsl-dspi: Fix CTAR selection
commit 5cc7b04740effa5cc0af53f434134b5859d58b73 upstream.
There are only 4 CTAR registers (CTAR0 - CTAR3) so we can only use the
lower 2 bits of the chip select to select a CTAR register.
SPI_PUSHR_CTAS used the lower 3 bits which would result in wrong bit values
if the chip selects 4/5 are used. For those chip selects SPI_CTAR even
calculated offsets of non-existing registers.
Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26ef9ec83152764b4234bb779d2f01a538ea06cd
Author: Ray Jui <rjui@broadcom.com>
Date: Thu Oct 9 11:44:54 2014 -0700
spi: pl022: Fix incorrect dma_unmap_sg
commit 3ffa6158f002e096d28ede71be4e0ee8ab20baa2 upstream.
When mapped RX DMA entries are unmapped in an error condition when DMA
is firstly configured in the driver, the number of TX DMA entries was
passed in, which is incorrect
Signed-off-by: Ray Jui <rjui@broadcom.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c11a94b882929bb8440580302284dc1a7b944d2e
Author: Jack Pham <jackp@codeaurora.org>
Date: Tue Oct 21 16:31:10 2014 -0700
usb: dwc3: gadget: Properly initialize LINK TRB
commit 1200a82a59b6aa65758ccc92c3447b98c53cd7a2 upstream.
On ISOC endpoints the last trb_pool entry used as a
LINK TRB is not getting zeroed out correctly due to
memset being called incorrectly and in the wrong place.
If pool allocated from DMA was not zero-initialized
to begin with this will result in the size and ctrl
values being random garbage. Call memset correctly after
assignment of the trb_link pointer.
Fixes: f6bafc6a1c ("usb: dwc3: convert TRBs into bitshifts")
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce0197e4c67cf5539640873b8e49d8fdf3771e4c
Author: Roger Quadros <rogerq@ti.com>
Date: Tue Oct 7 09:40:57 2014 -0500
Revert "usb: dwc3: dwc3-omap: Disable/Enable only wrapper interrupts in prepare/complete"
commit b01ff5cb2fc99d45e4edc97077b6e17186570a16 upstream.
This reverts commit 02dae36aa649a66c5c6181157ddd806e7b4913fc.
That commit is bogus in two ways:
1) There's no way dwc3-omap's ->suspend() can cause any effect
on xhci's ->suspend(). Linux device driver model guarantees
that a parent's ->suspend() will only be called after all
children are suspended. dwc3-omap is the parent of the
parent of xhci.
2) When implementing Deep Sleep states where context is lost,
USBOTGSS_IRQ0 register, well, looses context so we
_must_ rewrite it otherwise core IRQs will never be
reenabled and USB will appear to be dead.
Fixes: 02dae36 (usb: dwc3: dwc3-omap: Disable/Enable only
wrapper interrupts in prepare/complete)
Cc: George Cherian <george.cherian@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c3514f6d0763afecc79bba898db99724406dbf0
Author: Cyril Brulebois <kibi@debian.org>
Date: Tue Oct 28 16:42:41 2014 +0100
wireless: rt2x00: add new rt2800usb device
commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream.
0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle
References: https://bugs.debian.org/766802
Reported-by: Martin Mokrejs <mmokrejs@fold.natur.cuni.cz>
Signed-off-by: Cyril Brulebois <kibi@debian.org>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 65d93c227e63fd97cac0045e80ef548e2f845d49
Author: Canek Peláez Valdés <canek@ciencias.unam.mx>
Date: Sun Aug 24 19:06:11 2014 -0500
rt2x00: support Ralink 5362.
commit ac0372abf8524a7572a9cdaac6495eb2eba20457 upstream.
Signed-off-by: Canek Peláez Valdés <canek@ciencias.unam.mx>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f86070377c1892adc47a66787a212025395d23cd
Author: Dan Williams <dcbw@redhat.com>
Date: Tue Oct 14 11:10:41 2014 -0500
USB: option: add Haier CE81B CDMA modem
commit 012eee1522318b5ccd64d277d50ac32f7e9974fe upstream.
Port layout:
0: QCDM/DIAG
1: NMEA
2: AT
3: AT/PPP
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3c2faf5e2e058307e7cb9eeeb4538e3d0d3cdc27
Author: Daniele Palmas <dnlplm@gmail.com>
Date: Tue Oct 14 10:47:37 2014 +0200
usb: option: add support for Telit LE910
commit 2d0eb862dd477c3c4f32b201254ca0b40e6f465c upstream.
Add VID/PID for Telit LE910 modem. Interfaces description is almost the
same than LE920, except that the qmi interface is number 2 (instead than
5).
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 841c21075428691556265681b25f8ed6618be0b9
Author: Oussama Ghorbel <ghorbel@pivasoftware.com>
Date: Tue Nov 4 11:47:06 2014 +0530
phy: omap-usb2: Enable runtime PM of omap-usb2 phy properly
commit f20531a9aae0c7378d9fa75b4b5d99b7eecab066 upstream.
The USB OTG port does not work since v3.16 on omap platform.
This is a regression introduced by the commit
eb82a3d846fa (phy: omap-usb2: Balance pm_runtime_enable() on probe failure
and remove).
This because the call to pm_runtime_enable() function is moved after the
call to devm_phy_create() function, which has side effect since later in
the subsequent calls of devm_phy_create() there is a check with
pm_runtime_enabled() to configure few things.
Fixes: eb82a3d846fa
Signed-off-by: Oussama Ghorbel <ghorbel@pivasoftware.com>
Tested-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 77435b9a1cf4392f5fc63d0ab187002cec377810
Author: Johan Hovold <johan@kernel.org>
Date: Thu Nov 6 18:08:33 2014 +0100
USB: cdc-acm: add quirk for control-line state requests
commit 2a8cdfde9237c4e1bd7c2e68c415b006491d23cc upstream.
Add new quirk for devices that cannot handle control-line state
requests.
Note that we currently send these requests to all devices, regardless of
whether they claim to support it, but that errors are only logged if
support is claimed.
Since commit 0943d8ead30e ("USB: cdc-acm: use tty-port dtr_rts"), which
only changed the timings for these requests slightly, this has been
reported to cause occasional firmware crashes on Simtec Electronics
Entropy Key devices after re-enumeration. Enable the quirk for this
device.
Reported-by: Nix <nix@esperi.org.uk>
Tested-by: Nix <nix@esperi.org.uk>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ebef959c0d7847c6b6bd578593e32e7591ac9d68
Author: Johan Hovold <johan@kernel.org>
Date: Wed Nov 5 18:41:59 2014 +0100
USB: cdc-acm: only raise DTR on transitions from B0
commit 4473d054ceb572557954f9536731d39b20937b0c upstream.
Make sure to only raise DTR on transitions from B0 in set_termios.
Also allow set_termios to be called from open with a termios_old of
NULL. Note that DTR will not be raised prematurely in this case.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fd323ab33141a4a19cbaf7434a4f1b5ae61fb611
Author: Johan Hovold <johan@kernel.org>
Date: Mon Oct 27 18:34:33 2014 +0100
USB: cdc-acm: add device id for GW Instek AFG-2225
commit cf84a691a61606a2e7269907d3727e2d9fa148ee upstream.
Add device-id entry for GW Instek AFG-2225, which has a byte swapped
bInterfaceSubClass (0x20).
Reported-by: Karl Palsson <karlp@tweak.net.au>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2f143ca30749fc566882c45adc02daa26ec3fd5b
Author: Perry Hung <iperry@gmail.com>
Date: Wed Oct 22 23:31:34 2014 -0400
usb: serial: ftdi_sio: add "bricked" FTDI device PID
commit 7f2719f0003da1ad13124ef00f48d7514c79e30d upstream.
An official recent Windows driver from FTDI detects counterfeit devices
and reprograms the internal EEPROM containing the USB PID to 0, effectively
bricking the device.
Add support for this VID/PID pair to correctly bind the driver on these
devices.
See:
http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/
Signed-off-by: Perry Hung <iperry@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab5fe4227acfa349b6920db73865aceb2339dea5
Author: Frans Klaver <frans.klaver@xsens.com>
Date: Fri Oct 10 11:52:08 2014 +0200
usb: serial: ftdi_sio: add Awinda Station and Dongle products
commit edd74ffab1f6909eee400c7de8ce621870aacac9 upstream.
Add new IDs for the Xsens Awinda Station and Awinda Dongle.
While at it, order the definitions by PID and add a logical separation
between devices using Xsens' VID and those using FTDI's VID.
Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c41c6089b526e59464ea35be41a71363ac31a2a
Author: Nathaniel Ting <nathaniel.ting@silabs.com>
Date: Fri Oct 3 12:01:20 2014 -0400
USB: serial: cp210x: add Silicon Labs 358x VID and PID
commit 35cc83eab097e5720a9cc0ec12bdc3a726f58381 upstream.
Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial
driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now
connect to host PCs over a USB serial link.
Signed-off-by: Nathaniel Ting <nathaniel.ting@silabs.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe18254216c3b04a675a7e1cc877c29e630d5c6e
Author: Peter Hurley <peter@hurleysoftware.com>
Date: Thu Oct 16 13:46:38 2014 -0400
serial: Fix divide-by-zero fault in uart_get_divisor()
commit 547039ec502076e60034eeb79611df3433a99b7d upstream.
uart_get_baud_rate() will return baud == 0 if the max rate is set
to the "magic" 38400 rate and the SPD_* flags are also specified.
On the first iteration, if the current baud rate is higher than the
max, the baud rate is clamped at the max (which in the degenerate
case is 38400). On the second iteration, the now-"magic" 38400 baud
rate selects the possibly higher alternate baud rate indicated by
the SPD_* flag. Since only two loop iterations are performed, the
loop is exited, a kernel WARNING is generated and a baud rate of
0 is returned.
Reproducible with:
setserial /dev/ttyS0 spd_hi base_baud 38400
Only perform the "magic" 38400 -> SPD_* baud transform on the first
loop iteration, which prevents the degenerate case from recognizing
the clamped baud rate as the "magic" 38400 value.
Reported-by: Robert Święcki <robert@swiecki.net>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1540639fb05f11ab2cfb26181214175718c0d97b
Author: Stephen Boyd <sboyd@codeaurora.org>
Date: Tue Aug 5 18:37:24 2014 -0700
serial: msm_serial: Fix kgdb continue
commit 8b374399468da1c25db5b5d436b167aafc10fbdc upstream.
Frank reports that after continuing in kgdb the RX stale event
doesn't occur until after the RX fifo is filled up with exactly
the amount of characters programmed for the RX watermark (in this
case it's 48). To read a single character from the uartdm
hardware we force a stale event so that any characters in the RX
packing buffer are flushed into the RX fifo immediately instead
of waiting for a stale timeout or for the fifo to fill. Forcing
that stale event asserts the stale interrupt but we never clear
that interrupt via UART_CR_CMD_RESET_STALE_INT in the polling
functions. So when kgdb continues the stale interrupt is left
pending in the hardware and we don't timeout with a stale event,
like we usually would if a user typed one character on the
console, until the reset stale interrupt and stale event commands
are sent. Frank could get things working again by running
handle_rx_dm(). By putting enough characters into the fifo he
could trigger a watermark interrupt, and thus cause
handle_rx_dm() to run finally resetting the stale interrupt
and enabling the stale event so that single characters would
cause timeouts again.
The fix is to just do what the interrupt routine was doing all
along and clear the stale interrupt and enable the event again.
Doing this also smooths over any differences in the fifo behavior
between v1.3 and v1.4 hardware allowing us to skip forcing the
uart into single character mode.
Reviewed-by: Frank Rowand <frank.rowand@sonymobile.com>
Tested-by: Frank Rowand <frank.rowand@sonymobile.com>
Fixes: f7e54d7ad743 "msm_serial: Add support for poll_{get,put}_char()"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a332bdec8c1aef32cd4487e2089ba6a81534379
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Tue Nov 4 18:03:16 2014 +0100
staging:iio:ade7758: Remove "raw" from channel name
commit b598aacc29331e7e638cd509108600e916c6331b upstream.
"raw" is a property of a channel, but should not be part of the name of
channel.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9f77d69dda0288eda44a001a1be1dab963aad746
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Tue Nov 4 18:03:15 2014 +0100
staging:iio:ade7758: Fix check if channels are enabled in prenable
commit 79fa64eb2ee8ccb4bcad7f54caa2699730b10b22 upstream.
We should check if a channel is enabled, not if no channels are enabled.
Fixes: 550268ca1111 ("staging:iio: scrap scan_count and ensure all drivers use active_scan_mask")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7697191d334932bfde221e59677d1803cf7ac2f8
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Tue Nov 4 18:03:14 2014 +0100
staging:iio:ade7758: Fix NULL pointer deref when enabling buffer
commit e10554738cab4224e097c2f9d975ea781a4fcde4 upstream.
In older versions of the IIO framework it was possible to pass a completely
different set of channels to iio_buffer_register() as the one that is
assigned to the IIO device. Commit 959d2952d124 ("staging:iio: make
iio_sw_buffer_preenable much more general.") introduced a restriction that
requires that the set of channels that is passed to iio_buffer_register() is
a subset of the channels assigned to the IIO device as the IIO core will use
the list of channels that is assigned to the device to lookup a channel by
scan index in iio_compute_scan_bytes(). If it can not find the channel the
function will crash. This patch fixes the issue by making sure that the same
set of channels is assigned to the IIO device and passed to
iio_buffer_register().
Note that we need to remove the IIO_CHAN_INFO_RAW and IIO_CHAN_INFO_SCALE
info attributes from the channels since we don't actually want those to be
registered.
Fixes the following crash:
Unable to handle kernel NULL pointer dereference at virtual address 00000016
pgd = d2094000
[00000016] *pgd=16e39831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 1695 Comm: bash Not tainted 3.17.0-06329-g29461ee #9686
task: d7768040 ti: d5bd4000 task.ti: d5bd4000
PC is at iio_compute_scan_bytes+0x38/0xc0
LR is at iio_compute_scan_bytes+0x34/0xc0
pc : [<c0316de8>] lr : [<c0316de4>] psr: 60070013
sp : d5bd5ec0 ip : 00000000 fp : 00000000
r10: d769f934 r9 : 00000000 r8 : 00000001
r7 : 00000000 r6 : c8fc6240 r5 : d769f800 r4 : 00000000
r3 : d769f800 r2 : 00000000 r1 : ffffffff r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 18c5387d Table: 1209404a DAC: 00000015
Process bash (pid: 1695, stack limit = 0xd5bd4240)
Stack: (0xd5bd5ec0 to 0xd5bd6000)
5ec0: d769f800 d7435640 c8fc6240 d769f984 00000000 c03175a4 d7435690 d7435640
5ee0: d769f990 00000002 00000000 d769f800 d5bd4000 00000000 000b43a8 c03177f4
5f00: d769f810 0162b8c8 00000002 c8fc7e00 d77f1d08 d77f1da8 c8fc7e00 c01faf1c
5f20: 00000002 c010694c c010690c d5bd5f88 00000002 c8fc6840 c8fc684c c0105e08
5f40: 00000000 00000000 d20d1580 00000002 000af408 d5bd5f88 c000de84 c00b76d4
5f60: d20d1580 000af408 00000002 d20d1580 d20d1580 00000002 000af408 c000de84
5f80: 00000000 c00b7a44 00000000 00000000 00000002 b6ebea78 00000002 000af408
5fa0: 00000004 c000dd00 b6ebea78 00000002 00000001 000af408 00000002 00000000
5fc0: b6ebea78 00000002 000af408 00000004 bee96a4c 000a6094 00000000 000b43a8
5fe0: 00000000 bee969cc b6e2eb77 b6e6525c 40070010 00000001 00000000 00000000
[<c0316de8>] (iio_compute_scan_bytes) from [<c03175a4>] (__iio_update_buffers+0x248/0x438)
[<c03175a4>] (__iio_update_buffers) from [<c03177f4>] (iio_buffer_store_enable+0x60/0x7c)
[<c03177f4>] (iio_buffer_store_enable) from [<c01faf1c>] (dev_attr_store+0x18/0x24)
[<c01faf1c>] (dev_attr_store) from [<c010694c>] (sysfs_kf_write+0x40/0x4c)
[<c010694c>] (sysfs_kf_write) from [<c0105e08>] (kernfs_fop_write+0x110/0x154)
[<c0105e08>] (kernfs_fop_write) from [<c00b76d4>] (vfs_write+0xbc/0x170)
[<c00b76d4>] (vfs_write) from [<c00b7a44>] (SyS_write+0x40/0x78)
[<c00b7a44>] (SyS_write) from [<c000dd00>] (ret_fast_syscall+0x0/0x30)
Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit db7abd947b6f2b0b144453ce33ca45a8703d0d6f
Author: George McCollister <george.mccollister@gmail.com>
Date: Fri Oct 31 15:44:00 2014 +0000
iio: as3935: allocate correct iio_device size
commit f73cde600d410ad4b31362a9c348016e40a146ea upstream.
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Acked-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a52ec8a41c2fb1adb32b0cb7c6f34591c1b3869b
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Thu Sep 25 15:27:00 2014 +0100
staging:iio:ad5933: Drop "raw" from channel names
commit 6822ee34ad57b29a3b44df2c2829910f03c34fa4 upstream.
"raw" is the name of a channel property, but should not be part of the
channel name itself.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 636528a4176c6f430d52883696d80ab95b6e0b82
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Thu Sep 25 15:27:00 2014 +0100
staging:iio:ad5933: Fix NULL pointer deref when enabling buffer
commit 824269c5868d2a7a26417e5ef3841a27d42c6139 upstream.
In older versions of the IIO framework it was possible to pass a
completely different set of channels to iio_buffer_register() as the one
that is assigned to the IIO device. Commit 959d2952d124 ("staging:iio: make
iio_sw_buffer_preenable much more general.") introduced a restriction that
requires that the set of channels that is passed to iio_buffer_register() is
a subset of the channels assigned to the IIO device as the IIO core will use
the list of channels that is assigned to the device to lookup a channel by
scan index in iio_compute_scan_bytes(). If it can not find the channel the
function will crash. This patch fixes the issue by making sure that the same
set of channels is assigned to the IIO device and passed to
iio_buffer_register().
Fixes the follow NULL pointer derefernce kernel crash:
Unable to handle kernel NULL pointer dereference at virtual address 00000016
pgd = d53d0000
[00000016] *pgd=1534e831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 1 PID: 1626 Comm: bash Not tainted 3.15.0-19969-g2a180eb-dirty #9545
task: d6c124c0 ti: d539a000 task.ti: d539a000
PC is at iio_compute_scan_bytes+0x34/0xa8
LR is at iio_compute_scan_bytes+0x34/0xa8
pc : [<c03052e4>] lr : [<c03052e4>] psr: 60070013
sp : d539beb8 ip : 00000001 fp : 00000000
r10: 00000002 r9 : 00000000 r8 : 00000001
r7 : 00000000 r6 : d6dc8800 r5 : d7571000 r4 : 00000002
r3 : d7571000 r2 : 00000044 r1 : 00000001 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 18c5387d Table: 153d004a DAC: 00000015
Process bash (pid: 1626, stack limit = 0xd539a240)
Stack: (0xd539beb8 to 0xd539c000)
bea0: c02fc0e4 d7571000
bec0: d76c1640 d6dc8800 d757117c 00000000 d757112c c0305b04 d76c1690 d76c1640
bee0: d7571188 00000002 00000000 d7571000 d539a000 00000000 000dd1c8 c0305d54
bf00: d7571010 0160b868 00000002 c69d3900 d7573278 d7573308 c69d3900 c01ece90
bf20: 00000002 c0103fac c0103f6c d539bf88 00000002 c69d3b00 c69d3b0c c0103468
bf40: 00000000 00000000 d7694a00 00000002 000af408 d539bf88 c000dd84 c00b2f94
bf60: d7694a00 000af408 00000002 d7694a00 d7694a00 00000002 000af408 c000dd84
bf80: 00000000 c00b32d0 00000000 00000000 00000002 b6f1aa78 00000002 000af408
bfa0: 00000004 c000dc00 b6f1aa78 00000002 00000001 000af408 00000002 00000000
bfc0: b6f1aa78 00000002 000af408 00000004 be806a4c 000a6094 00000000 000dd1c8
bfe0: 00000000 be8069cc b6e8ab77 b6ec125c 40070010 00000001 22940489 154a5007
[<c03052e4>] (iio_compute_scan_bytes) from [<c0305b04>] (__iio_update_buffers+0x248/0x438)
[<c0305b04>] (__iio_update_buffers) from [<c0305d54>] (iio_buffer_store_enable+0x60/0x7c)
[<c0305d54>] (iio_buffer_store_enable) from [<c01ece90>] (dev_attr_store+0x18/0x24)
[<c01ece90>] (dev_attr_store) from [<c0103fac>] (sysfs_kf_write+0x40/0x4c)
[<c0103fac>] (sysfs_kf_write) from [<c0103468>] (kernfs_fop_write+0x110/0x154)
[<c0103468>] (kernfs_fop_write) from [<c00b2f94>] (vfs_write+0xd0/0x160)
[<c00b2f94>] (vfs_write) from [<c00b32d0>] (SyS_write+0x40/0x78)
[<c00b32d0>] (SyS_write) from [<c000dc00>] (ret_fast_syscall+0x0/0x30)
Code: ea00000e e1a01008 e1a00005 ebfff6fc (e5d0a016)
Fixes: 959d2952d124 ("staging:iio: make iio_sw_buffer_preenable much more general.")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bff71889260f240753afc19ce2d9ac743599593b
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Sat Oct 4 08:50:21 2014 -0300
iio: adc: mxs-lradc: Disable the clock on probe failure
commit 75d7ed3b9e7cb79a3b0e1f417fb674d54b4fc668 upstream.
We should disable lradc->clk in the case of errors in the probe function.
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 57e65011ecda66285fcff26be9238400ce0f0380
Author: Robin van der Gracht <robin@protonic.nl>
Date: Mon Sep 29 15:00:07 2014 +0200
iio: st_sensors: Fix buffer copy
commit 4250c90b30b8bf2a1a21122ba0484f8f351f152d upstream.
Use byte_for_channel as iterator to properly initialize the buffer.
Signed-off-by: Robin van der Gracht <robin@protonic.nl>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c99e7a88ab69f3abfbd8e31a36436b9f0ca8179
Author: Michal Hocko <mhocko@suse.cz>
Date: Mon Oct 20 18:12:32 2014 +0200
OOM, PM: OOM killed task shouldn't escape PM suspend
commit 5695be142e203167e3cb515ef86a88424f3524eb upstream.
PM freezer relies on having all tasks frozen by the time devices are
getting frozen so that no task will touch them while they are getting
frozen. But OOM killer is allowed to kill an already frozen task in
order to handle OOM situtation. In order to protect from late wake ups
OOM killer is disabled after all tasks are frozen. This, however, still
keeps a window open when a killed task didn't manage to die by the time
freeze_processes finishes.
Reduce the race window by checking all tasks after OOM killer has been
disabled. This is still not race free completely unfortunately because
oom_killer_disable cannot stop an already ongoing OOM killer so a task
might still wake up from the fridge and get killed without
freeze_processes noticing. Full synchronization of OOM and freezer is,
however, too heavy weight for this highly unlikely case.
Introduce and check oom_kills counter which gets incremented early when
the allocator enters __alloc_pages_may_oom path and only check all the
tasks if the counter changes during the freezing attempt. The counter
is updated so early to reduce the race window since allocator checked
oom_killer_disabled which is set by PM-freezing code. A false positive
will push the PM-freezer into a slow path but that is not a big deal.
Changes since v1
- push the re-check loop out of freeze_processes into
check_frozen_processes and invert the condition to make the code more
readable as per Rafael
Fixes: f660daac474c6f (oom: thaw threads if oom killed thread is frozen before deferring)
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 43b755e62704f71161a0ea404e613f50a075b153
Author: Lv Zheng <lv.zheng@intel.com>
Date: Wed Oct 29 11:33:49 2014 +0800
ACPI / EC: Fix regression due to conflicting firmware behavior between Samsung and Acer.
commit 79149001105f18bd2285ada109f9229ea24a7571 upstream.
It is reported that Samsung laptops that need to poll events are broken by
the following commit:
Commit 3afcf2ece453e1a8c2c6de19cdf06da3772a1b08
Subject: ACPI / EC: Add support to disallow QR_EC to be issued when SCI_EVT isn't set
The behaviors of the 2 vendor firmwares are conflict:
1. Acer: OSPM shouldn't issue QR_EC unless SCI_EVT is set, firmware
automatically sets SCI_EVT as long as there is event queued up.
2. Samsung: OSPM should issue QR_EC whatever SCI_EVT is set, firmware
returns 0 when there is no event queued up.
This patch is a quick fix to distinguish the behaviors to make Acer
behavior only effective for Acer EC firmware so that the breakages on
Samsung EC firmware can be avoided.
Fixes: 3afcf2ece453 (ACPI / EC: Add support to disallow QR_EC to be issued ...)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Reported-and-tested-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
[ rjw : Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2e7815e5d45b76281ecdd6d007c7ad4dff5f8a0d
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Mon Oct 27 13:21:33 2014 +0800
ACPI, irq, x86: Return IRQ instead of GSI in mp_register_gsi()
commit b77e8f435337baa1cd15852fb9db3f6d26cd8eb7 upstream.
Function mp_register_gsi() returns blindly the GSI number for the ACPI
SCI interrupt. That causes a regression when the GSI for ACPI SCI is
shared with other devices.
The regression was caused by commit 84245af7297ced9e8fe "x86, irq, ACPI:
Change __acpi_register_gsi to return IRQ number instead of GSI" and
exposed on a SuperMicro system, which shares one GSI between ACPI SCI
and PCI device, with following failure:
http://sourceforge.net/p/linux1394/mailman/linux1394-user/?viewmonth=201410
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 20 low
level)
[ 2.699224] firewire_ohci 0000:06:00.0: failed to allocate interrupt
20
Return mp_map_gsi_to_irq(gsi, 0) instead of the GSI number.
Reported-and-Tested-by: Daniel Robbins <drobbins@funtoo.org>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Link: http://lkml.kernel.org/r/1414387308-27148-4-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 19f86e16597d5a7440d72bf84d9758e68d787bc5
Author: Jiang Liu <jiang.liu@linux.intel.com>
Date: Mon Oct 20 22:45:27 2014 +0800
x86: ACPI: Do not translate GSI number if IOAPIC is disabled
commit 961b6a7003acec4f9d70dabc1a253b783cb74272 upstream.
When IOAPIC is disabled, acpi_gsi_to_irq() should return gsi directly
instead of calling mp_map_gsi_to_irq() to translate gsi to IRQ by IOAPIC.
It fixes https://bugzilla.kernel.org/show_bug.cgi?id=84381.
This regression was introduced with commit 6b9fb7082409 "x86, ACPI,
irq: Consolidate algorithm of mapping (ioapic, pin) to IRQ number"
Reported-and-Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Thomas Richter <thor@math.tu-berlin.de>
Cc: rui.zhang@intel.com
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Link: http://lkml.kernel.org/r/1413816327-12850-1-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 134259105d18f9355b78cf1b2048192b5d63b2af
Author: Zhang Rui <rui.zhang@intel.com>
Date: Thu Oct 23 20:20:00 2014 +0800
ACPI: invoke acpi_device_wakeup() with correct parameters
commit 67598a1d3140a66f57aa6bcb8d22c4c2b7e910f5 upstream.
Fix a bug that invokes acpi_device_wakeup() with wrong parameters.
Fixes: f35cec255557 (ACPI / PM: Always enable wakeup GPEs when enabling device wakeup)
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 175ab34a6d88aadaeb316e5361d5b228f5b38733
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Thu Oct 23 13:26:21 2014 -0400
fix inode leaks on d_splice_alias() failure exits
commit 51486b900ee92856b977eacfc5bfbe6565028070 upstream.
d_splice_alias() callers expect it to either stash the inode reference
into a new alias, or drop the inode reference. That makes it possible
to just return d_splice_alias() result from ->lookup() instance, without
any extra housekeeping required.
Unfortunately, that should include the failure exits. If d_splice_alias()
returns an error, it leaves the dentry it has been given negative and
thus it *must* drop the inode reference. Easily fixed, but it goes way
back and will need backporting.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit aea133663ca27601109d419ad7d6f926050b1ced
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date: Tue Oct 21 09:27:12 2014 +0200
freezer: Do not freeze tasks killed by OOM killer
commit 51fae6da640edf9d266c94f36bc806c63c301991 upstream.
Since f660daac474c6f (oom: thaw threads if oom killed thread is frozen
before deferring) OOM killer relies on being able to thaw a frozen task
to handle OOM situation but a3201227f803 (freezer: make freezing() test
freeze conditions in effect instead of TIF_FREEZE) has reorganized the
code and stopped clearing freeze flag in __thaw_task. This means that
the target task only wakes up and goes into the fridge again because the
freezing condition hasn't changed for it. This reintroduces the bug
fixed by f660daac474c6f.
Fix the issue by checking for TIF_MEMDIE thread flag in
freezing_slow_path and exclude the task from freezing completely. If a
task was already frozen it would get woken by __thaw_task from OOM killer
and get out of freezer after rechecking freezing().
Changes since v1
- put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator
as per Oleg
- return __thaw_task into oom_scan_process_thread because
oom_kill_process will not wake task in the fridge because it is
sleeping uninterruptible
[mhocko@suse.cz: rewrote the changelog]
Fixes: a3201227f803 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE)
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Michal Hocko <mhocko@suse.cz>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18377d39177e358c4bb599f5de415cbd9ee0d882
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Oct 13 08:37:44 2014 -0700
intel_pstate: Correct BYT VID values.
commit d022a65ed2473fac4a600e3424503dc571160a3e upstream.
Using a VID value that is not high enough for the requested P state can
cause machine checks. Add a ceiling function to ensure calulated VIDs
with fractional values are set to the next highest integer VID value.
The algorythm for calculating the non-trubo VID from the BIOS writers
guide is:
vid_ratio = (vid_max - vid_min) / (max_pstate - min_pstate)
vid = ceiling(vid_min + (req_pstate - min_pstate) * vid_ratio)
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 57a14053d1b90d14f04fca3c21c315bad01c5329
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Oct 13 08:37:43 2014 -0700
intel_pstate: Fix BYT frequency reporting
commit b27580b05e6f5253228debc60b8ff4a786ff573a upstream.
BYT has a different conversion from P state to frequency than the core
processors. This causes the min/max and current frequency to be
misreported on some BYT SKUs. Tested on BYT N2820, Ivybridge and
Haswell processors.
Link: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6663
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 29cf079c2406a4e1fc443da2ecd6faa30754ebac
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Oct 13 08:37:42 2014 -0700
intel_pstate: Don't lose sysfs settings during cpu offline
commit c034871712730a33e0267095f48b62eae958499c upstream.
The user may have custom settings don't destroy them during suspend.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80651
Reported-by: Tobias Jakobi <liquid.acid@gmx.net>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 145d53ac79d439722e83d8087fa94c2c257fbdf5
Author: Matt Fleming <matt.fleming@intel.com>
Date: Fri Oct 3 13:06:33 2014 +0100
rtc: Disable EFI rtc for x86
commit 7efe665903d0d963b0ebf4cab25cc3ae32c62600 upstream.
commit da167ad7638759 ("rtc: ia64: allow other architectures to use EFI
RTC") inadvertently introduced a regression for x86 because we've been
careful not to enable the EFI rtc driver due to the generally buggy
implementations of the time-related EFI runtime services.
In fact, since the above commit was merged we've seen reports of crashes
on 32-bit tablets,
https://bugzilla.kernel.org/show_bug.cgi?id=84241#c21
Disable it explicitly for x86 so that we don't give users false hope
that this driver will work - it won't, and your machine is likely to
crash.
Acked-by: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6feaeb4e57450bb590122dd486509fff98f018fe
Author: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Date: Tue Oct 7 01:19:49 2014 +0100
x86: Add cpu_detect_cache_sizes to init_intel() add Quark legacy_cache()
commit aece118e487a744eafcdd0c77fe32b55ee2092a1 upstream.
Intel processors which don't report cache information via cpuid(2)
or cpuid(4) need quirk code in the legacy_cache_size callback to
report this data. For Intel that callback is is intel_size_cache().
This patch enables calling of cpu_detect_cache_sizes() inside of
init_intel() and hence the calling of the legacy_cache callback in
intel_size_cache(). Adding this call will ensure that PIII Tualatin
currently in intel_size_cache() and Quark SoC X1000 being added to
intel_size_cache() in this patch will report their respective cache
sizes.
This model of calling cpu_detect_cache_sizes() is consistent with
AMD/Via/Cirix/Transmeta and Centaur.
Also added is a string to idenitfy the Quark as Quark SoC X1000
giving better and more descriptive output via /proc/cpuinfo
Adding cpu_detect_cache_sizes to init_intel() will enable calling
of intel_size_cache() on Intel processors which currently no code
can reach. Therefore this patch will also re-enable reporting
of PIII Tualatin cache size information as well as add
Quark SoC X1000 support.
Comment text and cache flow logic suggested by Thomas Gleixner
Signed-off-by: Bryan O'Donoghue <pure.logic@nexus-software.ie>
Cc: davej@redhat.com
Cc: hmh@hmh.eng.br
Link: http://lkml.kernel.org/r/1412641189-12415-3-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 90f1b74c5020fc67a40a1ec4deefaab8674f8d4a
Author: David E. Box <david.e.box@linux.intel.com>
Date: Wed Sep 17 22:13:49 2014 -0700
x86/platform/intel/iosf: Add Braswell PCI ID
commit 849f5d894383d25c49132437aa289c9a9c98d5df upstream.
Add Braswell PCI ID to list of supported ID's for the IOSF driver.
Signed-off-by: David E. Box <david.e.box@linux.intel.com>
Link: http://lkml.kernel.org/r/1411017231-20807-2-git-send-email-david.e.box@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 372089844abaa2e8b633bfd432a3ff04ab9a222e
Author: Pali Rohár <pali.rohar@gmail.com>
Date: Thu Oct 16 01:16:51 2014 +0200
cpufreq: intel_pstate: Fix setting max_perf_pct in performance policy
commit 36b4bed5cd8f6e17019fa7d380e0836872c7b367 upstream.
Code which changes policy to powersave changes also max_policy_pct based on
max_freq. Code which change max_perf_pct has upper limit base on value
max_policy_pct. When policy is changing from powersave back to performance
then max_policy_pct is not changed. Which means that changing max_perf_pct is
not possible to high values if max_freq was too low in powersave policy.
Test case:
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
800000
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3300000
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
100
$ echo powersave > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
$ echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
$ echo 20 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
800000
$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
20
$ echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
$ echo 3300000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
$ echo 100 > /sys/devices/system/cpu/intel_pstate/max_perf_pct
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
3300000
$ cat /sys/devices/system/cpu/intel_pstate/max_perf_pct
24
And now intel_pstate driver allows to set maximal value for max_perf_pct based
on max_policy_pct which is 24 for previous powersave max_freq 800000.
This patch will set default value for max_policy_pct when setting policy to
performance so it will allow to set also max value for max_perf_pct.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 32c54bdcfa8fc6c77431a185e7907339021aa747
Author: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Date: Mon Oct 13 08:37:41 2014 -0700
cpufreq: intel_pstate: Reflect current no_turbo state correctly
commit 4521e1a0ce173daa23dfef8312d09051e057ff8e upstream.
Some BIOSes modify the state of MSR_IA32_MISC_ENABLE_TURBO_DISABLE
based on the current power source for the system battery AC vs
battery. Reflect the correct current state and ability to modify the
no_turbo sysfs file based on current state of
MSR_IA32_MISC_ENABLE_TURBO_DISABLE.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=83151
Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b79ac56d6276d7ca7a5dc9da194138e4c3e18bd6
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Mon Oct 13 08:37:40 2014 -0700
cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers
commit c034b02e213d271b98c45c4a7b54af8f69aaac1e upstream.
Currently the core does not expose scaling_cur_freq for set_policy()
drivers this breaks some userspace monitoring tools.
Change the core to expose this file for all drivers and if the
set_policy() driver supports the get() callback use it to retrieve the
current frequency.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=73741
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f31c1f7fb1b9542fbcec5e29334c90f883ef8f2
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Wed Oct 15 17:20:55 2014 -0400
drm/radeon: fix vm page table block size calculation
commit 8e66e134e20b936179ea1535dd4ed19ec4f99dba upstream.
The page offset is 12 bits. For example if we have an
8 GB VM, we'd need 33 bits. The number of bits needed
for PD + PT is 21 (33 - 12 or log2(8) + 18), not 20
(log2(8) + 17).
Noticed by Alexey during code review.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 831e17a958ea3bb289f780299a79fa1b06c8187b
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Oct 13 13:20:02 2014 -0400
drm/radeon: use gart memory for DMA ring tests
commit adfed2b0587289013f8143c54913ddfd44ac1fd3 upstream.
Avoids HDP cache flush issues when using vram which can
cause ring test failures on certain boards.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Alexander Fyodorov <halcy@yandex.ru>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ffe0245532b98efc4bc0e06f29c51d3f0e471152
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Oct 13 11:51:50 2014 -0400
drm/radeon: fix speaker allocation setup
commit 4910403836ded89803fab201d4b5caaa85de3a89 upstream.
If the sad_count is 0, set the hw to stereo and change
the error message to a warn. A lot of monitors don't
set the speaker allocation block.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 18c22448d791a5c329528e495f19b639dd7a3dec
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Tue Oct 7 18:02:52 2014 -0300
drm/i915: properly reenable gen8 pipe IRQs
commit 1180e20606fd7c5d76dc5b2a1594fa51ba5a0f31 upstream.
We were missing the pipe B/C vblank bits! Take a look at
gen8_de_irq_postinstall for a comparison.
This should fix a bunch of IGT tests.
There are a few more things we could improve on this code, but this
should be the minimal fix to unblock us.
v2: s/extra_iir/extra_ier/ because IIR doesn't make sense (Ville)
Bugzilla:https://bugs.freedesktop.org/show_bug.cgi?id=83640
Testcase: igt/*
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8989ebbfd33e144015b1a4a22bac998a3b144251
Author: U. Artie Eoff <ullysses.a.eoff@intel.com>
Date: Mon Sep 29 15:49:32 2014 -0700
drm/i915: intel_backlight scale() math WA
commit 673e7bbdb3920b62cfc6c710bea626b0a9b0f43a upstream.
Improper truncated integer division in the scale() function causes
actual_brightness != brightness. This (partial) work-around should be
sufficient for a majority of use-cases, but it is by no means a complete
solution.
TODO: Determine how best to scale "user" values to "hw" values, and
vice-versa, when the ranges are of different sizes. That would be a
buggy scenario even with this work-around.
The issue was introduced in the following (v3.17-rc1) commit:
6dda730 drm/i915: respect the VBT minimum backlight brightness
Note that for easier backporting this commit adds a duplicated macro.
A follow-up cleanup patch rectifies this for 3.18+
v2: (thanks to Chris Wilson) clarify commit message, use rounded division
macro
v3: -DIV_ROUND_CLOSEST() fails to build with CONFIG_X86_32=y. (Jani)
-Use DIV_ROUND_CLOSEST_ULL() instead. (Damien)
-v1 and v2 originally authored by Joe Konno.
Signed-off-by: U. Artie Eoff <ullysses.a.eoff@intel.com>
Reviewed-By: Joe Konno <joe.konno@intel.com>
[danvet: Add backporting note.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2a0a68a350d188451611a23c34e79cc8b52a16bb
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Oct 20 15:49:33 2014 +1000
drm/nouveau: fix regression on agp boards
commit 67e26e41ff8aa514826dae79f0b10169b5ba93b4 upstream.
Extends the fix in f2f9a2cbaf019481feefe231f996d3602612fa99 to also
workaround permission issues noticed by people using AGP systems.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 062999749f1eeabeba0614234314d8d9bbf868be
Author: Brian Silverman <bsilver16384@gmail.com>
Date: Sat Oct 25 20:20:37 2014 -0400
futex: Fix a race condition between REQUEUE_PI and task death
commit 30a6b8031fe14031ab27c1fa3483cb9780e7f63c upstream.
free_pi_state and exit_pi_state_list both clean up futex_pi_state's.
exit_pi_state_list takes the hb lock first, and most callers of
free_pi_state do too. requeue_pi doesn't, which means free_pi_state
can free the pi_state out from under exit_pi_state_list. For example:
task A | task B
exit_pi_state_list |
pi_state = |
curr->pi_state_list->next |
| futex_requeue(requeue_pi=1)
| // pi_state is the same as
| // the one in task A
| free_pi_state(pi_state)
| list_del_init(&pi_state->list)
| kfree(pi_state)
list_del_init(&pi_state->list) |
Move the free_pi_state calls in requeue_pi to before it drops the hb
locks which it's already holding.
[ tglx: Removed a pointless free_pi_state() call and the hb->lock held
debugging. The latter comes via a seperate patch ]
Signed-off-by: Brian Silverman <bsilver16384@gmail.com>
Cc: austin.linux@gmail.com
Cc: darren@dvhart.com
Cc: peterz@infradead.org
Link: http://lkml.kernel.org/r/1414282837-23092-1-git-send-email-bsilver16384@gmail.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a6896378d1b8c4c2b5267cd09e052e3e6b604ddd
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date: Thu Oct 30 10:53:16 2014 -0400
ext4: prevent bugon on race between write/fcntl
commit a41537e69b4aa43f0fea02498c2595a81267383b upstream.
O_DIRECT flags can be toggeled via fcntl(F_SETFL). But this value checked
twice inside ext4_file_write_iter() and __generic_file_write() which
result in BUG_ON inside ext4_direct_IO.
Let's initialize iocb->private unconditionally.
TESTCASE: xfstest:generic/036 https://patchwork.ozlabs.org/patch/402445/
#TYPICAL STACK TRACE:
kernel BUG at fs/ext4/inode.c:2960!
invalid opcode: 0000 [#1] SMP
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 6 PID: 5505 Comm: aio-dio-fcntl-r Not tainted 3.17.0-rc2-00176-gff5c017 #161
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
task: ffff88080e95a7c0 ti: ffff88080f908000 task.ti: ffff88080f908000
RIP: 0010:[<ffffffff811fabf2>] [<ffffffff811fabf2>] ext4_direct_IO+0x162/0x3d0
RSP: 0018:ffff88080f90bb58 EFLAGS: 00010246
RAX: 0000000000000400 RBX: ffff88080fdb2a28 RCX: 00000000a802c818
RDX: 0000040000080000 RSI: ffff88080d8aeb80 RDI: 0000000000000001
RBP: ffff88080f90bbc8 R08: 0000000000000000 R09: 0000000000001581
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88080d8aeb80
R13: ffff88080f90bbf8 R14: ffff88080fdb28c8 R15: ffff88080fdb2a28
FS: 00007f23b2055700(0000) GS:ffff880818400000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f23b2045000 CR3: 000000080cedf000 CR4: 00000000000407e0
Stack:
ffff88080f90bb98 0000000000000000 7ffffffffffffffe ffff88080fdb2c30
0000000000000200 0000000000000200 0000000000000001 0000000000000200
ffff88080f90bbc8 ffff88080fdb2c30 ffff88080f90be08 0000000000000200
Call Trace:
[<ffffffff8112ca9d>] generic_file_direct_write+0xed/0x180
[<ffffffff8112f2b2>] __generic_file_write_iter+0x222/0x370
[<ffffffff811f495b>] ext4_file_write_iter+0x34b/0x400
[<ffffffff811bd709>] ? aio_run_iocb+0x239/0x410
[<ffffffff811bd709>] ? aio_run_iocb+0x239/0x410
[<ffffffff810990e5>] ? local_clock+0x25/0x30
[<ffffffff810abd94>] ? __lock_acquire+0x274/0x700
[<ffffffff811f4610>] ? ext4_unwritten_wait+0xb0/0xb0
[<ffffffff811bd756>] aio_run_iocb+0x286/0x410
[<ffffffff810990e5>] ? local_clock+0x25/0x30
[<ffffffff810ac359>] ? lock_release_holdtime+0x29/0x190
[<ffffffff811bc05b>] ? lookup_ioctx+0x4b/0xf0
[<ffffffff811bde3b>] do_io_submit+0x55b/0x740
[<ffffffff811bdcaa>] ? do_io_submit+0x3ca/0x740
[<ffffffff811be030>] SyS_io_submit+0x10/0x20
[<ffffffff815ce192>] system_call_fastpath+0x16/0x1b
Code: 01 48 8b 80 f0 01 00 00 48 8b 18 49 8b 45 10 0f 85 f1 01 00 00 48 03 45 c8 48 3b 43 48 0f 8f e3 01 00 00 49 83 7c
24 18 00 75 04 <0f> 0b eb fe f0 ff 83 ec 01 00 00 49 8b 44 24 18 8b 00 85 c0 89
RIP [<ffffffff811fabf2>] ext4_direct_IO+0x162/0x3d0
RSP <ffff88080f90bb58>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d7e281b07d4dc9ef18c5bd984e1ba41d8bbd05a
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date: Thu Oct 30 10:53:16 2014 -0400
ext4: enable journal checksum when metadata checksum feature enabled
commit 98c1a7593fa355fda7f5a5940c8bf5326ca964ba upstream.
If metadata checksumming is turned on for the FS, we need to tell the
journal to use checksumming too.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c8907b5f04fc1c1d9d1a03238eeb2d7f2b47756c
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 30 10:52:57 2014 -0400
ext4: fix overflow when updating superblock backups after resize
commit 9378c6768e4fca48971e7b6a9075bc006eda981d upstream.
When there are no meta block groups update_backups() will compute the
backup block in 32-bit arithmetics thus possibly overflowing the block
number and corrupting the filesystem. OTOH filesystems without meta
block groups larger than 16 TB should be rare. Fix the problem by doing
the counting in 64-bit arithmetics.
Coverity-id: 741252
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 34ce60ba58276889897b573e2d1a78e5c2af68e7
Author: Jan Kara <jack@suse.cz>
Date: Thu Oct 30 10:53:16 2014 -0400
ext4: fix oops when loading block bitmap failed
commit 599a9b77ab289d85c2d5c8607624efbe1f552b0f upstream.
When we fail to load block bitmap in __ext4_new_inode() we will
dereference NULL pointer in ext4_journal_get_write_access(). So check
for error from ext4_read_block_bitmap().
Coverity-id: 989065
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1e2a3067af88c6829630b64a91a56eee114b9f52
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date: Tue Oct 14 02:35:49 2014 -0400
ext4: check s_chksum_driver when looking for bg csum presence
commit 813d32f91333e4c33d5a19b67167c4bae42dae75 upstream.
Convert the ext4_has_group_desc_csum predicate to look for a checksum
driver instead of the metadata_csum flag and change the bg checksum
calculation function to look for GDT_CSUM before taking the crc16
path.
Without this patch, if we mount with ^uninit_bg,^metadata_csum and
later metadata_csum gets turned on by accident, the block group
checksum functions will incorrectly assume that checksumming is
enabled (metadata_csum) but that crc16 should be used
(!s_chksum_driver). This is totally wrong, so fix the predicate
and the checksum formula selection.
(Granted, if the metadata_csum feature bit gets enabled on a live FS
then something underhanded is going on, but we could at least avoid
writing garbage into the on-disk fields.)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dcd14a65c2cfdf2adbd8b13a60ae894dbe3ec291
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date: Mon Oct 13 03:42:12 2014 -0400
ext4: move error report out of atomic context in ext4_init_block_bitmap()
commit aef4885ae14f1df75b58395c5314d71f613d26d9 upstream.
Error report likely result in IO so it is bad idea to do it from
atomic context.
This patch should fix following issue:
BUG: sleeping function called from invalid context at include/linux/buffer_head.h:349
in_atomic(): 1, irqs_disabled(): 0, pid: 137, name: kworker/u128:1
5 locks held by kworker/u128:1/137:
#0: ("writeback"){......}, at: [<ffffffff81085618>] process_one_work+0x228/0x4d0
#1: ((&(&wb->dwork)->work)){......}, at: [<ffffffff81085618>] process_one_work+0x228/0x4d0
#2: (jbd2_handle){......}, at: [<ffffffff81242622>] start_this_handle+0x712/0x7b0
#3: (&ei->i_data_sem){......}, at: [<ffffffff811fa387>] ext4_map_blocks+0x297/0x430
#4: (&(&bgl->locks[i].lock)->rlock){......}, at: [<ffffffff811f3180>] ext4_read_block_bitmap_nowait+0x5d0/0x630
CPU: 3 PID: 137 Comm: kworker/u128:1 Not tainted 3.17.0-rc2-00184-g82752e4 #165
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
Workqueue: writeback bdi_writeback_workfn (flush-1:0)
0000000000000411 ffff880813777288 ffffffff815c7fdc ffff880813777288
ffff880813a8bba0 ffff8808137772a8 ffffffff8108fb30 ffff880803e01e38
ffff880803e01e38 ffff8808137772c8 ffffffff811a8d53 ffff88080ecc6000
Call Trace:
[<ffffffff815c7fdc>] dump_stack+0x51/0x6d
[<ffffffff8108fb30>] __might_sleep+0xf0/0x100
[<ffffffff811a8d53>] __sync_dirty_buffer+0x43/0xe0
[<ffffffff811a8e03>] sync_dirty_buffer+0x13/0x20
[<ffffffff8120f581>] ext4_commit_super+0x1d1/0x230
[<ffffffff8120fa03>] save_error_info+0x23/0x30
[<ffffffff8120fd06>] __ext4_error+0xb6/0xd0
[<ffffffff8120f260>] ? ext4_group_desc_csum+0x140/0x190
[<ffffffff811f2d8c>] ext4_read_block_bitmap_nowait+0x1dc/0x630
[<ffffffff8122e23a>] ext4_mb_init_cache+0x21a/0x8f0
[<ffffffff8113ae95>] ? lru_cache_add+0x55/0x60
[<ffffffff8112e16c>] ? add_to_page_cache_lru+0x6c/0x80
[<ffffffff8122eaa0>] ext4_mb_init_group+0x190/0x280
[<ffffffff8122ec51>] ext4_mb_good_group+0xc1/0x190
[<ffffffff8123309a>] ext4_mb_regular_allocator+0x17a/0x410
[<ffffffff8122c821>] ? ext4_mb_use_preallocated+0x31/0x380
[<ffffffff81233535>] ? ext4_mb_new_blocks+0x205/0x8e0
[<ffffffff8116ed5c>] ? kmem_cache_alloc+0xfc/0x180
[<ffffffff812335b0>] ext4_mb_new_blocks+0x280/0x8e0
[<ffffffff8116f2c4>] ? __kmalloc+0x144/0x1c0
[<ffffffff81221797>] ? ext4_find_extent+0x97/0x320
[<ffffffff812257f4>] ext4_ext_map_blocks+0xbc4/0x1050
[<ffffffff811fa387>] ? ext4_map_blocks+0x297/0x430
[<ffffffff811fa3ab>] ext4_map_blocks+0x2bb/0x430
[<ffffffff81200e43>] ? ext4_init_io_end+0x23/0x50
[<ffffffff811feb44>] ext4_writepages+0x564/0xaf0
[<ffffffff815cde3b>] ? _raw_spin_unlock+0x2b/0x40
[<ffffffff810ac7bd>] ? lock_release_non_nested+0x2fd/0x3c0
[<ffffffff811a009e>] ? writeback_sb_inodes+0x10e/0x490
[<ffffffff811a009e>] ? writeback_sb_inodes+0x10e/0x490
[<ffffffff811377e3>] do_writepages+0x23/0x40
[<ffffffff8119c8ce>] __writeback_single_inode+0x9e/0x280
[<ffffffff811a026b>] writeback_sb_inodes+0x2db/0x490
[<ffffffff811a0664>] wb_writeback+0x174/0x2d0
[<ffffffff810ac359>] ? lock_release_holdtime+0x29/0x190
[<ffffffff811a0863>] wb_do_writeback+0xa3/0x200
[<ffffffff811a0a40>] bdi_writeback_workfn+0x80/0x230
[<ffffffff81085618>] ? process_one_work+0x228/0x4d0
[<ffffffff810856cd>] process_one_work+0x2dd/0x4d0
[<ffffffff81085618>] ? process_one_work+0x228/0x4d0
[<ffffffff81085c1d>] worker_thread+0x35d/0x460
[<ffffffff810858c0>] ? process_one_work+0x4d0/0x4d0
[<ffffffff810858c0>] ? process_one_work+0x4d0/0x4d0
[<ffffffff8108a885>] kthread+0xf5/0x100
[<ffffffff810990e5>] ? local_clock+0x25/0x30
[<ffffffff8108a790>] ? __init_kthread_worker+0x70/0x70
[<ffffffff815ce2ac>] ret_from_fork+0x7c/0xb0
[<ffffffff8108a790>] ? __init_kthread_work
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b3b37b28739a07d9daf8a5e8d2415cbc4df1022
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date: Mon Oct 13 03:36:16 2014 -0400
ext4: Replace open coded mdata csum feature to helper function
commit 9aa5d32ba269bec0e7eaba2697a986a7b0bc8528 upstream.
Besides the fact that this replacement improves code readability
it also protects from errors caused direct EXT4_S(sb)->s_es manipulation
which may result attempt to use uninitialized csum machinery.
#Testcase_BEGIN
IMG=/dev/ram0
MNT=/mnt
mkfs.ext4 $IMG
mount $IMG $MNT
#Enable feature directly on disk, on mounted fs
tune2fs -O metadata_csum $IMG
# Provoke metadata update, likey result in OOPS
touch $MNT/test
umount $MNT
#Testcase_END
# Replacement script
@@
expression E;
@@
- EXT4_HAS_RO_COMPAT_FEATURE(E, EXT4_FEATURE_RO_COMPAT_METADATA_CSUM)
+ ext4_has_metadata_csum(E)
https://bugzilla.kernel.org/show_bug.cgi?id=82201
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a1d6b55a49da98f92ffecb44909d5847dcac506d
Author: Eric Sandeen <sandeen@redhat.com>
Date: Sat Oct 11 19:51:17 2014 -0400
ext4: fix reservation overflow in ext4_da_write_begin
commit 0ff8947fc5f700172b37cbca811a38eb9cb81e08 upstream.
Delalloc write journal reservations only reserve 1 credit,
to update the inode if necessary. However, it may happen
once in a filesystem's lifetime that a file will cross
the 2G threshold, and require the LARGE_FILE feature to
be set in the superblock as well, if it was not set already.
This overruns the transaction reservation, and can be
demonstrated simply on any ext4 filesystem without the LARGE_FILE
feature already set:
dd if=/dev/zero of=testfile bs=1 seek=2147483646 count=1 \
conv=notrunc of=testfile
sync
dd if=/dev/zero of=testfile bs=1 seek=2147483647 count=1 \
conv=notrunc of=testfile
leads to:
EXT4-fs: ext4_do_update_inode:4296: aborting transaction: error 28 in __ext4_handle_dirty_super
EXT4-fs error (device loop0) in ext4_do_update_inode:4301: error 28
EXT4-fs error (device loop0) in ext4_reserve_inode_write:4757: Readonly filesystem
EXT4-fs error (device loop0) in ext4_dirty_inode:4876: error 28
EXT4-fs error (device loop0) in ext4_da_write_end:2685: error 28
Adjust the number of credits based on whether the flag is
already set, and whether the current write may extend past the
LARGE_FILE limit.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5be56bf0f1040b9b05cc3fc1ed0e9e4816385c74
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sun Oct 5 22:47:07 2014 -0400
ext4: don't orphan or truncate the boot loader inode
commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream.
The boot loader inode (inode #5) should never be visible in the
directory hierarchy, but it's possible if the file system is corrupted
that there will be a directory entry that points at inode #5. In
order to avoid accidentally trashing it, when such a directory inode
is opened, the inode will be marked as a bad inode, so that it's not
possible to modify (or read) the inode from userspace.
Unfortunately, when we unlink this (invalid/illegal) directory entry,
we will put the bad inode on the ophan list, and then when try to
unlink the directory, we don't actually remove the bad inode from the
orphan list before freeing in-memory inode structure. This means the
in-memory orphan list is corrupted, leading to a kernel oops.
In addition, avoid truncating a bad inode in ext4_destroy_inode(),
since truncating the boot loader inode is not a smart thing to do.
Reported-by: Sami Liedes <sami.liedes@iki.fi>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 207c775cb6c23f2ae887a058f0563344773f77ae
Author: Theodore Ts'o <tytso@mit.edu>
Date: Sun Oct 5 22:56:00 2014 -0400
ext4: add ext4_iget_normal() which is to be used for dir tree lookups
commit f4bb2981024fc91b23b4d09a8817c415396dbabb upstream.
If there is a corrupted file system which has directory entries that
point at reserved, metadata inodes, prohibit them from being used by
treating them the same way we treat Boot Loader inodes --- that is,
mark them to be bad inodes. This prohibits them from being opened,
deleted, or modified via chmod, chown, utimes, etc.
In particular, this prevents a corrupted file system which has a
directory entry which points at the journal inode from being deleted
and its blocks released, after which point Much Hilarity Ensues.
Reported-by: Sami Liedes <sami.liedes@iki.fi>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1eb9fed3620abb513aa21c49a2a2b8e874d9856c
Author: Dmitry Monakhov <dmonakhov@openvz.org>
Date: Fri Oct 3 12:47:23 2014 -0400
ext4: grab missed write_count for EXT4_IOC_SWAP_BOOT
commit 3e67cfad22230ebed85c56cbe413876f33fea82b upstream.
Otherwise this provokes complain like follows:
WARNING: CPU: 12 PID: 5795 at fs/ext4/ext4_jbd2.c:48 ext4_journal_check_start+0x4e/0xa0()
Modules linked in: brd iTCO_wdt lpc_ich mfd_core igb ptp dm_mirror dm_region_hash dm_log dm_mod
CPU: 12 PID: 5795 Comm: python Not tainted 3.17.0-rc2-00175-gae5344f #158
Hardware name: Intel Corporation W2600CR/W2600CR, BIOS SE5C600.86B.99.99.x028.061320111235 06/13/2011
0000000000000030 ffff8808116cfd28 ffffffff815c7dfc 0000000000000030
0000000000000000 ffff8808116cfd68 ffffffff8106ce8c ffff8808116cfdc8
ffff880813b16000 ffff880806ad6ae8 ffffffff81202008 0000000000000000
Call Trace:
[<ffffffff815c7dfc>] dump_stack+0x51/0x6d
[<ffffffff8106ce8c>] warn_slowpath_common+0x8c/0xc0
[<ffffffff81202008>] ? ext4_ioctl+0x9e8/0xeb0
[<ffffffff8106ceda>] warn_slowpath_null+0x1a/0x20
[<ffffffff8122867e>] ext4_journal_check_start+0x4e/0xa0
[<ffffffff81228c10>] __ext4_journal_start_sb+0x90/0x110
[<ffffffff81202008>] ext4_ioctl+0x9e8/0xeb0
[<ffffffff8107b0bd>] ? ptrace_stop+0x24d/0x2f0
[<ffffffff81088530>] ? alloc_pid+0x480/0x480
[<ffffffff8107b1f2>] ? ptrace_do_notify+0x92/0xb0
[<ffffffff81186545>] do_vfs_ioctl+0x4e5/0x550
[<ffffffff815cdbcb>] ? _raw_spin_unlock_irq+0x2b/0x40
[<ffffffff81186603>] SyS_ioctl+0x53/0x80
[<ffffffff815ce2ce>] tracesys+0xd0/0xd5
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c8cdbdb2ac79a73d444b35d1d3b6291eb97c48db
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 1 21:49:46 2014 -0400
ext4: fix mmap data corruption when blocksize < pagesize
commit d6320cbfc92910a3e5f10c42d98c231c98db4f60 upstream.
Use truncate_isize_extended() when hole is being created in a file so that
->page_mkwrite() will get called for the partial tail page if it is
mmaped (see the first patch in the series for details).
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2fc80ca89a98e144d12e86382c34cb9c12be47fc
Author: Jan Kara <jack@suse.cz>
Date: Thu Sep 18 01:12:15 2014 -0400
ext4: don't check quota format when there are no quota files
commit 279bf6d390933d5353ab298fcc306c391a961469 upstream.
The check whether quota format is set even though there are no
quota files with journalled quota is pointless and it actually
makes it impossible to turn off journalled quotas (as there's
no way to unset journalled quota format). Just remove the check.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f13b1f78f3ac1011f087e0ce46f365c2f060038a
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date: Tue Sep 16 14:34:59 2014 -0400
ext4: check EA value offset when loading
commit a0626e75954078cfacddb00a4545dde821170bc5 upstream.
When loading extended attributes, check each entry's value offset to
make sure it doesn't collide with the entries.
Without this check it is easy to crash the kernel by mounting a
malicious FS containing a file with an EA wherein e_value_offs = 0 and
e_value_size > 0 and then deleting the EA, which corrupts the name
list.
(See the f_ea_value_crash test's FS image in e2fsprogs for an example.)
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dbcd57f790014d6b892525f24f699321a866ac3c
Author: Darrick J. Wong <darrick.wong@oracle.com>
Date: Tue Sep 16 14:43:09 2014 -0400
jbd2: free bh when descriptor block checksum fails
commit 064d83892e9ba547f7d4eae22cbca066d95210ce upstream.
Free the buffer head if the journal descriptor block fails checksum
verification.
This is the jbd2 port of the e2fsprogs patch "e2fsck: free bh on csum
verify error in do_one_pass".
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7de4d736135ecbb1f03548746c13f774bbbf06bd
Author: Marc-André Lureau <marcandre.lureau@gmail.com>
Date: Thu Oct 16 11:39:44 2014 +0200
qxl: don't create too large primary surface
commit c572aaf46f71f63ae5914d4e194a955e0ba1b519 upstream.
Limit primary to qemu vgamem size, to avoid reaching
qemu guest bug "requested primary larger than framebuffer"
on resizing screen too large to fit.
Remove unneeded and misleading variables.
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1127552
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e9fe9029bb54ddac7efc83fa4c70ed83f1edef1c
Author: David Daney <david.daney@cavium.com>
Date: Mon Oct 20 15:34:23 2014 -0700
MIPS: tlbex: Properly fix HUGE TLB Refill exception handler
commit 9e0f162a36914937a937358fcb45e0609ef2bfc4 upstream.
In commit 8393c524a25609 (MIPS: tlbex: Fix a missing statement for
HUGETLB), the TLB Refill handler was fixed so that non-OCTEON targets
would work properly with huge pages. The change was incorrect in that
it broke the OCTEON case.
The problem is shown here:
xxx0: df7a0000 ld k0,0(k1)
.
.
.
xxxc0: df610000 ld at,0(k1)
xxxc4: 335a0ff0 andi k0,k0,0xff0
xxxc8: e825ffcd bbit1 at,0x5,0x0
xxxcc: 003ad82d daddu k1,at,k0
.
.
.
In the non-octeon case there is a destructive test for the huge PTE
bit, and then at 0, $k0 is reloaded (that is what the 8393c524a25609
patch added).
In the octeon case, we modify k1 in the branch delay slot, but we
never need k0 again, so the new load is not needed, but since k1 is
modified, if we do the load, we load from a garbage location and then
get a nested TLB Refill, which is seen in userspace as either SIGBUS
or SIGSEGV (depending on the garbage).
The real fix is to only do this reloading if it is needed, and never
where it is harmful.
Signed-off-by: David Daney <david.daney@cavium.com>
Cc: Huacai Chen <chenhc@lemote.com>
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8151/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7392d3e8a19f6ccd13a3066393e0f9ab339c1041
Author: Markos Chandras <markos.chandras@imgtec.com>
Date: Mon Oct 20 09:39:31 2014 +0100
MIPS: ftrace: Fix a microMIPS build problem
commit aedd153f5bb5b1f1d6d9142014f521ae2ec294cc upstream.
Code before the .fixup section needs to have the .insn directive.
This has no side effects on MIPS32/64 but it affects the way microMIPS
loads the address for the return label.
Fixes the following build problem:
mips-linux-gnu-ld: arch/mips/built-in.o: .fixup+0x4a0: Unsupported jump between
ISA modes; consider recompiling with interlinking enabled.
mips-linux-gnu-ld: final link failed: Bad value
Makefile:819: recipe for target 'vmlinux' failed
The fix is similar to 1658f914ff91c3bf ("MIPS: microMIPS:
Disable LL/SC and fix linker bug.")
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8117/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f34355e567eb3fffdb6a5a875fde4e955d7d15e7
Author: Markos Chandras <markos.chandras@imgtec.com>
Date: Tue Oct 21 10:21:54 2014 +0100
MIPS: cp1emu: Fix ISA restrictions for cop1x_op instructions
commit a5466d7bba9af83a82cc7c081b2a7d557cde3204 upstream.
Commit 08a07904e1828 ("MIPS: math-emu: Remove most ifdefery") removed
the #ifdef ISA conditions and switched to runtime detection. However,
according to the instruction set manual, the cop1x_op instructions are
available in >=MIPS32r2 as well. This fixes a problem on MIPS32r2
with the ntpd package which failed to execute with a SIGILL exit code due
to the fact that a madd.d instruction was not being emulated.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Fixes: 08a07904e1828 ("MIPS: math-emu: Remove most ifdefery")
Cc: linux-mips@linux-mips.org
Reviewed-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: Markos Chandras <markos.chandras@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/8173/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9c5aecb6b0b7c0815a0494d82684466e3c914307
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date: Sun Sep 21 15:38:43 2014 +0300
MIPS: loongson2_cpufreq: Fix CPU clock rate setting mismerge
commit aa08ed55442ac6f9810c055e1474be34e785e556 upstream.
During 3.16 merge window, parts of the commit 8e8acb32960f
(MIPS/loongson2_cpufreq: Fix CPU clock rate setting) seem to have
been deleted probably due to a mismerge, and as a result cpufreq
is broken again on Loongson2 boards in 3.16 and newer kernels.
Fix by repeating the fix.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7835/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c73d8aa65c6228e9527ed29ae54db52534775984
Author: Aaro Koskinen <aaro.koskinen@iki.fi>
Date: Tue Oct 14 00:42:08 2014 +0300
MIPS: ptrace.h: Add a missing include
commit cdb685ad44996e9a113a10002cb42d40ff29db99 upstream.
Commit a79ebea62010 (MIPS: ptrace: Fix user pt_regs definition,
use in ptrace_{get, set}regs()) converted struct pt_regs to use __u64.
Some userspace applications (e.g. GDB) include this file directly,
and fail to see this type. Fix by including <linux/types.h>.
The patch fixes the following build failure with GDB 7.8 when using
GLIBC headers created against Linux 3.17:
In file included from /home/aaro/los/work/shared/gdb-7.8/gdb/mips-linux-nat.c:37:0:
/home/aaro/los/work/mips/rootfs/mips-linux-gnu/usr/include/asm/ptrace.h:32:2: error: unknown type name '__u64'
__u64 regs[32];
^
/home/aaro/los/work/mips/rootfs/mips-linux-gnu/usr/include/asm/ptrace.h:35:2: error: unknown type name '__u64'
__u64 lo;
^
/home/aaro/los/work/mips/rootfs/mips-linux-gnu/usr/include/asm/ptrace.h:36:2: error: unknown type name '__u64'
__u64 hi;
^
Fixes: a79ebea62010 ("MIPS: ptrace: Fix user pt_regs definition, use in ptrace_{get, set}regs()")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Cc: Alex Smith <alex@alex-smith.me.uk>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/8067/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 321ea2b59f850e879a728a4192d34e428ae6654a
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Sat Oct 4 04:23:15 2014 +0000
target: Fix APTPL metadata handling for dynamic MappedLUNs
commit e24805637d2d270d7975502e9024d473de86afdb upstream.
This patch fixes a bug in handling of SPC-3 PR Activate Persistence
across Target Power Loss (APTPL) logic where re-creation of state for
MappedLUNs from dynamically generated NodeACLs did not occur during
I_T Nexus establishment.
It adds the missing core_scsi3_check_aptpl_registration() call during
core_tpg_check_initiator_node_acl() -> core_tpg_add_node_to_devs() in
order to replay any pre-loaded APTPL metadata state associated with
the newly connected SCSI Initiator Port.
Cc: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7effee5dc12ae7bee6b13befd437801c44d9fd1e
Author: Quinn Tran <quinn.tran@qlogic.com>
Date: Thu Sep 25 06:22:28 2014 -0400
target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE
commit 082f58ac4a48d3f5cb4597232cb2ac6823a96f43 upstream.
During temporary resource starvation at lower transport layer, command
is placed on queue full retry path, which expose this problem. The TCM
queue full handling of SCF_TRANSPORT_TASK_SENSE currently sends the same
cmd twice to lower layer. The 1st time led to cmd normal free path.
The 2nd time cause Null pointer access.
This regression bug was originally introduced v3.1-rc code in the
following commit:
commit e057f53308a5f071556ee80586b99ee755bf07f5
Author: Christoph Hellwig <hch@infradead.org>
Date: Mon Oct 17 13:56:41 2011 -0400
target: remove the transport_qf_callback se_cmd callback
Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bd9954b584c64eea1203d370352de5c6123bca61
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Sun Oct 5 02:13:03 2014 -0700
iser-target: Disable TX completion interrupt coalescing
commit 0d0f660d882c1c02748ced13966a2413aa5d6cc2 upstream.
This patch explicitly disables TX completion interrupt coalescing logic
in isert_put_response() and isert_put_datain() that was originally added
as an efficiency optimization in commit 95b60f07.
It has been reported that this change can trigger ABORT_TASK timeouts
under certain small block workloads, where disabling coalescing was
required for stability. According to Sagi, this doesn't impact
overall performance, so go ahead and disable it for now.
Reported-by: Moussa Ba <moussaba@micron.com>
Reported-by: Sagi Grimberg <sagig@dev.mellanox.co.il>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b24673ed3945ae9cab8ac84964c0e399e06374cc
Author: Joern Engel <joern@logfs.org>
Date: Fri Oct 3 14:35:56 2014 -0700
qla_target: don't delete changed nacls
commit f4c24db1b7ad0ce84409e15744d26c6f86a96840 upstream.
The code is currently riddled with "drop the hardware_lock to avoid a
deadlock" bugs that expose races. One of those races seems to expose a
valid warning in tcm_qla2xxx_clear_nacl_from_fcport_map. Add some
bandaid to it.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a3789f477075c8f686bb1ccde968884b1cb5108b
Author: Vineet Gupta <vgupta@synopsys.com>
Date: Sat Sep 27 12:53:41 2014 +0530
ARC: unbork FPU save/restore
commit 52e9bae93802bd29c33be11e9e758ad7daac805f upstream.
Fixes: 2ab402dfd65d15a4b2 "ARC: make start_thread() out-of-line"
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1e84e21883baed62003429a319fc41ee1a47e713
Author: Anton Kolesov <Anton.Kolesov@synopsys.com>
Date: Thu Sep 25 13:23:24 2014 +0400
ARC: Update order of registers in KGDB to match GDB 7.5
commit ebc0c74e76cec9c4dd860eb0ca1c0b39dc63c482 upstream.
Order of registers has changed in GDB moving from 6.8 to 7.5. This patch
updates KGDB to work properly with GDB 7.5, though makes it incompatible
with 6.8.
Signed-off-by: Anton Kolesov <Anton.Kolesov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 96b54d26c8a71ede8b02f95c00be61a1c48d8bd6
Author: Vineet Gupta <vgupta@synopsys.com>
Date: Fri Jun 20 16:24:49 2014 +0530
ARC: [nsimosci] Allow "headless" models to boot
commit 5c05483e2db91890faa9a7be0a831701a3f442d6 upstream.
There are certain test configuration of virtual platform which don't
have any real console device (uart/pgu). So add tty0 as a fallback console
device to allow system to boot and be accessible via telnet
Otherwise with ttyS0 as only console, but 8250 disabled in kernel build,
init chokes.
Reported-by: Anton Kolesov <akolesov@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 037d7f4c9fef4023562b993d93570aed1be24356
Author: Petr Matousek <pmatouse@redhat.com>
Date: Tue Sep 23 20:22:30 2014 +0200
kvm: vmx: handle invvpid vm exit gracefully
commit a642fc305053cc1c6e47e4f4df327895747ab485 upstream.
On systems with invvpid instruction support (corresponding bit in
IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid
causes vm exit, which is currently not handled and results in
propagation of unknown exit to userspace.
Fix this by installing an invvpid vm exit handler.
This is CVE-2014-3646.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cb2458058e9761059c6d94017e70dd06aada657c
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Thu Sep 18 22:39:39 2014 +0300
KVM: x86: Handle errors when RIP is set during far jumps
commit d1442d85cc30ea75f7d399474ca738e0bc96f715 upstream.
Far jmp/call/ret may fault while loading a new RIP. Currently KVM does not
handle this case, and may result in failed vm-entry once the assignment is
done. The tricky part of doing so is that loading the new CS affects the
VMCS/VMCB state, so if we fail during loading the new RIP, we are left in
unconsistent state. Therefore, this patch saves on 64-bit the old CS
descriptor and restores it if loading RIP failed.
This fixes CVE-2014-3647.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3dda9e902c39e2e541c5a27e3e13c47f33f3ea2a
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Thu Sep 18 22:39:38 2014 +0300
KVM: x86: Emulator fixes for eip canonical checks on near branches
commit 234f3ce485d54017f15cf5e0699cff4100121601 upstream.
Before changing rip (during jmp, call, ret, etc.) the target should be asserted
to be canonical one, as real CPUs do. During sysret, both target rsp and rip
should be canonical. If any of these values is noncanonical, a #GP exception
should occur. The exception to this rule are syscall and sysenter instructions
in which the assigned rip is checked during the assignment to the relevant
MSRs.
This patch fixes the emulator to behave as real CPUs do for near branches.
Far branches are handled by the next patch.
This fixes CVE-2014-3647.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 30cc44b473b287121be57c9c27d33b08acae7368
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Thu Sep 18 22:39:37 2014 +0300
KVM: x86: Fix wrong masking on relative jump/call
commit 05c83ec9b73c8124555b706f6af777b10adf0862 upstream.
Relative jumps and calls do the masking according to the operand size, and not
according to the address size as the KVM emulator does today.
This patch fixes KVM behavior.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7be26928ef58c515a25ae2f7c6e8272f451c662f
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Thu Sep 18 16:21:16 2014 +0300
kvm: x86: don't kill guest on unknown exit reason
commit 2bc19dc3754fc066c43799659f0d848631c44cfe upstream.
KVM_EXIT_UNKNOWN is a kvm bug, we don't really know whether it was
triggered by a priveledged application. Let's not kill the guest: WARN
and inject #UD instead.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fb559132e45c3c89fac8050099fb69a13aecaf8a
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Tue Sep 16 03:24:05 2014 +0300
KVM: x86: Check non-canonical addresses upon WRMSR
commit 854e8bb1aa06c578c2c9145fa6bfe3680ef63b23 upstream.
Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is
written to certain MSRs. The behavior is "almost" identical for AMD and Intel
(ignoring MSRs that are not implemented in either architecture since they would
anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if
non-canonical address is written on Intel but not on AMD (which ignores the top
32-bits).
Accordingly, this patch injects a #GP on the MSRs which behave identically on
Intel and AMD. To eliminate the differences between the architecutres, the
value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to
canonical value before writing instead of injecting a #GP.
Some references from Intel and AMD manuals:
According to Intel SDM description of WRMSR instruction #GP is expected on
WRMSR "If the source register contains a non-canonical address and ECX
specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE,
IA32_KERNEL_GS_BASE, IA32_LSTAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP."
According to AMD manual instruction manual:
LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the
LSTAR and CSTAR registers. If an RIP written by WRMSR is not in canonical
form, a general-protection exception (#GP) occurs."
IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the
base field must be in canonical form or a #GP fault will occur."
IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must
be in canonical form."
This patch fixes CVE-2014-3610.
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9ed3340ff2253a769253e559d8d0f240047a3757
Author: Andy Honig <ahonig@google.com>
Date: Wed Aug 27 14:42:54 2014 -0700
KVM: x86: Improve thread safety in pit
commit 2febc839133280d5a5e8e1179c94ea674489dae2 upstream.
There's a race condition in the PIT emulation code in KVM. In
__kvm_migrate_pit_timer the pit_timer object is accessed without
synchronization. If the race condition occurs at the wrong time this
can crash the host kernel.
This fixes CVE-2014-3611.
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b1bc00a31682b0e2dc1f536d76dfd36bcae3fa14
Author: Andy Honig <ahonig@google.com>
Date: Wed Aug 27 11:16:44 2014 -0700
KVM: x86: Prevent host from panicking on shared MSR writes.
commit 8b3c3104c3f4f706e99365c3e0d2aa61b95f969f upstream.
The previous patch blocked invalid writes directly when the MSR
is written. As a precaution, prevent future similar mistakes by
gracefulling handle GPs caused by writes to shared MSRs.
Signed-off-by: Andrew Honig <ahonig@google.com>
[Remove parts obsoleted by Nadav's patch. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eee4e1a9acbfaf5f0641c16c06e4cdd3b3418d3f
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Mon Oct 13 13:04:14 2014 +0300
KVM: x86: PREFETCH and HINT_NOP should have SrcMem flag
commit 3f6f1480d86bf9fc16c160d803ab1d006e3058d5 upstream.
The decode phase of the x86 emulator assumes that every instruction with the
ModRM flag, and which can be used with RIP-relative addressing, has either
SrcMem or DstMem. This is not the case for several instructions - prefetch,
hint-nop and clflush.
Adding SrcMem|NoAccess for prefetch and hint-nop and SrcMem for clflush.
This fixes CVE-2014-8480.
Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 04647769835cbcf32a4ad04731cf1f00e2d6f03a
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Mon Oct 13 13:04:13 2014 +0300
KVM: x86: Emulator does not decode clflush well
commit 13e457e0eebf0a0c82c38ceb890d93eb826d62a6 upstream.
Currently, all group15 instructions are decoded as clflush (e.g., mfence,
xsave). In addition, the clflush instruction requires no prefix (66/f2/f3)
would exist. If prefix exists it may encode a different instruction (e.g.,
clflushopt).
Creating a group for clflush, and different group for each prefix.
This has been the case forever, but the next patch needs the cflush group
in order to fix a bug introduced in 3.17.
Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 759caa76e2fb7f6037083e08194ece12745b92ef
Author: Nadav Amit <namit@cs.technion.ac.il>
Date: Fri Oct 3 01:10:04 2014 +0300
KVM: x86: Decoding guest instructions which cross page boundary may fail
commit 08da44aedba0f493e10695fa334348a7a4f72eb3 upstream.
Once an instruction crosses a page boundary, the size read from the second page
disregards the common case that part of the operand resides on the first page.
As a result, fetch of long insturctions may fail, and thereby cause the
decoding to fail as well.
Fixes: 5cfc7e0f5e5e1adf998df94f8e36edaf5d30d38e
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 022d987ebfec27dce57b40e763b02e8c47e55105
Author: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date: Fri Oct 17 22:55:59 2014 +0200
kvm: fix excessive pages un-pinning in kvm_iommu_map error path.
commit 3d32e4dbe71374a6780eaf51d719d76f9a9bf22f upstream.
The third parameter of kvm_unpin_pages() when called from
kvm_iommu_map_pages() is wrong, it should be the number of pages to un-pin
and not the page size.
This error was facilitated with an inconsistent API: kvm_pin_pages() takes
a size, but kvn_unpin_pages() takes a number of pages, so fix the problem
by matching the two.
This was introduced by commit 350b8bd ("kvm: iommu: fix the third parameter
of kvm_iommu_put_pages (CVE-2014-3601)"), which fixes the lack of
un-pinning for pages intended to be un-pinned (i.e. memory leak) but
unfortunately potentially aggravated the number of pages we un-pin that
should have stayed pinned. As far as I understand though, the same
practical mitigations apply.
This issue was found during review of Red Hat 6.6 patches to prepare
Ksplice rebootless updates.
Thanks to Vegard for his time on a late Friday evening to help me in
understanding this code.
Fixes: 350b8bd ("kvm: iommu: fix the third parameter of... (CVE-2014-3601)")
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Jamie Iles <jamie.iles@oracle.com>
Reviewed-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 56f2b2e46c25cf5321bfde3c05ce8505fc1e9e1a
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Thu Oct 23 14:54:14 2014 +0200
KVM: emulate: avoid accessing NULL ctxt->memopp
commit a430c9166312e1aa3d80bce32374233bdbfeba32 upstream.
A failure to decode the instruction can cause a NULL pointer access.
This is fixed simply by moving the "done" label as close as possible
to the return.
This fixes CVE-2014-8481.
Reported-by: Andy Lutomirski <luto@amacapital.net>
Fixes: 41061cdb98a0bec464278b4db8e894a3121671f5
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 768147da5b9a688fe3357cdadcbb17aca2a7216d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue Aug 5 05:11:13 2014 -0300
media: vmalloc_sg: off by one in error handling
commit 23d3090f8b44ab42162e99e8584445bc25b8922f upstream.
The "i--" needs to happen at the start of the loop or it will try to
release something bogus (probably it will crash) and it won't release
the first ->vaddr_page[].
Fixes: 7b4eeed174b7 ('[media] vmalloc_sg: make sure all pages in vmalloc area are really DMA-ready')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 534d3b6e0b33844e1ce8693f6ca65d1f9fc65d39
Author: Axel Lin <axel.lin@ingics.com>
Date: Fri Aug 8 10:32:56 2014 -0300
media: tda7432: Fix setting TDA7432_MUTE bit for TDA7432_RF register
commit 91ba0e59babdb3c7aca836a65f1095b3eaff7b06 upstream.
Fix a copy-paste bug when converting to the control framework.
Fixes: commit 5d478e0de871 ("[media] tda7432: convert to the control framework")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2d778860aa027457379118f6e9e86dcbbd9343c8
Author: Tomas Melin <tomas.melin@iki.fi>
Date: Tue Oct 28 15:43:14 2014 -0300
media: rc-core: fix protocol_change regression in ir_raw_event_register
commit 14edb593338e3811e818aba286237c365f8881a1 upstream.
IR receiver using nuvoton-cir and lirc required additional configuration
steps after upgrade from kernel 3.16 to 3.17-rcX. Bisected regression to
commit da6e162d6a4607362f8478c715c797d84d449f8b ("[media] rc-core:
simplify sysfs code").
The regression comes from adding function change_protocol in ir-raw.c.
It changes behaviour so that only the protocol enabled by driver's
map_name will be active after registration. This breaks user space
behaviour, lirc does not get key press signals anymore.
Enable lirc protocol by default for ir raw decoders to restore original
behaviour.
Signed-off-by: Tomas Melin <tomas.melin@iki.fi>
Acked-by: David Härdeman <david@hardeman.nu>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e533cbb47948cecf0af4d7d8990d0ae3c2c0b952
Author: Ulrich Eckhardt <uli-lirc@uli-eckhardt.de>
Date: Fri Oct 10 14:19:12 2014 -0300
media: ds3000: fix LNB supply voltage on Tevii S480 on initialization
commit 8c5bcded11cb607b1bb5920de3b9c882136d27db upstream.
The Tevii S480 outputs 18V on startup for the LNB supply voltage and does not
automatically power down. This blocks other receivers connected
to a satellite channel router (EN50494), since the receivers can not send the
required DiSEqC sequences when the Tevii card is connected to a the same SCR.
This patch switches off the LNB supply voltage on initialization of the frontend.
[mchehab@osg.samsung.com: add a comment about why we're explicitly
turning off voltage at device init]
Signed-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fb127d5136b113dc7c14fea545c6107104ab76cc
Author: Ulrich Eckhardt <uli-lirc@uli-eckhardt.de>
Date: Fri Oct 10 13:27:32 2014 -0300
media: imon: fix other RC type protocol support
commit d358aefdc0cc92b16ced449f998dbad639db6809 upstream.
With kernel 3.17 the imon remote control for device 15c2:0034 does not
work anymore, which uses the OTHER protocol. Only the front panel
buttons which uses the RC6 protocol are working.
Adds the missing comparison for the RC_BIT_OTHER.
Signed-off-by: Ulrich Eckhardt <uli@uli-eckhardt.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2691838d90588731f31a7eca3c3bd022ec64587c
Author: Frank Schaefer <fschaefer.oss@googlemail.com>
Date: Sat Aug 9 06:37:21 2014 -0300
media: em28xx-v4l: fix video buffer field order reporting in progressive mode
commit 662c97cf8f9e9d67d45d0a9f0c1565a1ede364c2 upstream.
The correct field order in progressive mode is V4L2_FIELD_NONE, not V4L2_FIELD_INTERLACED.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 525f3e77bcf3cb1162deaff773168f082e149023
Author: Frank Schaefer <fschaefer.oss@googlemail.com>
Date: Sat Aug 9 06:37:20 2014 -0300
media: em28xx-v4l: give back all active video buffers to the vb2 core properly on streaming stop
commit 627530c32a43283474e9dd3e954519410ffa033a upstream.
When a new video frame is started, the driver takes the next video buffer from
the list of active buffers and moves it to dev->usb_ctl.vid_buf / dev->usb_ctl.vbi_buf
for further processing.
On streaming stop we currently only give back the pending buffers from the list
but not the ones which are currently processed.
This causes the following warning from the vb2 core since kernel 3.15:
...
------------[ cut here ]------------
WARNING: CPU: 1 PID: 2284 at drivers/media/v4l2-core/videobuf2-core.c:2115 __vb2_queue_cancel+0xed/0x150 [videobuf2_core]()
[...]
Call Trace:
[<c0769c46>] dump_stack+0x48/0x69
[<c0245b69>] warn_slowpath_common+0x79/0x90
[<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
[<f925e4ad>] ? __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
[<c0245bfd>] warn_slowpath_null+0x1d/0x20
[<f925e4ad>] __vb2_queue_cancel+0xed/0x150 [videobuf2_core]
[<f925fa35>] vb2_internal_streamoff+0x35/0x90 [videobuf2_core]
[<f925fac5>] vb2_streamoff+0x35/0x60 [videobuf2_core]
[<f925fb27>] vb2_ioctl_streamoff+0x37/0x40 [videobuf2_core]
[<f8e45895>] v4l_streamoff+0x15/0x20 [videodev]
[<f8e4925d>] __video_do_ioctl+0x23d/0x2d0 [videodev]
[<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]
[<f8e48c63>] video_usercopy+0x203/0x5a0 [videodev]
[<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]
[<c039d0e7>] ? fsnotify+0x1e7/0x2b0
[<f8e49012>] video_ioctl2+0x12/0x20 [videodev]
[<f8e49020>] ? video_ioctl2+0x20/0x20 [videodev]
[<f8e4461e>] v4l2_ioctl+0xee/0x130 [videodev]
[<f8e44530>] ? v4l2_open+0xf0/0xf0 [videodev]
[<c0378de2>] do_vfs_ioctl+0x2e2/0x4d0
[<c0368eec>] ? vfs_write+0x13c/0x1c0
[<c0369a8f>] ? vfs_writev+0x2f/0x50
[<c0379028>] SyS_ioctl+0x58/0x80
[<c076fff3>] sysenter_do_call+0x12/0x12
---[ end trace 5545f934409f13f4 ]---
...
Many thanks to Hans Verkuil, whose recently added check in the vb2 core unveiled
this long standing issue and who has investigated it further.
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cef7b4202189a22bc498c11fe56f92babdfd6876
Author: Antti Palosaari <crope@iki.fi>
Date: Thu Aug 21 14:02:27 2014 -0300
media: m88ts2022: fix 32bit overflow on filter calc
commit f538e085138e519e25ae0828bd6c6e7492ce8ca4 upstream.
Maximum satellite symbol rate used is 45000000Sps which overflows
when multiplied by 135. As final calculation result is fraction,
we could use mult_frac macro in order to keep calculation inside
32 bit number limits and prevent overflow.
Original bug and fix was provided by Nibble Max. I decided to
implement it differently as it is now.
Reported-by: Nibble Max <nibble.max@gmail.com>
Tested-by: Nibble Max <nibble.max@gmail.com>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5e8d91d907d58964afb4c13c5173cd6876158a76
Author: Mauro Carvalho Chehab <m.chehab@samsung.com>
Date: Mon Aug 11 18:09:32 2014 -0300
media: siano: add support for PCTV 77e
commit 29bbb7bd0a65e01a0423e1df764676119b71ecb3 upstream.
Add support for PCTV microStick (77e) device that uses a sms1140
chipset.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b98e9bb0f504895604abd1f1d1a586ab51ee1c4d
Author: Frank Schaefer <fschaefer.oss@googlemail.com>
Date: Fri Dec 27 00:16:13 2013 -0300
media: em28xx: check if a device has audio earlier"
commit fb91bde9d3664dd879655f3a1013c0b5728e7a09 upstream.
GIT_AUTHOR_DATE=1409603039
This reverts
commit b99f0aadd33fad269c8e62b5bec8b5c012a44a56
Author: Mauro Carvalho Chehab <m.chehab@samsung.com>
[media] em28xx: check if a device has audio earlier
Better to split chipset detection from the audio setup. So, move the
detection code to em28xx_init_dev().
It broke analog audio of the Hauppauge winTV HVR 900 and very likely many other
em28xx devices.
Background:
The local variable has_audio in em28xx_usb_probe() describes if the currently
probed _usb_interface_ has an audio endpoint, while dev->audio_mode.has_audio
means that the _device_ as a whole provides analog audio.
Hence it is wrong to set dev->audio_mode.has_audio = has_audio in em28xx_usb_probe().
As result, audio support is no longer detected and configured on devices which
have the audio endpoint on a separate interface, because em28xx_audio_setup()
bails out immediately at the beginning.
Revert the faulty commit to restore the old audio detection procedure, which checks
the chip configuration register to determine if the device has analog audio.
Cc: <stable@vger.kernel.org> # 3.14 to 3.16
Reported-by: Oravecz Csaba <oravecz@nytud.mta.hu>
Tested-by: Oravecz Csaba <oravecz@nytud.mta.hu>
Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fa0e20007c07952e1caff5573d64ee18cab73cd5
Author: Paul Fertser <fercerpav@gmail.com>
Date: Sun Jun 8 12:16:48 2014 -0300
media: usb: uvc: add a quirk for Dell XPS M1330 webcam
commit 62ea864f84fed6e04dd033d500d4c9183a83d590 upstream.
As reported on [1], this device needs this quirk to be able to
reliably initialise the webcam.
[1] http://ubuntuforums.org/showthread.php?t=2145996
Cc: stable@vger.kernel.org
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 06de155cc6e9237cc21a10a382112e73cf9df81d
Author: Maciej Matraszek <m.matraszek@samsung.com>
Date: Mon Sep 15 05:14:48 2014 -0300
media: v4l2-common: fix overflow in v4l_bound_align_image()
commit 3bacc10cd4a85bc70bc0b6c001d3bf995c7fe04c upstream.
Fix clamp_align() used in v4l_bound_align_image() to prevent overflow
when passed large value like UINT32_MAX.
In the current implementation:
clamp_align(UINT32_MAX, 8, 8192, 3)
returns 8, because in line:
x = (x + (1 << (align - 1))) & mask;
x overflows to (-1 + 4) & 0x7 = 3, while expected value is 8192.
v4l_bound_align_image() is heavily used in VIDIOC_S_FMT and
VIDIOC_SUBDEV_S_FMT ioctls handlers, and documentation of the latter
explicitly states that:
"The modified format should be as close as possible to the original
request."
-- http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-subdev-g-fmt.html
Thus one would expect, that passing UINT32_MAX as format width and
height will result in setting maximum possible resolution for the
device. Particularly, when the driver doesn't support
VIDIOC_ENUM_FRAMESIZES ioctl, which is common in the codebase.
Fixes changeset: b0d3159be9a3
Signed-off-by: Maciej Matraszek <m.matraszek@samsung.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3ae7839f7a6a66cbf79f668d03581154549ec5d7
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Sep 15 21:11:51 2014 +1000
drm/gt214-/kms: fix hda eld regression
commit d889c52427d48c05f163f2f39b2cfc12e17e5266 upstream.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d336f0d8cbe205caf36bf81dedac48e9f34b73cb
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon Sep 8 10:33:32 2014 +1000
drm/nouveau/bios: memset dcb struct to zero before parsing
commit 595d373f1e9c9ce0fc946457fdb488e8a58972cd upstream.
Fixes type/mask calculation being based on uninitialised data for VGA
outputs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a315ab9712ffbea63b9b6a1847900b84b774b88
Author: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Date: Tue Sep 2 09:51:15 2014 -0300
drm/tilcdc: Fix the error path in tilcdc_load()
commit b478e336b3e75505707a11e78ef8b964ef0a03af upstream.
The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs in tilcdc_load().
To fix it, this commit adds proper labels to bail out at the different
stages in the load function, and release only the resources actually allocated.
Tested-by: Darren Etheridge <detheridge@ti.com>
Tested-by: Johannes Pointner <johannes.pointner@br-automation.com>
Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Fixes: 3a49012224ca ("drm/tilcdc: panel: fix leak when unloading the module")
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a9d77f51f7976fcd75d5ede42d5303c5009de3fd
Author: Josh Boyer <jwboyer@fedoraproject.org>
Date: Fri Sep 5 13:19:59 2014 -0400
drm/vmwgfx: Fix drm.h include
commit e351943b081f4d9e6f692ce1a6117e8d2e71f478 upstream.
The userspace drm.h include doesn't prefix the drm directory. This can lead
to compile failures as /usr/include/drm/ isn't in the standard gcc include
paths. Fix it to be <drm/drm.h>, which matches the rest of the driver drm
header files that get installed into /usr/include/drm.
Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759
Fixes: 1d7a5cbf8f74e
Reported-by: Jeffrey Bastian <jbastian@redhat.com>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0cdd3a68ac0ff940c84c696f9e22371b5377c5ce
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date: Fri Sep 26 15:05:22 2014 +0100
drm/i915: Do not leak pages when freeing userptr objects
commit c479f4383ea8940dd6f88da61798ad31feb33e51 upstream.
sg_alloc_table_from_pages() can build us a table with coalesced ranges which
means we need to iterate over pages and not sg table entries when releasing
page references.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Barbalho, Rafael" <rafael.barbalho@intel.com>
Tested-by: Rafael Barbalho <rafael.barbalho@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Remove unused local variable sg.]
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ca6cdd88da19163229b206ca9372a27ea0c0b035
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Sep 26 10:31:02 2014 +0100
drm/i915: Do not store the error pointer for a failed userptr registration
commit e9681366ea9e76ab8f75e84351f2f3ca63ee542c upstream.
If we fail to create our mmu notification, we report the error back and
currently store the error inside the i915_mm_struct. This not only causes
subsequent registerations of the same mm to fail (an issue if the first
was interrupted by a signal and needed to be restarted) but also causes
us to eventually try and free the error pointer.
[ 73.419599] BUG: unable to handle kernel NULL pointer dereference at 000000000000004c
[ 73.419831] IP: [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130
[ 73.420065] PGD 8650c067 PUD 870bb067 PMD 0
[ 73.420319] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[ 73.420580] CPU: 0 PID: 42 Comm: kworker/0:1 Tainted: G W 3.17.0-rc6+ #1561
[ 73.420837] Hardware name: Intel Corporation SandyBridge Platform/LosLunas CRB, BIOS ASNBCPT1.86C.0075.P00.1106281639 06/28/2011
[ 73.421405] Workqueue: events __i915_mm_struct_free__worker
[ 73.421724] task: ffff880088a81220 ti: ffff880088168000 task.ti: ffff880088168000
[ 73.422051] RIP: 0010:[<ffffffff8114af33>] [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130
[ 73.422410] RSP: 0018:ffff88008816bd50 EFLAGS: 00010286
[ 73.422765] RAX: 0000000000000003 RBX: ffff880086485400 RCX: 0000000000000000
[ 73.423137] RDX: ffff88016d80ee90 RSI: ffff880086485400 RDI: 0000000000000044
[ 73.423513] RBP: ffff88008816bd70 R08: 0000000000000001 R09: 0000000000000000
[ 73.423895] R10: 0000000000000320 R11: 0000000000000001 R12: 0000000000000044
[ 73.424282] R13: ffff880166e5f008 R14: ffff88016d815200 R15: ffff880166e5f040
[ 73.424682] FS: 0000000000000000(0000) GS:ffff88016d800000(0000) knlGS:0000000000000000
[ 73.425099] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 73.425537] CR2: 000000000000004c CR3: 0000000087f5f000 CR4: 00000000000407f0
[ 73.426157] Stack:
[ 73.426597] ffff880088a81248 ffff880166e5f038 fffffffffffffffc ffff880166e5f008
[ 73.427096] ffff88008816bd98 ffffffff814a75f2 ffff880166e5f038 ffff8800880f8a28
[ 73.427603] ffff88016d812ac0 ffff88008816be00 ffffffff8106321a ffffffff810631af
[ 73.428119] Call Trace:
[ 73.428606] [<ffffffff814a75f2>] __i915_mm_struct_free__worker+0x42/0x80
[ 73.429116] [<ffffffff8106321a>] process_one_work+0x1ba/0x610
[ 73.429632] [<ffffffff810631af>] ? process_one_work+0x14f/0x610
[ 73.430153] [<ffffffff810636db>] worker_thread+0x6b/0x4a0
[ 73.430671] [<ffffffff8108d67d>] ? trace_hardirqs_on+0xd/0x10
[ 73.431501] [<ffffffff81063670>] ? process_one_work+0x610/0x610
[ 73.432030] [<ffffffff8106a206>] kthread+0xf6/0x110
[ 73.432561] [<ffffffff8106a110>] ? __kthread_parkme+0x80/0x80
[ 73.433100] [<ffffffff8169c22c>] ret_from_fork+0x7c/0xb0
[ 73.433644] [<ffffffff8106a110>] ? __kthread_parkme+0x80/0x80
[ 73.434194] Code: 0f 1f 84 00 00 00 00 00 66 66 66 66 90 8b 46 4c 85 c0 0f 8e 10 01 00 00 55 48 89 e5 41 55 41 54 53 48 89 f3 49 89 fc 48 83 ec 08 <48> 83 7f 08 00 0f 84 b1 00 00 00 48 c7 c7 40 e6 ac 82 e8 26 65
[ 73.435942] RIP [<ffffffff8114af33>] mmu_notifier_unregister+0x23/0x130
[ 73.437017] RSP <ffff88008816bd50>
[ 73.437704] CR2: 000000000000004c
Fixes regression from commit ad46cb533d586fdb256855437af876617c6cf609
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Aug 7 14:20:40 2014 +0100
drm/i915: Prevent recursive deadlock on releasing a busy userptr
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84207
Testcase: igt/gem_render_copy_redux
Testcase: igt/gem_userptr_blits/create-destroy-sync
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jacek Danecki <jacek.danecki@intel.com>
Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
Cc: Jacek Danecki <jacek.danecki@intel.com>
Cc: "Ursulin, Tvrtko" <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit efbd644aaea7083e1a264da4bea73673fe640c99
Author: Emil Velikov <emil.l.velikov@gmail.com>
Date: Mon Sep 8 20:27:57 2014 +0100
drm/nouveau/gpio: rename g92 class to g94
commit b485a7005faba38286bc02ab1d80e2cbf61c1002 upstream.
nv92 hardware has only 16 interrupt lines, while nv94 and later
has 32. Accessing 0xe0c{0,4} registers on nv92 can lead to incorrect
PDISP setup. This is a regression introduced with
commit 9d0f5ec9ee0fd5dc5fc1cc2cf559286431e406e3
Author: Ben Skeggs <bskeggs@redhat.com>
Date: Mon May 12 15:22:42 2014 +1000
gpio: split g92 class from nv50
Reported-by: estece on #nouveau
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e7ae4dccc39860dfc8bbf0949ef207004692a4f7
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Tue Oct 7 19:04:58 2014 +1100
drm/ast: Fix HW cursor image
commit 1e99cfa8de0f0879091e33cd65fd60418d006ad9 upstream.
The translation from the X driver to the KMS one typo'ed a couple
of array indices, causing the HW cursor to look weird (blocky with
leaking edge colors). This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fedb1e978b3d017064e9591c185049538a5164ea
Author: Jason Gerecke <killertofu@gmail.com>
Date: Tue Sep 23 11:09:28 2014 -0700
HID: input: Fix TransducerSerialNumber implementation
commit 5989a55a4c9aafba8b152c6bf52244510c2b88b9 upstream.
The commit which introduced TransducerSerialNumber (368c966) is missing
two crucial implementation details. Firstly, the commit does not set the
type/code/bit/max fields as expected later down the code which can cause
the driver to crash when a tablet with this usage is connected. Secondly,
the call to 'set_bit' causes MSC_PULSELED to be sent instead of the
expected MSC_SERIAL. This commit addreses both issues.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ed9a984568179de2b1e77060170d29f51f15cd3f
Author: Hans de Goede <hdegoede@redhat.com>
Date: Fri Oct 24 14:55:24 2014 -0700
Input: i8042 - quirks for Fujitsu Lifebook A544 and Lifebook AH544
commit 993b3a3f80a7842a48cd46c2b41e1b3ef6302468 upstream.
These models need i8042.notimeout, otherwise the touchpad will not work.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=69731
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1111138
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 326bc16520eb2590345257c2783d823c765c7144
Author: Andreas Bosch <linux@progandy.de>
Date: Wed Oct 15 10:44:50 2014 -0700
Input: alps - fix v4 button press recognition
commit b0cfb794a3dd1d699f3e453f9180bd06508fb8f0 upstream.
Since the change to struct input_mt_pos some variables are now bitfields
instead of integers. Automatic conversion from integer to bitfield entry
destroys information, therefore enforce boolean interpretation instead.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1114768
Fixes: 02d04254a5df ("Input: alps - use struct input_mt_pos to track coordinates")
Signed-off-by: Andreas Bosch <linux@progandy.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5c45fb173c67c2adf05877a05a822768592d492
Author: Hans de Goede <hdegoede@redhat.com>
Date: Sat Oct 11 11:27:37 2014 -0700
Input: i8042 - add noloop quirk for Asus X750LN
commit 9ff84a17302aeb8913ff244ecc0d8f9d219fecb5 upstream.
Without this the aux port does not get detected, and consequently the
touchpad will not work.
https://bugzilla.redhat.com/show_bug.cgi?id=1110011
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d6e68ffe5915aa9acbdff7e50aa63f52be487c89
Author: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Date: Tue Sep 2 09:49:18 2014 -0700
Input: synaptics - gate forcepad support by DMI check
commit aa972409951e0675e07918620427517cad5090e0 upstream.
Unfortunately, ForcePad capability is not actually exported over PS/2, so
we have to resort to DMI checks.
Reported-by: Nicole Faerber <nicole.faerber@kernelconcepts.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4e3455d02c6d53647ae198e790235350ed54e2d9
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue Sep 16 12:40:26 2014 -0400
framebuffer: fix border color
commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.
The framebuffer code uses the current background color to fill the border
when switching consoles, however, this results in inconsistent behavior.
For example:
- start Midnigh Commander
- the border is black
- switch to another console and switch back
- the border is cyan
- type something into the command line in mc
- the border is cyan
- switch to another console and switch back
- the border is black
- press F9 to go to menu
- the border is black
- switch to another console and switch back
- the border is dark blue
When switching to a console with Midnight Commander, the border is random
color that was left selected by the slang subsystem.
This patch fixes this inconsistency by always using black as the
background color when switching consoles.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a3f70d3738224b36d7d67808391648223b6e0a7
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Tue Sep 16 12:38:53 2014 -0400
framebuffer: fix screen corruption when copying
commit 5b789da8a7fc357661fc61faaf853e9161cc9700 upstream.
The function bitcpy_rev has a bug that may result in screen corruption.
The bug happens under these conditions:
* the end of the destination area of a copy operation is aligned on a long
word boundary
* the end of the source area is not aligned on a long word boundary
* we are copying more than one long word
In this case, the variable shift is non-zero and the variable first is
zero. The statements FB_WRITEL(comp(d0, FB_READL(dst), first), dst) reads
the last long word of the destination and writes it back unchanged
(because first is zero). Correctly, we should write the variable d0 to the
last word of the destination in this case.
This patch fixes the bug by introducing and extra test if first is zero.
The patch also removes the references to fb_memmove in the code that is
commented out because fb_memmove was removed from framebuffer subsystem.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0bcfd49de44907eb54f38cf7938b2008af24e918
Author: Prarit Bhargava <prarit@redhat.com>
Date: Tue Oct 14 02:51:39 2014 +1030
modules, lock around setting of MODULE_STATE_UNFORMED
commit d3051b489aa81ca9ba62af366149ef42b8dae97c upstream.
A panic was seen in the following sitation.
There are two threads running on the system. The first thread is a system
monitoring thread that is reading /proc/modules. The second thread is
loading and unloading a module (in this example I'm using my simple
dummy-module.ko). Note, in the "real world" this occurred with the qlogic
driver module.
When doing this, the following panic occurred:
------------[ cut here ]------------
kernel BUG at kernel/module.c:3739!
invalid opcode: 0000 [#1] SMP
Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module]
CPU: 37 PID: 186343 Comm: cat Tainted: GF O-------------- 3.10.0+ #7
Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000
RIP: 0010:[<ffffffff810d64c5>] [<ffffffff810d64c5>] module_flags+0xb5/0xc0
RSP: 0018:ffff88080fa7fe18 EFLAGS: 00010246
RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000
RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000
RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000
R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000
FS: 00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c
ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00
ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0
Call Trace:
[<ffffffff810d666c>] m_show+0x19c/0x1e0
[<ffffffff811e4d7e>] seq_read+0x16e/0x3b0
[<ffffffff812281ed>] proc_reg_read+0x3d/0x80
[<ffffffff811c0f2c>] vfs_read+0x9c/0x170
[<ffffffff811c1a58>] SyS_read+0x58/0xb0
[<ffffffff81605829>] system_call_fastpath+0x16/0x1b
Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
RIP [<ffffffff810d64c5>] module_flags+0xb5/0xc0
RSP <ffff88080fa7fe18>
Consider the two processes running on the system.
CPU 0 (/proc/modules reader)
CPU 1 (loading/unloading module)
CPU 0 opens /proc/modules, and starts displaying data for each module by
traversing the modules list via fs/seq_file.c:seq_open() and
fs/seq_file.c:seq_read(). For each module in the modules list, seq_read
does
op->start() <-- this is a pointer to m_start()
op->show() <- this is a pointer to m_show()
op->stop() <-- this is a pointer to m_stop()
The m_start(), m_show(), and m_stop() module functions are defined in
kernel/module.c. The m_start() and m_stop() functions acquire and release
the module_mutex respectively.
ie) When reading /proc/modules, the module_mutex is acquired and released
for each module.
m_show() is called with the module_mutex held. It accesses the module
struct data and attempts to write out module data. It is in this code
path that the above BUG_ON() warning is encountered, specifically m_show()
calls
static char *module_flags(struct module *mod, char *buf)
{
int bx = 0;
BUG_ON(mod->state == MODULE_STATE_UNFORMED);
...
The other thread, CPU 1, in unloading the module calls the syscall
delete_module() defined in kernel/module.c. The module_mutex is acquired
for a short time, and then released. free_module() is called without the
module_mutex. free_module() then sets mod->state = MODULE_STATE_UNFORMED,
also without the module_mutex. Some additional code is called and then the
module_mutex is reacquired to remove the module from the modules list:
/* Now we can delete it from the lists */
mutex_lock(&module_mutex);
stop_machine(__unlink_module, mod, NULL);
mutex_unlock(&module_mutex);
This is the sequence of events that leads to the panic.
CPU 1 is removing dummy_module via delete_module(). It acquires the
module_mutex, and then releases it. CPU 1 has NOT set dummy_module->state to
MODULE_STATE_UNFORMED yet.
CPU 0, which is reading the /proc/modules, acquires the module_mutex and
acquires a pointer to the dummy_module which is still in the modules list.
CPU 0 calls m_show for dummy_module. The check in m_show() for
MODULE_STATE_UNFORMED passed for dummy_module even though it is being
torn down.
Meanwhile CPU 1, which has been continuing to remove dummy_module without
holding the module_mutex, now calls free_module() and sets
dummy_module->state to MODULE_STATE_UNFORMED.
CPU 0 now calls module_flags() with dummy_module and ...
static char *module_flags(struct module *mod, char *buf)
{
int bx = 0;
BUG_ON(mod->state == MODULE_STATE_UNFORMED);
and BOOM.
Acquire and release the module_mutex lock around the setting of
MODULE_STATE_UNFORMED in the teardown path, which should resolve the
problem.
Testing: In the unpatched kernel I can panic the system within 1 minute by
doing
while (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done
and
while (true) do cat /proc/modules; done
in separate terminals.
In the patched kernel I was able to run just over one hour without seeing
any issues. I also verified the output of panic via sysrq-c and the output
of /proc/modules looks correct for all three states for the dummy_module.
dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-)
dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE)
dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+)
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Reviewed-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8baef734af1a6aba03c4ccea0b57b47ea0f705fb
Author: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Wed Oct 1 22:58:35 2014 +0200
dm log userspace: fix memory leak in dm_ulog_tfr_init failure path
commit 56ec16cb1e1ce46354de8511eef962a417c32c92 upstream.
If cn_add_callback() fails in dm_ulog_tfr_init(), it does not
deallocate prealloced memory but calls cn_del_callback().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Reviewed-by: Jonathan Brassow <jbrassow@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ebe9d6a035d447a10d1a143bec498feb1f62a4b6
Author: Christoph Hellwig <hch@lst.de>
Date: Sun Oct 19 17:13:57 2014 +0200
Revert "block: all blk-mq requests are tagged"
commit e999dbc254044e8d2a5818d92d205f65bae28f37 upstream.
This reverts commit fb3ccb5da71273e7f0d50b50bc879e50cedd60e7.
SCSI-2/SPI actually needs the tagged/untagged flag in the request to
work properly. Revert this patch and add a follow on to set it in
the right place.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Jens Axboe <axboe@kernel.dk>
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ab050e8e15aae8d949757a91348f8b1ebd9dfec0
Author: Mike Snitzer <snitzer@redhat.com>
Date: Wed Oct 8 18:26:13 2014 -0400
block: fix alignment_offset math that assumes io_min is a power-of-2
commit b8839b8c55f3fdd60dc36abcda7e0266aff7985c upstream.
The math in both blk_stack_limits() and queue_limit_alignment_offset()
assume that a block device's io_min (aka minimum_io_size) is always a
power-of-2. Fix the math such that it works for non-power-of-2 io_min.
This issue (of alignment_offset != 0) became apparent when testing
dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data
block size") unlocked the potential for alignment_offset != 0 due to
the dm-thin-pool's io_min possibly being a non-power-of-2.
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3757dfbf653fdf9c9c9d391cbff089325ab374e2
Author: Lai Jiangshan <laijs@cn.fujitsu.com>
Date: Thu Sep 18 16:49:41 2014 +0200
drbd: compute the end before rb_insert_augmented()
commit 82cfb90bc99d7b7e0ec62d0505b9d4f06805d5db upstream.
Commit 98683650 "Merge branch 'drbd-8.4_ed6' into
for-3.8-drivers-drbd-8.4_ed6" switches to the new augment API, but the
new API requires that the tree is augmented before rb_insert_augmented()
is called, which is missing.
So we add the augment-code to drbd_insert_interval() when it travels the
tree up to down before rb_insert_augmented(). See the example in
include/linux/interval_tree_generic.h or Documentation/rbtree.txt.
drbd_insert_interval() may cancel the insertion when traveling, in this
case, the just added augment-code does nothing before cancel since the
@this node is already in the subtrees in this case.
CC: Michel Lespinasse <walken@google.com>
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Andreas Gruenbacher <agruen@linbit.com>
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7c2d00144ac0969141ed496155c5484bb7bfaa6e
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Wed Oct 1 13:29:48 2014 -0400
dm bufio: when done scanning return from __scan immediately
commit 0e825862f3c04cee40e25f55680333728a4ffa9b upstream.
When __scan frees the required number of buffer entries that the
shrinker requested (nr_to_scan becomes zero) it must return. Before
this fix the __scan code exited only the inner loop and continued in the
outer loop -- which could result in reduced performance due to extra
buffers being freed (e.g. unnecessarily evicted thinp metadata needing
to be synchronously re-read into bufio's cache).
Also, move dm_bufio_cond_resched to __scan's inner loop, so that
iterating the bufio client's lru lists doesn't result in scheduling
latency.
Reported-by: Joe Thornber <thornber@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6959ee9b475a131a134aed86542cd26b9ac8266f
Author: Joe Thornber <ejt@redhat.com>
Date: Tue Sep 30 09:32:46 2014 +0100
dm bufio: update last_accessed when relinking a buffer
commit eb76faf53b1ff7a77ce3f78cc98ad392ac70c2a0 upstream.
The 'last_accessed' member of the dm_buffer structure was only set when
the the buffer was created. This led to each buffer being discarded
after dm_bufio_max_age time even if it was used recently. In practice
this resulted in all thinp metadata being evicted soon after being read
-- this is particularly problematic for metadata intensive workloads
like multithreaded small random IO.
'last_accessed' is now updated each time the buffer is moved to the head
of the LRU list, so the buffer is now properly discarded if it was not
used in dm_bufio_max_age time.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7d515b57a1457c9dc4113bc471e686f2b7e79474
Author: Jens Axboe <axboe@fb.com>
Date: Tue Oct 7 08:39:20 2014 -0600
blk-mq: fix potential hang if rolling wakeup depth is too high
commit abab13b5c4fd1fec4f9a61622548012d93dc2831 upstream.
We currently divide the queue depth by 4 as our batch wakeup
count, but we split the wakeups over BT_WAIT_QUEUES number of
wait queues. This defaults to 8. If the product of the resulting
batch wake count and BT_WAIT_QUEUES is higher than the device
queue depth, we can get into a situation where a task goes to
sleep waiting for a request, but never gets woken up.
Reported-by: Bart Van Assche <bvanassche@acm.org>
Fixes: 4bb659b156996
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8c7130220e2f3c64f9ef67aa576064df496cae84
Author: Olaf Hering <olaf@aepfle.de>
Date: Fri Apr 11 08:56:23 2014 +0200
drm/cirrus: bind also to qemu-xen-traditional
commit c0c3e735fa7bae29c6623511127fd021b2d6d849 upstream.
qemu as used by xend/xm toolstack uses a different subvendor id.
Bind the drm driver also to this emulated card.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 90e2b7d5186ed1158e5c56cf483754d8edd2e5ee
Author: Roger Pau Monné <roger.pau@citrix.com>
Date: Mon Sep 15 11:55:27 2014 +0200
xen-blkback: fix leak on grant map error path
commit 61cecca865280bef4f8a9748d0a9afa5df351ac2 upstream.
Fix leaking a page when a grant mapping has failed.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reported-and-Tested-by: Tao Chen <boby.chen@huawei.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c22f531fe6fca50ca49cd815374db1b0cbe95b16
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Mon Sep 8 15:21:33 2014 +0200
xen/blkback: unmap all persistent grants when frontend gets disconnected
commit 12ea729645ace01e08f9654df155622898d3aae6 upstream.
blkback does not unmap persistent grants when frontend goes to Closed
state (e.g. when blkfront module is being removed). This leads to the
following in guest's dmesg:
[ 343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use!
[ 343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use!
...
When load module -> use device -> unload module sequence is performed multiple times
it is possible to hit BUG() condition in blkfront module:
[ 343.243825] kernel BUG at drivers/block/xen-blkfront.c:954!
[ 343.243825] invalid opcode: 0000 [#1] SMP
[ 343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last unloaded: xen_blkfront]
...
[ 343.243825] Call Trace:
[ 343.243825] [<ffffffff814111ef>] ? unregister_xenbus_watch+0x16f/0x1e0
[ 343.243825] [<ffffffffa0016fbf>] blkfront_remove+0x3f/0x140 [xen_blkfront]
...
[ 343.243825] RIP [<ffffffffa0016aae>] blkif_free+0x34e/0x360 [xen_blkfront]
[ 343.243825] RSP <ffff88001eb8fdc0>
We don't need to keep these grants if we're disconnecting as frontend might already
forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from
xen_blkif_free() to xen_blkif_disconnect().
Now we can see the following:
[ 928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use!
[ 928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use!
...
[ 929.592146] xen:grant_table: freeing g.e. 0x587
[ 929.597174] xen:grant_table: freeing g.e. 0x372
...
Backend does not keep persistent grants any more, reconnect works fine.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fda8e9a29ef3e671d465c2b72c571594e309b681
Author: Michael S. Tsirkin <mst@redhat.com>
Date: Tue Oct 14 10:40:29 2014 +1030
virtio_pci: fix virtio spec compliance on restore
commit 6fbc198cf623944ab60a1db6d306a4d55cdd820d upstream.
On restore, virtio pci does the following:
+ set features
+ init vqs etc - device can be used at this point!
+ set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits
This is in violation of the virtio spec, which
requires the following order:
- ACKNOWLEDGE
- DRIVER
- init vqs
- DRIVER_OK
This behaviour will break with hypervisors that assume spec compliant
behaviour. It seems like a good idea to have this patch applied to
stable branches to reduce the support butden for the hypervisors.
Cc: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c51296e739e17350d9f468e464c77667696b16d2
Author: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Date: Fri Sep 26 13:27:03 2014 +0200
power: charger-manager: Fix NULL pointer exception with missing cm-fuel-gauge
commit 661a88860274e059fdb744dfaa98c045db7b5d1d upstream.
NULL pointer exception happens during charger-manager probe if
'cm-fuel-gauge' property is not present.
[ 2.448536] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[ 2.456572] pgd = c0004000
[ 2.459217] [00000000] *pgd=00000000
[ 2.462759] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 2.468047] Modules linked in:
[ 2.471089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-00251-ge44cf96cd525-dirty #969
[ 2.479765] task: ea890000 ti: ea87a000 task.ti: ea87a000
[ 2.485161] PC is at strcmp+0x4/0x30
[ 2.488719] LR is at power_supply_match_device_by_name+0x10/0x1c
[ 2.494695] pc : [<c01f4220>] lr : [<c030fe38>] psr: a0000113
[ 2.494695] sp : ea87bde0 ip : 00000000 fp : eaa97010
[ 2.506150] r10: 00000004 r9 : ea97269c r8 : ea3bbfd0
[ 2.511360] r7 : eaa97000 r6 : c030fe28 r5 : 00000000 r4 : ea3b0000
[ 2.517869] r3 : 0000006d r2 : 00000000 r1 : 00000000 r0 : c057c195
[ 2.524381] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 2.531671] Control: 10c5387d Table: 4000404a DAC: 00000015
[ 2.537399] Process swapper/0 (pid: 1, stack limit = 0xea87a240)
[ 2.543388] Stack: (0xea87bde0 to 0xea87c000)
[ 2.547733] bde0: ea3b0210 c026b1c8 eaa97010 eaa97000 eaa97010 eabb60a8 ea3b0210 00000000
[ 2.555891] be00: 00000008 ea2db210 ea1a3410 c030fee0 ea3bbf90 c03138fc c068969c c013526c
[ 2.564050] be20: eaa040c0 00000000 c068969c 00000000 eaa040c0 ea2da300 00000002 00000000
[ 2.572208] be40: 00000001 ea2da3c0 00000000 00000001 00000000 eaa97010 c068969c 00000000
[ 2.580367] be60: 00000000 c068969c 00000000 00000002 00000000 c026b71c c026b6f0 eaa97010
[ 2.588527] be80: c0e82530 c026a330 00000000 eaa97010 c068969c eaa97044 00000000 c061df50
[ 2.596686] bea0: ea87a000 c026a4dc 00000000 c068969c c026a448 c0268b5c ea8054a8 eaa8fd50
[ 2.604845] bec0: c068969c ea2db180 c06801f8 c0269b18 c0590f68 c068969c c0656c98 c068969c
[ 2.613004] bee0: c0656c98 ea3bbe40 c06988c0 c026aaf0 00000000 c0656c98 c0656c98 c00088a4
[ 2.621163] bf00: 00000000 c0055f48 00000000 00000004 00000000 ea890000 c05dbc54 c062c178
[ 2.629323] bf20: c0603518 c005f674 00000001 ea87a000 eb7ff83b c0476440 00000091 c003d41c
[ 2.637482] bf40: c05db344 00000007 eb7ff858 00000007 c065a76c c0647d24 00000007 c062c170
[ 2.645642] bf60: c06988c0 00000091 c062c178 c0603518 00000000 c0603cc4 00000007 00000007
[ 2.653801] bf80: c0603518 c0c0c0c0 00000000 c0453948 00000000 00000000 00000000 00000000
[ 2.661959] bfa0: 00000000 c0453950 00000000 c000e728 00000000 00000000 00000000 00000000
[ 2.670118] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 2.678277] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 c0c0c0c0 c0c0c0c0
[ 2.686454] [<c01f4220>] (strcmp) from [<c030fe38>] (power_supply_match_device_by_name+0x10/0x1c)
[ 2.695303] [<c030fe38>] (power_supply_match_device_by_name) from [<c026b1c8>] (class_find_device+0x54/0xac)
[ 2.705106] [<c026b1c8>] (class_find_device) from [<c030fee0>] (power_supply_get_by_name+0x1c/0x30)
[ 2.714137] [<c030fee0>] (power_supply_get_by_name) from [<c03138fc>] (charger_manager_probe+0x3d8/0xe58)
[ 2.723683] [<c03138fc>] (charger_manager_probe) from [<c026b71c>] (platform_drv_probe+0x2c/0x5c)
[ 2.732532] [<c026b71c>] (platform_drv_probe) from [<c026a330>] (driver_probe_device+0x10c/0x224)
[ 2.741384] [<c026a330>] (driver_probe_device) from [<c026a4dc>] (__driver_attach+0x94/0x98)
[ 2.749813] [<c026a4dc>] (__driver_attach) from [<c0268b5c>] (bus_for_each_dev+0x54/0x88)
[ 2.757969] [<c0268b5c>] (bus_for_each_dev) from [<c0269b18>] (bus_add_driver+0xd4/0x1d0)
[ 2.766123] [<c0269b18>] (bus_add_driver) from [<c026aaf0>] (driver_register+0x78/0xf4)
[ 2.774110] [<c026aaf0>] (driver_register) from [<c00088a4>] (do_one_initcall+0x80/0x1bc)
[ 2.782276] [<c00088a4>] (do_one_initcall) from [<c0603cc4>] (kernel_init_freeable+0x100/0x1cc)
[ 2.790952] [<c0603cc4>] (kernel_init_freeable) from [<c0453950>] (kernel_init+0x8/0xec)
[ 2.799029] [<c0453950>] (kernel_init) from [<c000e728>] (ret_from_fork+0x14/0x2c)
[ 2.806572] Code: e12fff1e e1a03000 eafffff7 e4d03001 (e4d12001)
[ 2.812832] ---[ end trace 7f12556111b9e7ef ]---
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: 856ee6115e2d ("charger-manager: Support deivce tree in charger manager driver")
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a72959e690ade376bfd61fec60cb4f0ae0c4c6bd
Author: Stephen Smalley <sds@tycho.nsa.gov>
Date: Mon Oct 6 16:32:52 2014 -0400
selinux: fix inode security list corruption
commit 923190d32de4428afbea5e5773be86bea60a9925 upstream.
sb_finish_set_opts() can race with inode_free_security()
when initializing inode security structures for inodes
created prior to initial policy load or by the filesystem
during ->mount(). This appears to have always been
a possible race, but commit 3dc91d4 ("SELinux: Fix possible
NULL pointer dereference in selinux_inode_permission()")
made it more evident by immediately reusing the unioned
list/rcu element of the inode security structure for call_rcu()
upon an inode_free_security(). But the underlying issue
was already present before that commit as a possible use-after-free
of isec.
Shivnandan Kumar reported the list corruption and proposed
a patch to split the list and rcu elements out of the union
as separate fields of the inode_security_struct so that setting
the rcu element would not affect the list element. However,
this would merely hide the issue and not truly fix the code.
This patch instead moves up the deletion of the list entry
prior to dropping the sbsec->isec_lock initially. Then,
if the inode is dropped subsequently, there will be no further
references to the isec.
Reported-by: Shivnandan Kumar <shivnandan.k@samsung.com>
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Paul Moore <pmoore@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0c2c25d01cd6e8cfb54c39656484e0bbd5d9e61d
Author: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Date: Sun Oct 12 23:09:08 2014 -0400
pstore: Fix duplicate {console,ftrace}-efi entries
commit d4bf205da618bbd0b038e404d646f14e76915718 upstream.
The pstore filesystem still creates duplicate filename/inode pairs for
some pstore types. Add the id to the filename to prevent that.
Before patch:
[/sys/fs/pstore] ls -li
total 0
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
After:
[/sys/fs/pstore] ls -li
total 0
1232 -r--r--r--. 1 root root 148 Sep 29 17:09 console-efi-141202499100000
1231 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi-141202499200000
1230 -r--r--r--. 1 root root 148 Sep 29 17:44 console-efi-141202705400000
1229 -r--r--r--. 1 root root 67 Sep 29 17:44 console-efi-141202705500000
1228 -r--r--r--. 1 root root 67 Sep 29 20:42 console-efi-141203772600000
1227 -r--r--r--. 1 root root 148 Sep 29 23:42 console-efi-141204854900000
1226 -r--r--r--. 1 root root 67 Sep 29 23:42 console-efi-141204855000000
1225 -r--r--r--. 1 root root 148 Sep 29 23:59 console-efi-141204954200000
1224 -r--r--r--. 1 root root 67 Sep 29 23:59 console-efi-141204954400000
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 94d71e0fa95644fb5fe4c6eba73f552511d83f8e
Author: Alex Williamson <alex.williamson@redhat.com>
Date: Fri Sep 19 10:03:13 2014 -0600
iommu/amd: Split init_iommu_group() from iommu_init_device()
commit 25b11ce2a3607d7c39a2ca121eea0c67c722b34e upstream.
For a PCI device, aliases from the IVRS table won't be populated
into dma_alias_devfn until after iommu_init_device() is called on
each device. We therefore want to split init_iommu_group() to
be called from a separate loop immediately following.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b7c845dde8ae87f335f8c7ae4b7bc45f34ff3446
Author: Alex Williamson <alex.williamson@redhat.com>
Date: Fri Sep 19 10:03:06 2014 -0600
iommu: Rework iommu_group_get_for_pci_dev()
commit f096c061f5525d1b35a65b793057b52061dcb486 upstream.
It turns out that our assumption that aliases are always to the same
slot isn't true. One particular platform reports an IVRS alias of the
SATA controller (00:11.0) for the legacy IDE controller (00:14.1).
When we hit this, we attempt to use a single IOMMU group for
everything on the same bus, which in this case is the root complex.
We already have multiple groups defined for the root complex by this
point, resulting in multiple WARN_ON hits.
This patch makes these sorts of aliases work again with IOMMU groups
by reworking how we search through the PCI address space to find
existing groups. This should also now handle looped dependencies and
all sorts of crazy inter-dependencies that we'll likely never see.
The recursion used here should never be very deep. It's unlikely to
have individual aliases and only theoretical that we'd ever see a
chain where one alias causes us to search through to yet another
alias. We're also only dealing with PCIe device on a single bus,
which means we'll typically only see multiple slots in use on the root
complex. Loops are also a theoretically possibility, which I've
tested using fake DMA alias quirks and prevent from causing problems
using a bitmap of the devfn space that's been visited.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 373626aa4e02b657cfa2a854134c7e0384cae033
Author: Chris Ball <chris@printf.net>
Date: Thu Sep 4 17:11:53 2014 +0100
mfd: rtsx_pcr: Fix MSI enable error handling
commit 5152970538a5e16c03bbcb9f1c780489a795ed40 upstream.
pci_enable_msi() can return failure with both positive and negative
integers -- it returns 0 for success -- but is only tested here for
"if (ret < 0)". This causes us to try to use MSI on the RTS5249 SD
reader in the Dell XPS 11 when enabling MSI failed, causing:
[ 1.737110] rtsx_pci: probe of 0000:05:00.0 failed with error -110
Reported-by: D. Jared Dominguez <Jared_Dominguez@Dell.com>
Tested-by: D. Jared Dominguez <Jared_Dominguez@Dell.com>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c452ad8dcd3f03345f618d68db676a00e70b7e64
Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Date: Mon Sep 8 15:28:42 2014 +0200
mfd: ti_am335x_tscadc: Fix TSC resume
commit 6a71f38dd87f255a0586104ce2a14d5a3ddf3401 upstream.
In the resume path, the ADC invokes am335x_tsc_se_set_cache() with 0 as
the steps argument if continous mode is not in use. This in turn disables
all steps and so the TSC is not working until one ADC sampling is
performed.
This patch fixes it by writing the current cached mask instead of the
passed steps.
Fixes: 7ca6740cd1cd ("mfd: input: iio: ti_amm335x: Rework TSC/ADCA
synchronization")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4cc548f3796009f3d99db6a54de6e68b8a1266b
Author: Vignesh R <vigneshr@ti.com>
Date: Mon Sep 1 12:01:06 2014 +0530
mfd: ti_am335x_tscadc: Fix TSC operation after ADC continouous mode
commit 6ac734d2242949f41eb1346ca0fd4ed010c937aa upstream.
After enabling and disabling ADC continuous mode via sysfs, ts_print_raw
fails to return any data. This is because when ADC is configured for
continuous mode, it disables touch screen steps.These steps are not
re-enabled when ADC continuous mode is disabled. Therefore existing values
of REG_SE needs to be cached before enabling continuous mode and
disabling touch screen steps and enabling ADC steps. The cached value
are to be restored to REG_SE once ADC is disabled.
Fixes: 7ca6740cd1cd ("mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization")
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5281794fc3f9ced0343eb5fb6c5af31cfad5e994
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Wed Oct 8 10:42:27 2014 -0700
mnt: Prevent pivot_root from creating a loop in the mount tree
commit 0d0826019e529f21c84687521d03f60cd241ca7d upstream.
Andy Lutomirski recently demonstrated that when chroot is used to set
the root path below the path for the new ``root'' passed to pivot_root
the pivot_root system call succeeds and leaks mounts.
In examining the code I see that starting with a new root that is
below the current root in the mount tree will result in a loop in the
mount tree after the mounts are detached and then reattached to one
another. Resulting in all kinds of ugliness including a leak of that
mounts involved in the leak of the mount loop.
Prevent this problem by ensuring that the new mount is reachable from
the current root of the mount tree.
[Added stable cc. Fixes CVE-2014-7970. --Andy]
Reported-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.org
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 42d5787d0b80f35448c4cd860101f2dc125a49f9
Author: Richard Genoud <richard.genoud@gmail.com>
Date: Tue Sep 9 14:25:01 2014 +0200
UBI: add missing kmem_cache_free() in process_pool_aeb error path
commit 1bf1890e86869032099b539bc83b098be12fc5a7 upstream.
I ran into this error after a ubiupdatevol, because I forgot to backport
e9110361a9a4 UBI: fix the volumes tree sorting criteria.
UBI error: process_pool_aeb: orphaned volume in fastmap pool
UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan!
kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects
CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1
[<c000d298>] (unwind_backtrace) from [<c000baa8>] (show_stack+0x10/0x14)
[<c000baa8>] (show_stack) from [<c01b7a68>] (destroy_ai+0x230/0x244)
[<c01b7a68>] (destroy_ai) from [<c01b8fd4>] (ubi_attach+0x98/0x1ec)
[<c01b8fd4>] (ubi_attach) from [<c01ade90>] (ubi_attach_mtd_dev+0x2b8/0x868)
[<c01ade90>] (ubi_attach_mtd_dev) from [<c038b510>] (ubi_init+0x1dc/0x2ac)
[<c038b510>] (ubi_init) from [<c0008860>] (do_one_initcall+0x94/0x140)
[<c0008860>] (do_one_initcall) from [<c037aadc>] (kernel_init_freeable+0xe8/0x1b0)
[<c037aadc>] (kernel_init_freeable) from [<c02730ac>] (kernel_init+0x8/0xe4)
[<c02730ac>] (kernel_init) from [<c00093f0>] (ret_from_fork+0x14/0x24)
UBI: scanning is finished
Freeing the cache in the error path fixes the Slab error.
Tested on at91sam9g35 (3.14.18+fastmap backports)
Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6196ef9b63ce2ec5cc59f4d16ced7232e68f9bcb
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Fri Aug 29 18:42:30 2014 -0300
UBI: Dispatch update notification if the volume is updated
commit fda322a1b3b9e8ee231913c500f73c6988b1aff5 upstream.
The UBI_IOCVOLUP ioctl is used to start an update and also to
truncate a volume. In the first case, a "volume updated" notification
is dispatched when the update is done.
This commit adds the "volume updated" notification to be also sent when
the volume is truncated. This is required for UBI block and gluebi to get
notified about the new volume size.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea4871b6e428ea67e97c5e37b90b4f359f928d65
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Fri Aug 29 18:42:29 2014 -0300
UBI: block: Add support for the UBI_VOLUME_UPDATED notification
commit 06d9c2905f745c8b1920a335cbb366ba6b0fc754 upstream.
Static volumes can change its 'used_bytes' when they get updated,
and so the block interface must listen to the UBI_VOLUME_UPDATED
notification to resize the block device accordingly.
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f075a118d03de3898173a7c05ae9a3c3c961652e
Author: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Date: Fri Aug 29 18:42:28 2014 -0300
UBI: block: Fix block device size setting
commit 978d6496758d19de2431ebf163337fc7b92f8c45 upstream.
We are currently taking the block device size from the ubi_volume_info.size
field. However, this is not the amount of data in the volume, but the
number of reserved physical eraseblocks, and hence leads to an incorrect
representation of the volume.
In particular, this produces I/O errors on static volumes as the block
interface may attempt to read unmapped PEBs:
$ cat /dev/ubiblock0_0 > /dev/null
UBI error: ubiblock_read_to_buf: ubiblock0_0 ubi_read error -22
end_request: I/O error, dev ubiblock0_0, sector 9536
Buffer I/O error on device ubiblock0_0, logical block 2384
[snip]
Fix this by using the ubi_volume_info.used_bytes field which is set to the
actual number of data bytes for both static and dynamic volumes.
While here, improve the error message to be less stupid and more useful:
UBI error: ubiblock_read_to_buf: ubiblock0_1 ubi_read error -9 on LEB=0, off=15872, len=512
It's worth noticing that the 512-byte sector representation of the volume
is only correct if the volume size is multiple of 512-bytes. This is true for
virtually any NAND device, given eraseblocks and pages are 512-byte multiple
and hence so is the LEB size.
Artem: tweak the error message and make it look more like other UBI error
messages.
Fixes: 9d54c8a33eec ("UBI: R/O block driver on top of UBI volumes")
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0fff26c988da02f3ba6320cad75d52281e61f8e3
Author: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Wed Sep 24 16:37:20 2014 +0200
s390/topology: call set_sched_topology early
commit 48e9a6c1f54695609b709bf674aac133794ada00 upstream.
The call to topology_init is too late for the set_sched_topology call.
The initial scheduling domain structure has already been established
with default topology array. Use the smp_cpus_done() call to get the
s390 specific topology array registered early enough.
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 76285a141b827221a5b450f439dfe9483cc2aabc
Author: Daniel Borkmann <dborkman@redhat.com>
Date: Tue Aug 26 23:16:35 2014 -0400
random: add and use memzero_explicit() for clearing data
commit d4c5efdb97773f59a2b711754ca0953f24516739 upstream.
zatimend has reported that in his environment (3.16/gcc4.8.3/corei7)
memset() calls which clear out sensitive data in extract_{buf,entropy,
entropy_user}() in random driver are being optimized away by gcc.
Add a helper memzero_explicit() (similarly as explicit_bzero() variants)
that can be used in such cases where a variable with sensitive data is
being cleared out in the end. Other use cases might also be in crypto
code. [ I have put this into lib/string.c though, as it's always built-in
and doesn't need any dependencies then. ]
Fixes kernel bugzilla: 82041
Reported-by: zatimend@hotmail.co.uk
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: Alexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 848eb5fb084a1d03eb8d6f3688b0f20a6086372b
Author: Thorsten Knabe <linux@thorsten-knabe.de>
Date: Sat Aug 23 15:47:38 2014 +0200
um: ubd: Fix for processes stuck in D state forever
commit 2a2361228c5e6d8c1733f00653481de918598e50 upstream.
Starting with Linux 3.12 processes get stuck in D state forever in
UserModeLinux under sync heavy workloads. This bug was introduced by
commit 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport).
Fix bug by adding a check if FLUSH request was successfully submitted to
the I/O thread and keeping the FLUSH request on the request queue on
submission failures.
Fixes: 805f11a0d5 (um: ubd: Add REQ_FLUSH suppport)
Signed-off-by: Thorsten Knabe <linux@thorsten-knabe.de>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 74622033f1d67fa4b3054c2b0dfbb2527ec7a977
Author: Kirill Tkhai <ktkhai@parallels.com>
Date: Mon Sep 22 22:36:24 2014 +0400
sched: Use dl_bw_of() under RCU read lock
commit 66339c31bc3978d5fff9c4b4cb590a861def4db2 upstream.
dl_bw_of() dereferences rq->rd which has to have RCU read lock held.
Probability of use-after-free isn't zero here.
Also add lockdep assert into dl_bw_cpus().
Signed-off-by: Kirill Tkhai <ktkhai@parallels.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140922183624.11015.71558.stgit@localhost
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2743684fa1a9c4a0adfb54f8ef8316df1eb61459
Author: Ilya Dryomov <idryomov@redhat.com>
Date: Fri Oct 10 16:39:05 2014 +0400
libceph: ceph-msgr workqueue needs a resque worker
commit f9865f06f7f18c6661c88d0511f05c48612319cc upstream.
Commit f363e45fd118 ("net/ceph: make ceph_msgr_wq non-reentrant")
effectively removed WQ_MEM_RECLAIM flag from ceph_msgr_wq. This is
wrong - libceph is very much a memory reclaim path, so restore it.
Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
Tested-by: Micha Krause <micha@krausam.de>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ae49f71e8e0e98875003dff028f05082732cde71
Author: Ilya Dryomov <idryomov@redhat.com>
Date: Fri Oct 10 18:36:07 2014 +0400
rbd: rbd workqueues need a resque worker
commit 792c3a914910bd34302c5345578f85cfcb5e2c01 upstream.
Need to use WQ_MEM_RECLAIM for our workqueues to prevent I/O lockups
under memory pressure - we sit on the memory reclaim path.
Signed-off-by: Ilya Dryomov <idryomov@redhat.com>
Tested-by: Micha Krause <micha@krausam.de>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 611b6dd4683844a92eb8d9612bd971db3fc9071a
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Wed Oct 8 23:44:00 2014 -0400
fix misuses of f_count() in ppp and netlink
commit 24dff96a37a2ca319e75a74d3929b2de22447ca6 upstream.
we used to check for "nobody else could start doing anything with
that opened file" by checking that refcount was 2 or less - one
for descriptor table and one we'd acquired in fget() on the way to
wherever we are. That was race-prone (somebody else might have
had a reference to descriptor table and do fget() just as we'd
been checking) and it had become flat-out incorrect back when
we switched to fget_light() on those codepaths - unlike fget(),
it doesn't grab an extra reference unless the descriptor table
is shared. The same change allowed a race-free check, though -
we are safe exactly when refcount is less than 2.
It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading
to ppp one) and 2.6.17 for sendmsg() (netlink one). OTOH,
netlink hadn't grown that check until 3.9 and ppp used to live
in drivers/net, not drivers/net/ppp until 3.1. The bug existed
well before that, though, and the same fix used to apply in old
location of file.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0252c57fe138956165f433e60944c0dc6c270fcb
Author: Al Viro <viro@ZenIV.linux.org.uk>
Date: Fri Aug 1 20:13:40 2014 +0100
kill wbuf_queued/wbuf_dwork_lock
commit 99358a1ca53e8e6ce09423500191396f0e6584d2 upstream.
schedule_delayed_work() happening when the work is already pending is
a cheap no-op. Don't bother with ->wbuf_queued logics - it's both
broken (cancelling ->wbuf_dwork leaves it set, as spotted by Jeff Harris)
and pointless. It's cheaper to let schedule_delayed_work() handle that
case.
Reported-by: Jeff Harris <jefftharris@gmail.com>
Tested-by: Jeff Harris <jefftharris@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 131db0daeeeb7fa723bc1e4ad05b78ab927666a2
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Mon Sep 29 14:46:30 2014 -0400
missing data dependency barrier in prepend_name()
commit 6d13f69444bd3d4888e43f7756449748f5a98bad upstream.
AFAICS, prepend_name() is broken on SMP alpha. Disclaimer: I don't have
SMP alpha boxen to reproduce it on. However, it really looks like the race
is real.
CPU1: d_path() on /mnt/ramfs/<255-character>/foo
CPU2: mv /mnt/ramfs/<255-character> /mnt/ramfs/<63-character>
CPU2 does d_alloc(), which allocates an external name, stores the name there
including terminating NUL, does smp_wmb() and stores its address in
dentry->d_name.name. It proceeds to d_add(dentry, NULL) and d_move()
old dentry over to that. ->d_name.name value ends up in that dentry.
In the meanwhile, CPU1 gets to prepend_name() for that dentry. It fetches
->d_name.name and ->d_name.len; the former ends up pointing to new name
(64-byte kmalloc'ed array), the latter - 255 (length of the old name).
Nothing to force the ordering there, and normally that would be OK, since we'd
run into the terminating NUL and stop. Except that it's alpha, and we'd need
a data dependency barrier to guarantee that we see that store of NUL
__d_alloc() has done. In a similar situation dentry_cmp() would survive; it
does explicit smp_read_barrier_depends() after fetching ->d_name.name.
prepend_name() doesn't and it risks walking past the end of kmalloc'ed object
and possibly oops due to taking a page fault in kernel mode.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 23ab9b6bb4f1c3a4a5de58e521e5a26110d12f7c
Author: Takashi Iwai <tiwai@suse.de>
Date: Tue Oct 28 12:42:19 2014 +0100
ALSA: pcm: Zero-clear reserved fields of PCM status ioctl in compat mode
commit 317168d0c766defd14b3d0e9c2c4a9a258b803ee upstream.
In compat mode, we copy each field of snd_pcm_status struct but don't
touch the reserved fields, and this leaves uninitialized values
there. Meanwhile the native ioctl does zero-clear the whole
structure, so we should follow the same rule in compat mode, too.
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 99ec7002716eb5b34aa28ea1a7368d1b606e5916
Author: Christian Vogel <vogelchr@vogel.cx>
Date: Sat Oct 25 13:40:41 2014 +0200
ALSA: bebob: Uninitialized id returned by saffirepro_both_clk_src_get
commit d1d0b6b668818571122d30d68a0b3f768bd83a52 upstream.
snd_bebob_stream_check_internal_clock() may get an id from
saffirepro_both_clk_src_get (via clk_src->get()) that was uninitialized.
a) make logic in saffirepro_both_clk_src_get explicit
b) test if id used in snd_bebob_stream_check_internal_clock matches array size
[fixed missing signed prefix to *_maps[] by tiwai]
Signed-off-by: Christian Vogel <vogelchr@vogel.cx>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98866681fea200645c819c30940117cc47799043
Author: Takashi Iwai <tiwai@suse.de>
Date: Wed Oct 29 16:13:05 2014 +0100
ALSA: hda - Add workaround for CMI8888 snoop behavior
commit 3b70bdba2fcb374a2235a56ab73334348d819579 upstream.
CMI8888 shows the stuttering playback when the snooping is disabled
on the audio buffer. Meanwhile, we've got reports that CORB/RIRB
doesn't work in the snooped mode. So, as a compromise, disable the
snoop only for CORB/RIRB and enable the snoop for the stream buffers.
The resultant patch became a bit ugly, unfortunately, but we still can
live with it.
Reported-and-tested-by: Geoffrey McRae <geoff@spacevs.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d2c39f0bde32af7de0137ac89efa1a8a33f1f0a8
Author: Dmitry Kasatkin <d.kasatkin@samsung.com>
Date: Tue Oct 28 14:28:49 2014 +0200
evm: check xattr value length and type in evm_inode_setxattr()
commit 3b1deef6b1289a99505858a3b212c5b50adf0c2f upstream.
evm_inode_setxattr() can be called with no value. The function does not
check the length so that following command can be used to produce the
kernel oops: setfattr -n security.evm FOO. This patch fixes it.
Changes in v3:
* there is no reason to return different error codes for EVM_XATTR_HMAC
and non EVM_XATTR_HMAC. Remove unnecessary test then.
Changes in v2:
* testing for validity of xattr type
[ 1106.396921] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 1106.398192] IP: [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48
[ 1106.399244] PGD 29048067 PUD 290d7067 PMD 0
[ 1106.399953] Oops: 0000 [#1] SMP
[ 1106.400020] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse
[ 1106.400020] CPU: 0 PID: 3635 Comm: setxattr Not tainted 3.16.0-kds+ #2936
[ 1106.400020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1106.400020] task: ffff8800291a0000 ti: ffff88002917c000 task.ti: ffff88002917c000
[ 1106.400020] RIP: 0010:[<ffffffff812af7b8>] [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48
[ 1106.400020] RSP: 0018:ffff88002917fd50 EFLAGS: 00010246
[ 1106.400020] RAX: 0000000000000000 RBX: ffff88002917fdf8 RCX: 0000000000000000
[ 1106.400020] RDX: 0000000000000000 RSI: ffffffff818136d3 RDI: ffff88002917fdf8
[ 1106.400020] RBP: ffff88002917fd68 R08: 0000000000000000 R09: 00000000003ec1df
[ 1106.400020] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800438a0a00
[ 1106.400020] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1106.400020] FS: 00007f7dfa7d7740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000
[ 1106.400020] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1106.400020] CR2: 0000000000000000 CR3: 000000003763e000 CR4: 00000000000006f0
[ 1106.400020] Stack:
[ 1106.400020] ffff8800438a0a00 ffff88002917fdf8 0000000000000000 ffff88002917fd98
[ 1106.400020] ffffffff812a1030 ffff8800438a0a00 ffff88002917fdf8 0000000000000000
[ 1106.400020] 0000000000000000 ffff88002917fde0 ffffffff8116d08a ffff88002917fdc8
[ 1106.400020] Call Trace:
[ 1106.400020] [<ffffffff812a1030>] security_inode_setxattr+0x5d/0x6a
[ 1106.400020] [<ffffffff8116d08a>] vfs_setxattr+0x6b/0x9f
[ 1106.400020] [<ffffffff8116d1e0>] setxattr+0x122/0x16c
[ 1106.400020] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45
[ 1106.400020] [<ffffffff8114d011>] ? __sb_start_write+0x10f/0x143
[ 1106.400020] [<ffffffff811687e8>] ? mnt_want_write+0x21/0x45
[ 1106.400020] [<ffffffff811687c0>] ? __mnt_want_write+0x48/0x4f
[ 1106.400020] [<ffffffff8116d3e6>] SyS_setxattr+0x6e/0xb0
[ 1106.400020] [<ffffffff81529da9>] system_call_fastpath+0x16/0x1b
[ 1106.400020] Code: c3 0f 1f 44 00 00 55 48 89 e5 41 55 49 89 d5 41 54 49 89 fc 53 48 89 f3 48 c7 c6 d3 36 81 81 48 89 df e8 18 22 04 00 85 c0 75 07 <41> 80 7d 00 02 74 0d 48 89 de 4c 89 e7 e8 5a fe ff ff eb 03 83
[ 1106.400020] RIP [<ffffffff812af7b8>] evm_inode_setxattr+0x2a/0x48
[ 1106.400020] RSP <ffff88002917fd50>
[ 1106.400020] CR2: 0000000000000000
[ 1106.428061] ---[ end trace ae08331628ba3050 ]---
Reported-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8b88e5fde6fcd8c929a0dd9aa5074ca95c5de7fe
Author: Dmitry Kasatkin <d.kasatkin@samsung.com>
Date: Tue Sep 2 16:31:43 2014 +0300
evm: properly handle INTEGRITY_NOXATTRS EVM status
commit 3dcbad52cf18c3c379e96b992d22815439ebbe53 upstream.
Unless an LSM labels a file during d_instantiate(), newly created
files are not labeled with an initial security.evm xattr, until
the file closes. EVM, before allowing a protected, security xattr
to be written, verifies the existing 'security.evm' value is good.
For newly created files without a security.evm label, this
verification prevents writing any protected, security xattrs,
until the file closes.
Following is the example when this happens:
fd = open("foo", O_CREAT | O_WRONLY, 0644);
setxattr("foo", "security.SMACK64", value, sizeof(value), 0);
close(fd);
While INTEGRITY_NOXATTRS status is handled in other places, such
as evm_inode_setattr(), it does not handle it in all cases in
evm_protect_xattr(). By limiting the use of INTEGRITY_NOXATTRS to
newly created files, we can now allow setting "protected" xattrs.
Changelog:
- limit the use of INTEGRITY_NOXATTRS to IMA identified new files
Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com>
Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9aa2de7aae60a9e3bf2a71d0d24f325d215db81a
Author: Peter Zijlstra <peterz@infradead.org>
Date: Tue Sep 30 19:23:08 2014 +0200
perf: Fix unclone_ctx() vs. locking
commit 211de6eba8960521e2be450a7d07db85fba4604c upstream.
The idiot who did 4a1c0f262f88 ("perf: Fix lockdep warning on process exit")
forgot to pay attention and fix all similar cases. Do so now.
In particular, unclone_ctx() must be called while holding ctx->lock,
therefore all such sites are broken for the same reason. Pull the
put_ctx() call out from under ctx->lock.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Probably-also-reported-by: Vince Weaver <vincent.weaver@maine.edu>
Fixes: 4a1c0f262f88 ("perf: Fix lockdep warning on process exit")
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Cong Wang <cwang@twopensource.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140930172308.GI4241@worktop.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e01826f89a09fa4caa31b44f9f09ccf4562df939
Author: Dexuan Cui <decui@microsoft.com>
Date: Wed Oct 29 03:53:37 2014 -0700
x86, pageattr: Prevent overflow in slow_virt_to_phys() for X86_PAE
commit d1cd1210834649ce1ca6bafe5ac25d2f40331343 upstream.
pte_pfn() returns a PFN of long (32 bits in 32-PAE), so "long <<
PAGE_SHIFT" will overflow for PFNs above 4GB.
Due to this issue, some Linux 32-PAE distros, running as guests on Hyper-V,
with 5GB memory assigned, can't load the netvsc driver successfully and
hence the synthetic network device can't work (we can use the kernel parameter
mem=3000M to work around the issue).
Cast pte_pfn() to phys_addr_t before shifting.
Fixes: "commit d76565344512: x86, mm: Create slow_virt_to_phys()"
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: gregkh@linuxfoundation.org
Cc: linux-mm@kvack.org
Cc: olaf@aepfle.de
Cc: apw@canonical.com
Cc: jasowang@redhat.com
Cc: dave.hansen@intel.com
Cc: riel@redhat.com
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/1414580017-27444-1-git-send-email-decui@microsoft.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f9a1f05d969cf29858663ec129d7a16e66f572f3
Author: Andy Lutomirski <luto@amacapital.net>
Date: Fri Oct 31 18:08:45 2014 -0700
x86_64, entry: Fix out of bounds read on sysenter
commit 653bc77af60911ead1f423e588f54fc2547c4957 upstream.
Rusty noticed a Really Bad Bug (tm) in my NT fix. The entry code
reads out of bounds, causing the NT fix to be unreliable. But, and
this is much, much worse, if your stack is somehow just below the
top of the direct map (or a hole), you read out of bounds and crash.
Excerpt from the crash:
[ 1.129513] RSP: 0018:ffff88001da4bf88 EFLAGS: 00010296
2b:* f7 84 24 90 00 00 00 testl $0x4000,0x90(%rsp)
That read is deterministically above the top of the stack. I
thought I even single-stepped through this code when I wrote it to
check the offset, but I clearly screwed it up.
Fixes: 8c7aa698baca ("x86_64, entry: Filter RFLAGS.NT on entry from userspace")
Reported-by: Rusty Russell <rusty@ozlabs.org>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b1f7cac19752f9a92ef9bc47e334cbfe2071da2e
Author: Andy Lutomirski <luto@amacapital.net>
Date: Wed Oct 1 11:49:04 2014 -0700
x86_64, entry: Filter RFLAGS.NT on entry from userspace
commit 8c7aa698baca5e8f1ba9edb68081f1e7a1abf455 upstream.
The NT flag doesn't do anything in long mode other than causing IRET
to #GP. Oddly, CPL3 code can still set NT using popf.
Entry via hardware or software interrupt clears NT automatically, so
the only relevant entries are fast syscalls.
If user code causes kernel code to run with NT set, then there's at
least some (small) chance that it could cause trouble. For example,
user code could cause a call to EFI code with NT set, and who knows
what would happen? Apparently some games on Wine sometimes do
this (!), and, if an IRET return happens, they will segfault. That
segfault cannot be handled, because signal delivery fails, too.
This patch programs the CPU to clear NT on entry via SYSCALL (both
32-bit and 64-bit, by my reading of the AMD APM), and it clears NT
in software on entry via SYSENTER.
To save a few cycles, this borrows a trick from Jan Beulich in Xen:
it checks whether NT is set before trying to clear it. As a result,
it seems to have very little effect on SYSENTER performance on my
machine.
There's another minor bug fix in here: it looks like the CFI
annotations were wrong if CONFIG_AUDITSYSCALL=n.
Testers beware: on Xen, SYSENTER with NT set turns into a GPF.
I haven't touched anything on 32-bit kernels.
The syscall mask change comes from a variant of this patch by Anish
Bhatt.
Note to stable maintainers: there is no known security issue here.
A misguided program can set NT and cause the kernel to try and fail
to deliver SIGSEGV, crashing the program. This patch fixes Far Cry
on Wine: https://bugs.winehq.org/show_bug.cgi?id=33275
Reported-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/r/395749a5d39a29bd3e4b35899cf3a3c1340e5595.1412189265.git.luto@amacapital.net
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 049c33029b4cdf455810e184201cc20e6a5ec277
Author: Oleg Nesterov <oleg@redhat.com>
Date: Tue Sep 2 19:57:13 2014 +0200
x86, fpu: shift drop_init_fpu() from save_xstate_sig() to handle_signal()
commit 66463db4fc5605d51c7bb81d009d5bf30a783a2c upstream.
save_xstate_sig()->drop_init_fpu() doesn't look right. setup_rt_frame()
can fail after that, in this case the next setup_rt_frame() triggered
by SIGSEGV won't save fpu simply because the old state was lost. This
obviously mean that fpu won't be restored after sys_rt_sigreturn() from
SIGSEGV handler.
Shift drop_init_fpu() into !failed branch in handle_signal().
Test-case (needs -O2):
#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <sys/syscall.h>
#include <sys/mman.h>
#include <pthread.h>
#include <assert.h>
volatile double D;
void test(double d)
{
int pid = getpid();
for (D = d; D == d; ) {
/* sys_tkill(pid, SIGHUP); asm to avoid save/reload
* fp regs around "C" call */
asm ("" : : "a"(200), "D"(pid), "S"(1));
asm ("syscall" : : : "ax");
}
printf("ERR!!\n");
}
void sigh(int sig)
{
}
char altstack[4096 * 10] __attribute__((aligned(4096)));
void *tfunc(void *arg)
{
for (;;) {
mprotect(altstack, sizeof(altstack), PROT_READ);
mprotect(altstack, sizeof(altstack), PROT_READ|PROT_WRITE);
}
}
int main(void)
{
stack_t st = {
.ss_sp = altstack,
.ss_size = sizeof(altstack),
.ss_flags = SS_ONSTACK,
};
struct sigaction sa = {
.sa_handler = sigh,
};
pthread_t pt;
sigaction(SIGSEGV, &sa, NULL);
sigaltstack(&st, NULL);
sa.sa_flags = SA_ONSTACK;
sigaction(SIGHUP, &sa, NULL);
pthread_create(&pt, NULL, tfunc, NULL);
test(123.456);
return 0;
}
Reported-by: Bean Anderson <bean@azulsystems.com>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20140902175713.GA21646@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 89cad7627297376663fa01a570157b6827735519
Author: Oleg Nesterov <oleg@redhat.com>
Date: Tue Sep 2 19:57:17 2014 +0200
x86, fpu: __restore_xstate_sig()->math_state_restore() needs preempt_disable()
commit df24fb859a4e200d9324e2974229fbb7adf00aef upstream.
Add preempt_disable() + preempt_enable() around math_state_restore() in
__restore_xstate_sig(). Otherwise __switch_to() after __thread_fpu_begin()
can overwrite fpu->state we are going to restore.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Link: http://lkml.kernel.org/r/20140902175717.GA21649@redhat.com
Reviewed-by: Suresh Siddha <sbsiddha@gmail.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b5d6a69268e56db4d70fd15d7cfbfb00de09f8a1
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Sun Sep 7 21:05:05 2014 +0100
x86: Reject x32 executables if x32 ABI not supported
commit 0e6d3112a4e95d55cf6dca88f298d5f4b8f29bd1 upstream.
It is currently possible to execve() an x32 executable on an x86_64
kernel that has only ia32 compat enabled. However all its syscalls
will fail, even _exit(). This usually causes it to segfault.
Change the ELF compat architecture check so that x32 executables are
rejected if we don't support the x32 ABI.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Link: http://lkml.kernel.org/r/1410120305.6822.9.camel@decadent.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e40606e61ae6d5ec9c909635397009baefc8be4e
Author: Jan Kara <jack@suse.cz>
Date: Wed Oct 1 21:49:18 2014 -0400
vfs: fix data corruption when blocksize < pagesize for mmaped data
commit 90a8020278c1598fafd071736a0846b38510309c upstream.
->page_mkwrite() is used by filesystems to allocate blocks under a page
which is becoming writeably mmapped in some process' address space. This
allows a filesystem to return a page fault if there is not enough space
available, user exceeds quota or similar problem happens, rather than
silently discarding data later when writepage is called.
However VFS fails to call ->page_mkwrite() in all the cases where
filesystems need it when blocksize < pagesize. For example when
blocksize = 1024, pagesize = 4096 the following is problematic:
ftruncate(fd, 0);
pwrite(fd, buf, 1024, 0);
map = mmap(NULL, 1024, PROT_WRITE, MAP_SHARED, fd, 0);
map[0] = 'a'; ----> page_mkwrite() for index 0 is called
ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */
mremap(map, 1024, 10000, 0);
map[4095] = 'a'; ----> no page_mkwrite() called
At the moment ->page_mkwrite() is called, filesystem can allocate only
one block for the page because i_size == 1024. Otherwise it would create
blocks beyond i_size which is generally undesirable. But later at
->writepage() time, we also need to store data at offset 4095 but we
don't have block allocated for it.
This patch introduces a helper function filesystems can use to have
->page_mkwrite() called at all the necessary moments.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 602f5e766a649bd8cdae3dc169b848352a34b4d8
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Wed Jul 16 15:22:29 2014 +0300
UBIFS: fix free log space calculation
commit ba29e721eb2df6df8f33c1f248388bb037a47914 upstream.
Hu (hujianyang <hujianyang@huawei.com>) discovered an issue in the
'empty_log_bytes()' function, which calculates how many bytes are left in the
log:
"
If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h'
would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes'
instead of 0.
"
At this point it is not clear what would be the consequences of this, and
whether this may lead to any problems, but this patch addresses the issue just
in case.
Tested-by: hujianyang <hujianyang@huawei.com>
Reported-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 558dcb66298d9fe3ab65d67e04e2ce142fc639f1
Author: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Date: Sun Jun 29 17:00:45 2014 +0300
UBIFS: fix a race condition
commit 052c28073ff26f771d44ef33952a41d18dadd255 upstream.
Hu (hujianyang@huawei.com) discovered a race condition which may lead to a
situation when UBIFS is unable to mount the file-system after an unclean
reboot. The problem is theoretical, though.
In UBIFS, we have the log, which basically a set of LEBs in a certain area. The
log has the tail and the head.
Every time user writes data to the file-system, the UBIFS journal grows, and
the log grows as well, because we append new reference nodes to the head of the
log. So the head moves forward all the time, while the log tail stays at the
same position.
At any time, the UBIFS master node points to the tail of the log. When we mount
the file-system, we scan the log, and we always start from its tail, because
this is where the master node points to. The only occasion when the tail of the
log changes is the commit operation.
The commit operation has 2 phases - "commit start" and "commit end". The former
is relatively short, and does not involve much I/O. During this phase we mostly
just build various in-memory lists of the things which have to be written to
the flash media during "commit end" phase.
During the commit start phase, what we do is we "clean" the log. Indeed, the
commit operation will index all the data in the journal, so the entire journal
"disappears", and therefore the data in the log become unneeded. So we just
move the head of the log to the next LEB, and write the CS node there. This LEB
will be the tail of the new log when the commit operation finishes.
When the "commit start" phase finishes, users may write more data to the
file-system, in parallel with the ongoing "commit end" operation. At this point
the log tail was not changed yet, it is the same as it had been before we
started the commit. The log head keeps moving forward, though.
The commit operation now needs to write the new master node, and the new master
node should point to the new log tail. After this the LEBs between the old log
tail and the new log tail can be unmapped and re-used again.
And here is the possible problem. We do 2 operations: (a) We first update the
log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we
write the master node (see the big lock of code in 'do_commit()').
But nothing prevents the log head from moving forward between (a) and (b), and
the log head may "wrap" now to the old log tail. And when the "wrap" happens,
the contends of the log tail gets erased. Now a power cut happens and we are in
trouble. We end up with the old master node pointing to the old tail, which was
erased. And replay fails because it expects the master node to point to the
correct log tail at all times.
This patch merges the abovementioned (a) and (b) operations by moving the master
node change code to the 'ubifs_log_end_commit()' function, so that it runs with
the log mutex locked, which will prevent the log from being changed benween
operations (a) and (b).
Reported-by: hujianyang <hujianyang@huawei.com>
Tested-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d35f2f8cf099c4036ba5854b44fe72c53b12c582
Author: Eric Rannaud <e@nanocritical.com>
Date: Thu Oct 30 01:51:01 2014 -0700
fs: allow open(dir, O_TMPFILE|..., 0) with mode 0
commit 69a91c237ab0ebe4e9fdeaf6d0090c85275594ec upstream.
The man page for open(2) indicates that when O_CREAT is specified, the
'mode' argument applies only to future accesses to the file:
Note that this mode applies only to future accesses of the newly
created file; the open() call that creates a read-only file
may well return a read/write file descriptor.
The man page for open(2) implies that 'mode' is treated identically by
O_CREAT and O_TMPFILE.
O_TMPFILE, however, behaves differently:
int fd = open("/tmp", O_TMPFILE | O_RDWR, 0);
assert(fd == -1);
assert(errno == EACCES);
int fd = open("/tmp", O_TMPFILE | O_RDWR, 0600);
assert(fd > 0);
For O_CREAT, do_last() sets acc_mode to MAY_OPEN only:
if (*opened & FILE_CREATED) {
/* Don't check for write permission, don't truncate */
open_flag &= ~O_TRUNC;
will_truncate = false;
acc_mode = MAY_OPEN;
path_to_nameidata(path, nd);
goto finish_open_created;
}
But for O_TMPFILE, do_tmpfile() passes the full op->acc_mode to
may_open().
This patch lines up the behavior of O_TMPFILE with O_CREAT. After the
inode is created, may_open() is called with acc_mode = MAY_OPEN, in
do_tmpfile().
A different, but related glibc bug revealed the discrepancy:
https://sourceware.org/bugzilla/show_bug.cgi?id=17523
The glibc lazily loads the 'mode' argument of open() and openat() using
va_arg() only if O_CREAT is present in 'flags' (to support both the 2
argument and the 3 argument forms of open; same idea for openat()).
However, the glibc ignores the 'mode' argument if O_TMPFILE is in
'flags'.
On x86_64, for open(), it magically works anyway, as 'mode' is in
RDX when entering open(), and is still in RDX on SYSCALL, which is where
the kernel looks for the 3rd argument of a syscall.
But openat() is not quite so lucky: 'mode' is in RCX when entering the
glibc wrapper for openat(), while the kernel looks for the 4th argument
of a syscall in R10. Indeed, the syscall calling convention differs from
the regular calling convention in this respect on x86_64. So the kernel
sees mode = 0 when trying to use glibc openat() with O_TMPFILE, and
fails with EACCES.
Signed-off-by: Eric Rannaud <e@nanocritical.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 843ed955588e52746b73ba92ef53ec475ba644e5
Author: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Sat May 17 20:56:38 2014 +0900
fs: Fix theoretical division by 0 in super_cache_scan().
commit 475d0db742e3755c6b267f48577ff7cbb7dfda0d upstream.
total_objects could be 0 and is used as a denom.
While total_objects is a "long", total_objects == 0 unlikely happens for
3.12 and later kernels because 32-bit architectures would not be able to
hold (1 << 32) objects. However, total_objects == 0 may happen for kernels
between 3.1 and 3.11 because total_objects in prune_super() was an "int"
and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c319664d98c256a350c7df537a37a6b865314c24
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Sun Jul 27 13:00:41 2014 -0400
fs: make cont_expand_zero interruptible
commit c2ca0fcd202863b14bd041a7fece2e789926c225 upstream.
This patch makes it possible to kill a process looping in
cont_expand_zero. A process may spend a lot of time in this function, so
it is desirable to be able to kill it.
It happened to me that I wanted to copy a piece data from the disk to a
file. By mistake, I used the "seek" parameter to dd instead of "skip". Due
to the "seek" parameter, dd attempted to extend the file and became stuck
doing so - the only possibility was to reset the machine or wait many
hours until the filesystem runs out of space and cont_expand_zero fails.
We need this patch to be able to terminate the process.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d8494c06b6102a79d4c5cb991e5b32dc83079ab0
Author: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Date: Thu Aug 7 18:07:07 2014 +0200
mmc: sdhci-s3c: fix runtime PM handling on sdhci_add_host() failure
commit 221414db1934c1c883501998f510bb75acfbaa51 upstream.
Runtime Power Management handling for the sdhci_add_host() failure
case in sdhci_s3c_probe() should match the code in sdhci_s3c_remove()
(which uses pm_runtime_disable() call which matches the earlier
pm_runtime_enable() one). Fix it.
This patch fixes "BUG: spinlock bad magic on CPU#0, swapper/0/1" and
"Unbalanced pm_runtime_enable!" warnings.
>From the kernel log:
...
[ 1.659631] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
[ 1.665096] BUG: spinlock bad magic on CPU#0, swapper/0/1
[ 1.670433] lock: 0xea01e484, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
[ 1.677895] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.16.0-next-20140804-00008-ga59480f-dirty #707
[ 1.687037] [<c0013ae4>] (unwind_backtrace) from [<c0010d70>] (show_stack+0x10/0x14)
[ 1.694740] [<c0010d70>] (show_stack) from [<c04050c8>] (dump_stack+0x68/0xb8)
[ 1.701948] [<c04050c8>] (dump_stack) from [<c0052558>] (do_raw_spin_lock+0x15c/0x1a4)
[ 1.709848] [<c0052558>] (do_raw_spin_lock) from [<c040a630>] (_raw_spin_lock_irqsave+0x20/0x28)
[ 1.718619] [<c040a630>] (_raw_spin_lock_irqsave) from [<c030d7d0>] (sdhci_do_set_ios+0x1c/0x5cc)
[ 1.727464] [<c030d7d0>] (sdhci_do_set_ios) from [<c030ddfc>] (sdhci_runtime_resume_host+0x50/0x104)
[ 1.736574] [<c030ddfc>] (sdhci_runtime_resume_host) from [<c02462dc>] (pm_generic_runtime_resume+0x2c/0x40)
[ 1.746383] [<c02462dc>] (pm_generic_runtime_resume) from [<c0247898>] (__rpm_callback+0x34/0x70)
[ 1.755233] [<c0247898>] (__rpm_callback) from [<c02478fc>] (rpm_callback+0x28/0x88)
[ 1.762958] [<c02478fc>] (rpm_callback) from [<c02486f0>] (rpm_resume+0x384/0x4ec)
[ 1.770511] [<c02486f0>] (rpm_resume) from [<c02488b0>] (pm_runtime_forbid+0x58/0x64)
[ 1.778325] [<c02488b0>] (pm_runtime_forbid) from [<c030ea70>] (sdhci_s3c_probe+0x4a4/0x540)
[ 1.786749] [<c030ea70>] (sdhci_s3c_probe) from [<c02429cc>] (platform_drv_probe+0x2c/0x5c)
[ 1.795076] [<c02429cc>] (platform_drv_probe) from [<c02415f0>] (driver_probe_device+0x114/0x234)
[ 1.803929] [<c02415f0>] (driver_probe_device) from [<c024179c>] (__driver_attach+0x8c/0x90)
[ 1.812347] [<c024179c>] (__driver_attach) from [<c023ffb4>] (bus_for_each_dev+0x54/0x88)
[ 1.820506] [<c023ffb4>] (bus_for_each_dev) from [<c0240df8>] (bus_add_driver+0xd8/0x1cc)
[ 1.828665] [<c0240df8>] (bus_add_driver) from [<c0241db8>] (driver_register+0x78/0xf4)
[ 1.836652] [<c0241db8>] (driver_register) from [<c00088a4>] (do_one_initcall+0x80/0x1d0)
[ 1.844816] [<c00088a4>] (do_one_initcall) from [<c059ac94>] (kernel_init_freeable+0x108/0x1d4)
[ 1.853503] [<c059ac94>] (kernel_init_freeable) from [<c0401300>] (kernel_init+0x8/0xe4)
[ 1.861568] [<c0401300>] (kernel_init) from [<c000e538>] (ret_from_fork+0x14/0x3c)
[ 1.869582] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral
...
[ 1.997047] s3c-sdhci 12530000.sdhci: Unbalanced pm_runtime_enable!
...
[ 2.027235] s3c-sdhci 12530000.sdhci: sdhci_add_host() failed
[ 2.032884] platform 12530000.sdhci: Driver s3c-sdhci requests probe deferral
...
Tested on Hardkernel's Exynos4412 based ODROID-U3 board.
Fixes: 9f4e8151dbbc ("mmc: sdhci-s3c: Enable runtime power management")
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d9904f1e9451607fb915057bb40253ee6e6a7c30
Author: Roger Tseng <rogerable@realtek.com>
Date: Fri Aug 15 14:06:00 2014 +0800
mmc: rtsx_pci_sdmmc: fix incorrect last byte in R2 response
commit d1419d50c1bf711e9fd27b516a739c86b23f7cf9 upstream.
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Fixes: ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
Signed-off-by: Roger Tseng <rogerable@realtek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5651243b41871c4dc2e2d47df1f990c9fcae767f
Author: Stephen Warren <swarren@nvidia.com>
Date: Mon Sep 22 09:57:42 2014 -0600
mmc: don't request CD IRQ until mmc_start_host()
commit d4d11449088ee9aca16fd1884b852b8b73a4bda1 upstream.
As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.
Many host controller probe()s are roughly structured as:
*_probe() {
host = sdhci_pltfm_init();
mmc_of_parse(host->mmc);
rc = sdhci_add_host(host);
if (rc) {
sdhci_pltfm_free();
return rc;
}
In 3.17, CD IRQs can are enabled quite early via *_probe() ->
mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().
Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
call mmc_gpiod_request_cd_irq(). However, this issue still exists if
mmc_gpio_request_cd() is called directly before mmc_start_host().
sdhci_add_host() may fail part way through (e.g. due to deferred
probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
coded to assume that if sdhci_add_host() failed, then the delayed_work
cannot (or should not) have been triggered.
This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
kfree(host) is eventually called inside sdhci_pltfm_free():
WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb4()
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x18
The object being complained about is host->detect.
There's no need to request the CD IRQ so early; mmc_start_host() already
requests it. For most SDHCI hosts at least, the typical call path that
does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
mmc_start_host(). Therefore, remove the call to mmc_gpiod_request_cd_irq()
from mmc_gpio_request_cd(). This also matches mmc_gpio*d*_request_cd(),
which already doesn't call mmc_gpiod_request_cd_irq().
However, some host controller drivers call mmc_gpio_request_cd() after
mmc_start_host() has already been called, and assume that this will also
call mmc_gpiod_request_cd_irq(). Update those drivers to explicitly call
mmc_gpiod_request_cd_irq() themselves. Ideally, these drivers should be
modified to move their call to mmc_gpio_request_cd() before their call
to mmc_add_host(). However that's too large a change for stable.
This solves the problem (eliminates the kernel error message above),
since it guarantees that the IRQ can't trigger before mmc_start_host()
is called.
The critical point here is that once sdhci_add_host() calls
mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
fail. In other words, if there's a chance that mmc_start_host() may have
been called, and CD IRQs triggered, and the delayed_work scheduled,
sdhci_add_host() won't fail, and so cleanup is no longer via
sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
-> mmc_stop_host(), which does free the IRQ and cancel the work queue.
CC: Russell King <linux@arm.linux.org.uk>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a9481ff581a0cdedf3f344dfcb2dca8273ba2ae5
Author: Roger Tseng <rogerable@realtek.com>
Date: Fri Aug 15 14:06:01 2014 +0800
mmc: rtsx_usb_sdmmc: fix incorrect last byte in R2 response
commit 6f67cc6fd1cf339a0f19b9d4a998ec3c0123b1b6 upstream.
Current code erroneously fill the last byte of R2 response with an undefined
value. In addition, the controller actually 'offloads' the last byte
(CRC7, end bit) while receiving R2 response and thus it's impossible to get the
actual value. This could cause mmc stack to obtain inconsistent CID from the
same card after resume and misidentify it as a different card.
Fix by assigning dummy CRC and end bit: {7'b0, 1} = 0x1 to the last byte of R2.
Fixes: c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
Signed-off-by: Roger Tseng <rogerable@realtek.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a9ff187a302fd3dbaa377748be45e187fa24d81b
Author: Peter Griffin <peter.griffin@linaro.org>
Date: Fri Aug 15 14:02:15 2014 +0100
mmc: sdhci-pxav3: set_uhs_signaling is initialized twice differently
commit b315376573778b195e640a163675fb9f5937ddca upstream.
.set_uhs_signaling field is currently initialised twice once to the
arch specific callback pxav3_set_uhs_signaling, and also to the generic
sdhci_set_uhs_signaling callback.
This means that uhs is currently broken for this platform currently, as pxav3
has some special constriants which means it can't use the generic callback.
This happened in
commit 96d7b78cfc2f ("mmc: sdhci: convert sdhci_set_uhs_signaling() into a library function")
commit a702c8abb2a9 ("mmc: host: split up sdhci-pxa, create sdhci-pxav3.c")'
Fix this and hopefully prevent it happening in the future by ensuring named
initialisers always follow the declaration order in the structure definition.
Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a0f9df89576d1ef9490790fb4f1f4756f95f8586
Author: Fu Zhonghui <zhonghui.fu@linux.intel.com>
Date: Mon Aug 18 10:48:14 2014 +0800
mmc: core: sdio: Fix unconditional wake_up_process() on sdio thread
commit dea67c4ec8218b301d7cac7ee6e63dac0bc566cb upstream.
781e989cf59 ("mmc: sdhci: convert to new SDIO IRQ handling") and
bf3b5ec66bd ("mmc: sdio_irq: rework sdio irq handling") disabled
the use of our own custom threaded IRQ handler, but left in an
unconditional wake_up_process() on that handler at resume-time.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=80151
In addition, the check for MMC_CAP_SDIO_IRQ capability is added
before enable sdio IRQ.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <chris@printf.net>
Signed-off-by: Fu Zhonghui <zhonghui.fu@linux.intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 437be5976b4e540446c516b6e93c5196f4cb3012
Author: Lars-Peter Clausen <lars@metafoo.de>
Date: Wed Oct 22 10:51:18 2014 +0200
ASoC: adau1761: Fix input PGA volume
commit 3b283f0893f55cb79e4507e5ec34e49c17d0a787 upstream.
For the input PGA to work correctly the ALC clock needs to be active.
Otherwise volume changes are not applied.
Fixes: dab464b60b2 ("ASoC: Add ADAU1361/ADAU1761 audio CODEC support")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1aa7d96a49df67b5c2d911e14f98480938160a06
Author: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Date: Thu Oct 16 15:29:14 2014 +0100
ASoC: Intel: HSW/BDW only support S16 and S24 formats.
commit 2ccf3bd4f8b120936cdfc796baf40c5d3dfab68d upstream.
Fix driver with correct formats.
Signed-off-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 774d5ae19e4b6e8aa9dd197d3f0dd6931204f36a
Author: Dmitry Lavnikevich <d.lavnikevich@sam-solutions.com>
Date: Fri Oct 3 16:18:56 2014 +0300
ASoC: tlv320aic3x: fix PLL D configuration
commit 31d9f8faf9a54c851e835af489c82f45105a442f upstream.
Current caching implementation during regcache_sync() call bypasses
all register writes of values that are already known as default
(regmap reg_defaults). Same time in TLV320AIC3x codecs register 5
(AIC3X_PLL_PROGC_REG) write should be immediately followed by register
6 write (AIC3X_PLL_PROGD_REG) even if it was not changed. Otherwise
both registers will not be written.
This brings to issue that appears particulary in case of 44.1kHz
playback with 19.2MHz master clock. In this case AIC3X_PLL_PROGC_REG
is 0x6e while AIC3X_PLL_PROGD_REG is 0x0 (same as register
default). Thus AIC3X_PLL_PROGC_REG also remains not written and we get
wrong playback speed.
In this patch snd_soc_read() is used to get cached pll values and
snd_soc_write() (unlike regcache_sync() this function doesn't bypasses
hardware default values) to write them to registers.
Signed-off-by: Dmitry Lavnikevich <d.lavnikevich@sam-solutions.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a5af5c6d308d5a73a9d788dfb5cc405f400d0c54
Author: Daniel Mack <daniel@zonque.org>
Date: Tue Oct 7 14:33:46 2014 +0200
ASoC: soc-pcm: fix sig_bits determination in soc_pcm_apply_msb()
commit 5e63dfccf34d4dbf21429c4919f33c028ff49991 upstream.
In the SNDRV_PCM_STREAM_CAPTURE branch in soc_pcm_apply_msb(), look at
sig_bits of the capture stream, not the playback one.
Spotted by coverity.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 33e6c796838dca289666af379878ffae4d296990
Author: Daniel Mack <daniel@zonque.org>
Date: Tue Oct 7 13:41:24 2014 +0200
ASoC: soc-dapm: fix use after free
commit e5092c96c9c28f4d12811edcd02ca8eec16e748e upstream.
Coverity spotted the following possible use-after-free condition in
dapm_create_or_share_mixmux_kcontrol():
If kcontrol is NULL, and (wname_in_long_name && kcname_in_long_name)
validates to true, 'name' will be set to an allocated string, and be
freed a few lines later via the 'long_name' alias. 'name', however,
is used by dev_err() in case snd_ctl_add() fails.
Fix this by adding a jump label that frees 'long_name' at the end of
the function.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 403c9f08a334bb5429e28b99cb7f79bbad26e9af
Author: Daniel Mack <daniel@zonque.org>
Date: Tue Oct 7 13:41:23 2014 +0200
ASoC: core: fix use after free in snd_soc_remove_platform()
commit decc27b01d584c985c231e73d3b493de6ec07af8 upstream.
Coverity spotted an use-after-free condition in snd_soc_remove_platform().
Fix this by moving snd_soc_component_cleanup() after the debug print
statement which uses the component's string.
Signed-off-by: Daniel Mack <daniel@zonque.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b2764661ebb812b6b52481280fcaea9f75901565
Author: Ondrej Zary <linux@rainbow-software.org>
Date: Sat Sep 27 00:04:46 2014 +0200
libata-sff: Fix controllers with no ctl port
commit 6d8ca28fa688a9354bc9fbc935bdaeb3651b6677 upstream.
Currently, ata_sff_softreset is skipped for controllers with no ctl port.
But that also skips ata_sff_dev_classify required for device detection.
This means that libata is currently broken on controllers with no ctl port.
No device connected:
[ 1.872480] pata_isapnp 01:01.02: activated
[ 1.889823] scsi2 : pata_isapnp
[ 1.890109] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
[ 6.888110] ata3.01: qc timeout (cmd 0xec)
[ 6.888179] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 16.888085] ata3.01: qc timeout (cmd 0xec)
[ 16.888147] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 46.888086] ata3.01: qc timeout (cmd 0xec)
[ 46.888148] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 51.888100] ata3.00: qc timeout (cmd 0xec)
[ 51.888160] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 61.888079] ata3.00: qc timeout (cmd 0xec)
[ 61.888141] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 91.888089] ata3.00: qc timeout (cmd 0xec)
[ 91.888152] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5)
ATAPI device connected:
[ 1.882061] pata_isapnp 01:01.02: activated
[ 1.893430] scsi2 : pata_isapnp
[ 1.893719] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
[ 6.892107] ata3.01: qc timeout (cmd 0xec)
[ 6.892171] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 16.892079] ata3.01: qc timeout (cmd 0xec)
[ 16.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 46.892079] ata3.01: qc timeout (cmd 0xec)
[ 46.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5)
[ 46.908586] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr
[ 46.924570] ata3.00: configured for PIO0 (device error ignored)
[ 46.926295] scsi 2:0:0:0: CD-ROM ACER CD-767E/O 1.5X PQ: 0 ANSI: 5
[ 46.984519] sr0: scsi3-mmc drive: 6x/6x xa/form2 tray
[ 46.984592] cdrom: Uniform CD-ROM driver Revision: 3.20
So don't skip ata_sff_softreset, just skip the reset part of ata_bus_softreset
if the ctl port is not available.
This makes IDE port on ES968 behave correctly:
No device connected:
[ 4.670888] pata_isapnp 01:01.02: activated
[ 4.673207] scsi host2: pata_isapnp
[ 4.673675] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
[ 7.081840] Adding 2541652k swap on /dev/sda2. Priority:-1 extents:1 across:2541652k
ATAPI device connected:
[ 4.704362] pata_isapnp 01:01.02: activated
[ 4.706620] scsi host2: pata_isapnp
[ 4.706877] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11
[ 4.872782] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr
[ 4.888673] ata3.00: configured for PIO0 (device error ignored)
[ 4.893984] scsi 2:0:0:0: CD-ROM ACER CD-767E/O 1.5X PQ: 0 ANSI: 5
[ 7.015578] Adding 2541652k swap on /dev/sda2. Priority:-1 extents:1 across:2541652k
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bbfe3a4207309741eae7eb1d5047b8cdc6d5196b
Author: Scott Carter <ccscott@funsoft.com>
Date: Wed Sep 24 18:13:09 2014 -0700
pata_serverworks: disable 64-KB DMA transfers on Broadcom OSB4 IDE Controller
commit 37017ac6849e772e67dd187ba2fbd056c4afa533 upstream.
The Broadcom OSB4 IDE Controller (vendor and device IDs: 1166:0211)
does not support 64-KB DMA transfers.
Whenever a 64-KB DMA transfer is attempted,
the transfer fails and messages similar to the following
are written to the console log:
[ 2431.851125] sr 0:0:0:0: [sr0] Unhandled sense code
[ 2431.851139] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 2431.851152] sr 0:0:0:0: [sr0] Sense Key : Hardware Error [current]
[ 2431.851166] sr 0:0:0:0: [sr0] Add. Sense: Logical unit communication time-out
[ 2431.851182] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 76 f4 00 00 40 00
[ 2431.851210] end_request: I/O error, dev sr0, sector 121808
When the libata and pata_serverworks modules
are recompiled with ATA_DEBUG and ATA_VERBOSE_DEBUG defined in libata.h,
the 64-KB transfer size in the scatter-gather list can be seen
in the console log:
[ 2664.897267] sr 9:0:0:0: [sr0] Send:
[ 2664.897274] 0xf63d85e0
[ 2664.897283] sr 9:0:0:0: [sr0] CDB:
[ 2664.897288] Read(10): 28 00 00 00 7f b4 00 00 40 00
[ 2664.897319] buffer = 0xf6d6fbc0, bufflen = 131072, queuecommand 0xf81b7700
[ 2664.897331] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 7f b4 00 00 40
[ 2664.897338] ata_scsi_translate: ENTER
[ 2664.897345] ata_sg_setup: ENTER, ata1
[ 2664.897356] ata_sg_setup: 3 sg elements mapped
[ 2664.897364] ata_bmdma_fill_sg: PRD[0] = (0x66FD2000, 0xE000)
[ 2664.897371] ata_bmdma_fill_sg: PRD[1] = (0x65000000, 0x10000)
------------------------------------------------------> =======
[ 2664.897378] ata_bmdma_fill_sg: PRD[2] = (0x66A10000, 0x2000)
[ 2664.897386] ata1: ata_dev_select: ENTER, device 0, wait 1
[ 2664.897422] ata_sff_tf_load: feat 0x1 nsect 0x0 lba 0x0 0x0 0xFC
[ 2664.897428] ata_sff_tf_load: device 0xA0
[ 2664.897448] ata_sff_exec_command: ata1: cmd 0xA0
[ 2664.897457] ata_scsi_translate: EXIT
[ 2664.897462] leaving scsi_dispatch_cmnd()
[ 2664.897497] Doing sr request, dev = sr0, block = 0
[ 2664.897507] sr0 : reading 64/256 512 byte blocks.
[ 2664.897553] ata_sff_hsm_move: ata1: protocol 7 task_state 1 (dev_stat 0x58)
[ 2664.897560] atapi_send_cdb: send cdb
[ 2666.910058] ata_bmdma_port_intr: ata1: host_stat 0x64
[ 2666.910079] __ata_sff_port_intr: ata1: protocol 7 task_state 3
[ 2666.910093] ata_sff_hsm_move: ata1: protocol 7 task_state 3 (dev_stat 0x51)
[ 2666.910101] ata_sff_hsm_move: ata1: protocol 7 task_state 4 (dev_stat 0x51)
[ 2666.910129] sr 9:0:0:0: [sr0] Done:
[ 2666.910136] 0xf63d85e0 TIMEOUT
lspci shows that the driver used for the Broadcom OSB4 IDE Controller is
pata_serverworks:
00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8e [Master SecP SecO PriP])
Flags: bus master, medium devsel, latency 64
[virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1]
I/O ports at 0170 [size=8]
I/O ports at 0374 [size=4]
I/O ports at 1440 [size=16]
Kernel driver in use: pata_serverworks
The pata_serverworks driver supports five distinct device IDs,
one being the OSB4 and the other four belonging to the CSB series.
The CSB series appears to support 64-KB DMA transfers,
as tests on a machine with an SAI2 motherboard
containing a Broadcom CSB5 IDE Controller (vendor and device IDs: 1166:0212)
showed no problems with 64-KB DMA transfers.
This problem was first discovered when attempting to install openSUSE
from a DVD on a machine with an STL2 motherboard.
Using the pata_serverworks module,
older releases of openSUSE will not install at all due to the timeouts.
Releases of openSUSE prior to 11.3 can be installed by disabling
the pata_serverworks module using the brokenmodules boot parameter,
which causes the serverworks module to be used instead.
Recent releases of openSUSE (12.2 and later) include better error recovery and
will install, though very slowly.
On all openSUSE releases, the problem can be recreated
on a machine containing a Broadcom OSB4 IDE Controller
by mounting an install DVD and running a command similar to the following:
find /mnt -type f -print | xargs cat > /dev/null
The patch below corrects the problem.
Similar to the other ATA drivers that do not support 64-KB DMA transfers,
the patch changes the ata_port_operations qc_prep vector to point to a routine
that breaks any 64-KB segment into two 32-KB segments and
changes the scsi_host_template sg_tablesize element to reduce by half
the number of scatter/gather elements allowed.
These two changes affect only the OSB4.
Signed-off-by: Scott Carter <ccscott@funsoft.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f987bd6725929125d3fee9397a66a5d78244fecf
Author: Guenter Roeck <linux@roeck-us.net>
Date: Sun Sep 21 15:04:53 2014 -0700
Revert "percpu: free percpu allocation info for uniprocessor system"
commit bb2e226b3bef596dd56be97df655d857b4603923 upstream.
This reverts commit 3189eddbcafc ("percpu: free percpu allocation info for
uniprocessor system").
The commit causes a hang with a crisv32 image. This may be an architecture
problem, but at least for now the revert is necessary to be able to boot a
crisv32 image.
Cc: Tejun Heo <tj@kernel.org>
Cc: Honggang Li <enjoymindful@gmail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes: 3189eddbcafc ("percpu: free percpu allocation info for uniprocessor system")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 48319b709dca299ae7ea587433b278e25de1b28e
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date: Wed Sep 24 22:35:58 2014 -0400
SUNRPC: Add missing support for RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT
commit 2aca5b869ace67a63aab895659e5dc14c33a4d6e upstream.
The flag RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT was intended introduced in
order to allow NFSv4 clients to disable resend timeouts. Since those
cause the RPC layer to break the connection, they mess up the duplicate
reply caches that remain indexed on the port number in NFSv4..
This patch includes the code that was missing in the original to
set the appropriate flag in struct rpc_clnt, when the caller of
rpc_create() sets RPC_CLNT_CREATE_NO_RETRANS_TIMEOUT.
Fixes: 8a19a0b6cb2e (SUNRPC: Add RPC task and client level options to...)
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e08b682d8343f7c411809a03c62a2c6eed634eff
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Tue Sep 23 12:26:19 2014 -0400
SUNRPC: Don't wake tasks during connection abort
commit a743419f420a64d442280845c0377a915b76644f upstream.
When aborting a connection to preserve source ports, don't wake the task in
xs_error_report. This allows tasks with RPC_TASK_SOFTCONN to succeed if the
connection needs to be re-established since it preserves the task's status
instead of setting it to the status of the aborting kernel_connect().
This may also avoid a potential conflict on the socket's lock.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 23c6d39c4fde8ddaacfa653cfe4de8c4d9dca41f
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Tue Sep 23 12:26:20 2014 -0400
lockd: Try to reconnect if statd has moved
commit 173b3afceebe76fa2205b2c8808682d5b541fe3c upstream.
If rpc.statd is restarted, upcalls to monitor hosts can fail with
ECONNREFUSED. In that case force a lookup of statd's new port and retry the
upcall.
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fca296619d5a2d7be97296976105196ae0f31eaa
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri Oct 31 18:28:03 2014 +0200
stmmac: pci: set default of the filter bins
[ Upstream commit 1e19e084eae727654052339757ab7f1eaff58bad ]
The commit 3b57de958e2a brought the support for a different amount of the
filter bins, but didn't update the PCI driver accordingly. This patch appends
the default values when the device is enumerated via PCI bus.
Fixes: 3b57de958e2a (net: stmmac: Support devicetree configs for mcast and ucast filter entries)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 48705ea3054835cbd38eed21fbc1a8a67c916d37
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Fri Oct 31 03:10:31 2014 +0000
drivers/net: macvtap and tun depend on INET
[ Upstream commit de11b0e8c569b96c2cf6a811e3805b7aeef498a3 ]
These drivers now call ipv6_proxy_select_ident(), which is defined
only if CONFIG_INET is enabled. However, they have really depended
on CONFIG_INET for as long as they have allowed sending GSO packets
from userland.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: f43798c27684 ("tun: Allow GSO using virtio_net_hdr")
Fixes: b9fb9ee07e67 ("macvtap: add GSO/csum offload support")
Fixes: 5188cd44c55d ("drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 561295c6f6b4157a76db7ecba961b146241a4573
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Thu Oct 30 18:27:17 2014 +0000
drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets
[ Upstream commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 ]
UFO is now disabled on all drivers that work with virtio net headers,
but userland may try to send UFO/IPv6 packets anyway. Instead of
sending with ID=0, we should select identifiers on their behalf (as we
used to).
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data")
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 07fc5e7a20561ea11a0e4d12305b274e9c5863c4
Author: Tom Herbert <therbert@google.com>
Date: Thu Oct 30 08:40:56 2014 -0700
gre: Use inner mac length when computing tunnel length
[ Upstream commit 14051f0452a2c26a3f4791e6ad6a435e8f1945ff ]
Currently, skb_inner_network_header is used but this does not account
for Ethernet header for ETH_P_TEB. Use skb_inner_mac_header which
handles TEB and also should work with IP encapsulation in which case
inner mac and inner network headers are the same.
Tested: Ran TCP_STREAM over GRE, worked as expected.
Signed-off-by: Tom Herbert <therbert@google.com>
Acked-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9b5d0156bcfcc33763f9e62ab23a1d86f0f30ec7
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu Oct 30 15:59:28 2014 +0200
mlx4: Avoid leaking steering rules on flow creation error flow
[ Upstream commit 571e1b2c7a4c2fd5faa1648462a6b65fa26530d7 ]
If mlx4_ib_create_flow() attempts to create > 1 rules with the
firmware, and one of these registrations fail, we leaked the
already created flow rules.
One example of the leak is when the registration of the VXLAN ghost
steering rule fails, we didn't unregister the original rule requested
by the user, introduced in commit d2fce8a9060d "mlx4: Set
user-space raw Ethernet QPs to properly handle VXLAN traffic".
While here, add dump of the VXLAN portion of steering rules
so it can actually be seen when flow creation fails.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9e02c54c86ca6e4cfda44bc50ae329ad78f7c3ab
Author: Or Gerlitz <ogerlitz@mellanox.com>
Date: Thu Oct 30 15:59:27 2014 +0200
net/mlx4_en: Don't attempt to TX offload the outer UDP checksum for VXLAN
[ Upstream commit a4f2dacbf2a5045e34b98a35d9a3857800f25a7b ]
For VXLAN/NVGRE encapsulation, the current HW doesn't support offloading
both the outer UDP TX checksum and the inner TCP/UDP TX checksum.
The driver doesn't advertize SKB_GSO_UDP_TUNNEL_CSUM, however we are wrongly
telling the HW to offload the outer UDP checksum for encapsulated packets,
fix that.
Fixes: 837052d0ccc5 ('net/mlx4_en: Add netdev support for TCP/IP
offloads of vxlan tunneling')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 86449f087b4c5f77afd9b86c6e1d5d121754d583
Author: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Date: Thu Oct 30 10:09:53 2014 +0100
ipv4: Do not cache routing failures due to disabled forwarding.
[ Upstream commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58 ]
If we cache them, the kernel will reuse them, independently of
whether forwarding is enabled or not. Which means that if forwarding is
disabled on the input interface where the first routing request comes
from, then that unreachable result will be cached and reused for
other interfaces, even if forwarding is enabled on them. The opposite
is also true.
This can be verified with two interfaces A and B and an output interface
C, where B has forwarding enabled, but not A and trying
ip route get $dst iif A from $src && ip route get $dst iif B from $src
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Reviewed-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8400be4d70d0894447986843b509d3c2cf50257c
Author: Anish Bhatt <anish@chelsio.com>
Date: Wed Oct 29 17:54:03 2014 -0700
cxgb4 : Fix missing initialization of win0_lock
[ Upstream commit e327c225c911529898ec300cb96d2088893de3df ]
win0_lock was being used un-initialized, resulting in warning traces
being seen when lock debugging is enabled (and just wrong)
Fixes : fc5ab0209650 ('cxgb4: Replaced the backdoor mechanism to access the HW
memory with PCIe Window method')
Signed-off-by: Anish Bhatt <anish@chelsio.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5569bca0d2d1dea7146c86c2863a8e053040328b
Author: Eric Dumazet <edumazet@google.com>
Date: Wed Oct 22 19:43:46 2014 -0700
macvlan: fix a race on port dismantle and possible skb leaks
[ Upstream commit fe0ca7328d03d36aafecebb3af650e1bb2841c20 ]
We need to cancel the work queue after rcu grace period,
otherwise it can be rescheduled by incoming packets.
We need to purge queue if some skbs are still in it.
We can use __skb_queue_head_init() variant in
macvlan_process_broadcast()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue")
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 58899748e2a9241d89a5b891674314753b91664d
Author: Eric Dumazet <edumazet@google.com>
Date: Thu Oct 23 12:58:58 2014 -0700
tcp: md5: do not use alloc_percpu()
[ Upstream commit 349ce993ac706869d553a1816426d3a4bfda02b1 ]
percpu tcp_md5sig_pool contains memory blobs that ultimately
go through sg_set_buf().
-> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
This requires that whole area is in a physically contiguous portion
of memory. And that @buf is not backed by vmalloc().
Given that alloc_percpu() can use vmalloc() areas, this does not
fit the requirements.
Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_pool
is small anyway, there is no gain to dynamically allocate it.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in tcp_md5sig_pool")
Reported-by: Crestez Dan Leonard <cdleonard@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit df1465d47fed22a5e5d06965bf4c1e6a3acf9570
Author: Haiyang Zhang <haiyangz@microsoft.com>
Date: Wed Oct 22 13:47:18 2014 -0700
hyperv: Fix the total_data_buflen in send path
[ Upstream commit 942396b01989d54977120f3625e5ba31afe7a75c ]
total_data_buflen is used by netvsc_send() to decide if a packet can be put
into send buffer. It should also include the size of RNDIS message before the
Ethernet frame. Otherwise, a messge with total size bigger than send_section_size
may be copied into the send buffer, and cause data corruption.
[Request to include this patch to the Stable branches]
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit def42176ba8e1271d8c85fb900c2a92afbc8645b
Author: Sathya Perla <sathya.perla@emulex.com>
Date: Wed Oct 22 21:42:01 2014 +0530
net: fix saving TX flow hash in sock for outgoing connections
[ Upstream commit 9e7ceb060754f134231f68cb29d5db31419fe1ed ]
The commit "net: Save TX flow hash in sock and set in skbuf on xmit"
introduced the inet_set_txhash() and ip6_set_txhash() routines to calculate
and record flow hash(sk_txhash) in the socket structure. sk_txhash is used
to set skb->hash which is used to spread flows across multiple TXQs.
But, the above routines are invoked before the source port of the connection
is created. Because of this all outgoing connections that just differ in the
source port get hashed into the same TXQ.
This patch fixes this problem for IPv4/6 by invoking the the above routines
after the source port is available for the socket.
Fixes: b73c3d0e4("net: Save TX flow hash in sock and set in skbuf on xmit")
Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bd1313d7e0bf33eb59d3e3883d79e0ebde75b5e5
Author: Karl Beldan <karl.beldan@rivierawaves.com>
Date: Tue Oct 21 16:06:05 2014 +0200
net: tso: fix unaligned access to crafted TCP header in helper API
[ Upstream commit a63ba13eec092b70d4e5522d692eaeb2f9747387 ]
The crafted header start address is from a driver supplied buffer, which
one can reasonably expect to be aligned on a 4-bytes boundary.
However ATM the TSO helper API is only used by ethernet drivers and
the tcp header will then be aligned to a 2-bytes only boundary from the
header start address.
Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com>
Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a1ea31c839bb96e1267b4118c09354ecc8acb64
Author: Thomas Graf <tgraf@suug.ch>
Date: Tue Oct 21 22:05:38 2014 +0200
netlink: Re-add locking to netlink_lookup() and seq walker
[ Upstream commit 78fd1d0ab072d4d9b5f0b7c14a1516665170b565 ]
The synchronize_rcu() in netlink_release() introduces unacceptable
latency. Reintroduce minimal lookup so we can drop the
synchronize_rcu() until socket destruction has been RCUfied.
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: Steinar H. Gunderson <sgunderson@bigfoot.com>
Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f7ec20cfea3bd7e041a7785a1af379a0daaa28c
Author: Ian Morgan <imorgan@primordial.ca>
Date: Sun Oct 19 08:05:13 2014 -0400
ax88179_178a: fix bonding failure
[ Upstream commit 95ff88688781db2f64042e69bd499e518bbb36e5 ]
The following patch fixes a bug which causes the ax88179_178a driver to be
incapable of being added to a bond.
When I brought up the issue with the bonding maintainers, they indicated
that the real problem was with the NIC driver which must return zero for
success (of setting the MAC address). I see that several other NIC drivers
follow that pattern by either simply always returing zero, or by passing
through a negative (error) result while rewriting any positive return code
to zero. With that same philisophy applied to the ax88179_178a driver, it
allows it to work correctly with the bonding driver.
I believe this is suitable for queuing in -stable, as it's a small, simple,
and obvious fix that corrects a defect with no other known workaround.
This patch is against vanilla 3.17(.0).
Signed-off-by: Ian Morgan <imorgan@primordial.ca>
drivers/net/usb/ax88179_178a.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 96798a1735c430afca60cf0563c93a5973b3edf0
Author: Jon Paul Maloy <jon.maloy@ericsson.com>
Date: Fri Oct 17 15:25:28 2014 -0400
tipc: fix bug in bundled buffer reception
[ Upstream commit 643566d4b47e2956110e79c0e6f65db9b9ea42c6 ]
In commit ec8a2e5621db2da24badb3969eda7fd359e1869f ("tipc: same receive
code path for connection protocol and data messages") we omitted the
the possiblilty that an arriving message extracted from a bundle buffer
may be a multicast message. Such messages need to be to be delivered to
the socket via a separate function, tipc_sk_mcast_rcv(). As a result,
small multicast messages arriving as members of a bundle buffer will be
silently dropped.
This commit corrects the error by considering this case in the function
tipc_link_bundle_rcv().
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0e488ed818c6ff769d698d2f9db624ff57ab6af8
Author: Li RongQing <roy.qing.li@gmail.com>
Date: Fri Oct 17 16:53:23 2014 +0800
ipv4: fix a potential use after free in ip_tunnel_core.c
[ Upstream commit 1245dfc8cadb258386fcd27df38215a0eccb1f17 ]
pskb_may_pull() maybe change skb->data and make eth pointer oboslete,
so set eth after pskb_may_pull()
Fixes:3d7b46cd("ip_tunnel: push generic protocol handling to ip_tunnel module")
Cc: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5bbb2c08141fbdefd88da9714067bd5bf0a70d3d
Author: Vasily Averin <vvs@parallels.com>
Date: Wed Oct 15 16:24:02 2014 +0400
ipv4: dst_entry leak in ip_send_unicast_reply()
[ Upstream commit 4062090e3e5caaf55bed4523a69f26c3265cc1d2 ]
ip_setup_cork() called inside ip_append_data() steals dst entry from rt to cork
and in case errors in __ip_append_data() nobody frees stolen dst entry
Fixes: 2e77d89b2fa8 ("net: avoid a pair of dst_hold()/dst_release() in ip_append_data()")
Signed-off-by: Vasily Averin <vvs@parallels.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d5f6f014bc09b42fd98f604a1371551ec1518ff2
Author: Li RongQing <roy.qing.li@gmail.com>
Date: Fri Oct 17 14:06:16 2014 +0800
vxlan: fix a free after use
[ Upstream commit 7a9f526fc3ee49b6034af2f243676ee0a27dcaa8 ]
pskb_may_pull maybe change skb->data and make eth pointer oboslete,
so eth needs to reload
Fixes: 91269e390d062 ("vxlan: using pskb_may_pull as early as possible")
Cc: Eric Dumazet <edumazet@google.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8441b9479bedd326d4a1aa48b3c564214d5fb05c
Author: Li RongQing <roy.qing.li@gmail.com>
Date: Thu Oct 16 09:17:18 2014 +0800
vxlan: using pskb_may_pull as early as possible
[ Upstream commit 91269e390d062b526432f2ef1352b8df82e0e0bc ]
pskb_may_pull should be used to check if skb->data has enough space,
skb->len can not ensure that.
Cc: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3337a0d755009b121be43cde4d523eb60c9306c3
Author: Li RongQing <roy.qing.li@gmail.com>
Date: Thu Oct 16 08:49:41 2014 +0800
vxlan: fix a use after free in vxlan_encap_bypass
[ Upstream commit ce6502a8f9572179f044a4d62667c4645256d6e4 ]
when netif_rx() is done, the netif_rx handled skb maybe be freed,
and should not be used.
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b54811e60b95ef4c477f9f9e27de65aedbc3db86
Author: Jiri Pirko <jiri@resnulli.us>
Date: Mon Oct 13 16:34:10 2014 +0200
ipv4: fix nexthop attlen check in fib_nh_match
[ Upstream commit f76936d07c4eeb36d8dbb64ebd30ab46ff85d9f7 ]
fib_nh_match does not match nexthops correctly. Example:
ip route add 172.16.10/24 nexthop via 192.168.122.12 dev eth0 \
nexthop via 192.168.122.13 dev eth0
ip route del 172.16.10/24 nexthop via 192.168.122.14 dev eth0 \
nexthop via 192.168.122.15 dev eth0
Del command is successful and route is removed. After this patch
applied, the route is correctly matched and result is:
RTNETLINK answers: No such process
Please consider this for stable trees as well.
Fixes: 4e902c57417c4 ("[IPv4]: FIB configuration using struct fib_config")
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5643645171ce259c820bee02f2466f5019073deb
Author: Alexei Starovoitov <ast@plumgrid.com>
Date: Fri Oct 10 20:30:23 2014 -0700
x86: bpf_jit: fix two bugs in eBPF JIT compiler
[ Upstream commit e0ee9c12157dc74e49e4731e0d07512e7d1ceb95 ]
1.
JIT compiler using multi-pass approach to converge to final image size,
since x86 instructions are variable length. It starts with large
gaps between instructions (so some jumps may use imm32 instead of imm8)
and iterates until total program size is the same as in previous pass.
This algorithm works only if program size is strictly decreasing.
Programs that use LD_ABS insn need additional code in prologue, but it
was not emitted during 1st pass, so there was a chance that 2nd pass would
adjust imm32->imm8 jump offsets to the same number of bytes as increase in
prologue, which may cause algorithm to erroneously decide that size converged.
Fix it by always emitting largest prologue in the first pass which
is detected by oldproglen==0 check.
Also change error check condition 'proglen != oldproglen' to fail gracefully.
2.
while staring at the code realized that 64-byte buffer may not be enough
when 1st insn is large, so increase it to 128 to avoid buffer overflow
(theoretical maximum size of prologue+div is 109) and add runtime check.
Fixes: 622582786c9e ("net: filter: x86: internal BPF JIT")
Reported-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Tested-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 46a40624fd479078b511ad7d92166a90e6136456
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Mon Oct 27 14:40:39 2014 +0100
KVM: emulator: fix execution close to the segment limit
commit fd56e1546a5f734290cbedd2b81c518850736511 upstream.
Emulation of code that is 14 bytes to the segment limit or closer
(e.g. RIP = 0xFFFFFFF2 after reset) is broken because we try to read as
many as 15 bytes from the beginning of the instruction, and __linearize
fails when the passed (address, size) pair reaches out of the segment.
To fix this, let __linearize return the maximum accessible size (clamped
to 2^32-1) for usage in __do_insn_fetch_bytes, and avoid the limit check
by passing zero for the desired size.
For expand-down segments, __linearize is performing a redundant check.
(u32)(addr.ea + size - 1) <= lim can only happen if addr.ea is close
to 4GB; in this case, addr.ea + size - 1 will also fail the check against
the upper bound of the segment (which is provided by the D/B bit).
After eliminating the redundant check, it is simple to compute
the *max_size for expand-down segments too.
Now that the limit check is done in __do_insn_fetch_bytes, we want
to inject a general protection fault there if size < op_size (like
__linearize would have done), instead of just aborting.
This fixes booting Tiano Core from emulated flash with EPT disabled.
Fixes: 719d5a9b2487e0562f178f61e323c3dc18a8b200
Reported-by: Borislav Petkov <bp@suse.de>
Tested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 98484ece15e6346df257c4a46887f710edeb8d2d
Author: Rabin Vincent <rabin@rab.in>
Date: Wed Oct 29 23:06:58 2014 +0100
tracing/syscalls: Ignore numbers outside NR_syscalls' range
commit 086ba77a6db00ed858ff07451bedee197df868c9 upstream.
ARM has some private syscalls (for example, set_tls(2)) which lie
outside the range of NR_syscalls. If any of these are called while
syscall tracing is being performed, out-of-bounds array access will
occur in the ftrace and perf sys_{enter,exit} handlers.
# trace-cmd record -e raw_syscalls:* true && trace-cmd report
...
true-653 [000] 384.675777: sys_enter: NR 192 (0, 1000, 3, 4000022, ffffffff, 0)
true-653 [000] 384.675812: sys_exit: NR 192 = 1995915264
true-653 [000] 384.675971: sys_enter: NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1)
true-653 [000] 384.675988: sys_exit: NR 983045 = 0
...
# trace-cmd record -e syscalls:* true
[ 17.289329] Unable to handle kernel paging request at virtual address aaaaaace
[ 17.289590] pgd = 9e71c000
[ 17.289696] [aaaaaace] *pgd=00000000
[ 17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 17.290169] Modules linked in:
[ 17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21
[ 17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000
[ 17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8
[ 17.290866] LR is at syscall_trace_enter+0x124/0x184
Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers.
Commit cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls"
added the check for less than zero, but it should have also checked
for greater than NR_syscalls.
Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in
Fixes: cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls"
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>