Dave Jones [Tue, 15 Mar 2016 01:20:54 +0000 (21:20 -0400)]
x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()
[ Upstream commit
7834c10313fb823e538f2772be78edcdeed2e6e3 ]
Since 4.4, I've been able to trigger this occasionally:
===============================
[ INFO: suspicious RCU usage. ]
4.5.0-rc7-think+ #3 Not tainted
Cc: Andi Kleen <ak@linux.intel.com>
Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-------------------------------
./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/3/0.
stack backtrace:
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3
ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a
ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6
ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60
Call Trace:
<IRQ> [<
ffffffff92560c2a>] dump_stack+0x67/0x9d
[<
ffffffff921376a6>] lockdep_rcu_suspicious+0xe6/0x100
[<
ffffffff925ae7a7>] do_trace_write_msr+0x127/0x1a0
[<
ffffffff92061c83>] native_apic_msr_eoi_write+0x23/0x30
[<
ffffffff92054408>] smp_trace_call_function_interrupt+0x38/0x360
[<
ffffffff92d1ca60>] trace_call_function_interrupt+0x90/0xa0
<EOI> [<
ffffffff92ac5124>] ? cpuidle_enter_state+0x1b4/0x520
Move the entering_irq() call before ack_APIC_irq(), because entering_irq()
tells the RCU susbstems to end the extended quiescent state, so that the
following trace call in ack_APIC_irq() works correctly.
Suggested-by: Andi Kleen <ak@linux.intel.com>
Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()"
Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Zhang Rui [Fri, 18 Mar 2016 02:03:24 +0000 (10:03 +0800)]
Thermal: Ignore invalid trip points
[ Upstream commit
81ad4276b505e987dd8ebbdf63605f92cd172b52 ]
In some cases, platform thermal driver may report invalid trip points,
thermal core should not take any action for these trip points.
This fixed a regression that bogus trip point starts to screw up thermal
control on some Lenovo laptops, after
commit
bb431ba26c5cd0a17c941ca6c3a195a3a6d5d461
Author: Zhang Rui <rui.zhang@intel.com>
Date: Fri Oct 30 16:31:47 2015 +0800
Thermal: initialize thermal zone device correctly
After thermal zone device registered, as we have not read any
temperature before, thus tz->temperature should not be 0,
which actually means 0C, and thermal trend is not available.
In this case, we need specially handling for the first
thermal_zone_device_update().
Both thermal core framework and step_wise governor is
enhanced to handle this. And since the step_wise governor
is the only one that uses trends, so it's the only thermal
governor that needs to be updated.
Tested-by: Manuel Krause <manuelkrause@netscape.net>
Tested-by: szegad <szegadlo@poczta.onet.pl>
Tested-by: prash <prash.n.rao@gmail.com>
Tested-by: amish <ammdispose-arch@yahoo.com>
Tested-by: Matthias <morpheusxyz123@yahoo.de>
Reviewed-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
CC: <stable@vger.kernel.org> #3.18+
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317190
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114551
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Benjamin Tissoires [Fri, 18 Mar 2016 00:12:54 +0000 (17:12 -0700)]
Input: synaptics - handle spurious release of trackstick buttons, again
[ Upstream commit
82be788c96ed5978d3cb4a00079e26b981a3df3f ]
Looks like the fimware 8.2 still has the extra buttons spurious release
bug.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=114321
Cc: stable@vger.kernel.org
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oliver Neukum [Thu, 17 Mar 2016 21:00:17 +0000 (14:00 -0700)]
Input: ims-pcu - sanity check against missing interfaces
[ Upstream commit
a0ad220c96692eda76b2e3fd7279f3dcd1d8a8ff ]
A malicious device missing interface can make the driver oops.
Add sanity checking.
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Adrian Hunter [Mon, 7 Mar 2016 11:33:55 +0000 (13:33 +0200)]
mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout
[ Upstream commit
995136247915c5cee633d55ba23f6eebf67aa567 ]
Normally the timeout clock frequency is read from the capabilities
register. It is also possible to set the value prior to calling
sdhci_add_host() in which case that value will override the
capabilities register value. However that was being done after
calculating max_busy_timeout so that max_busy_timeout was being
calculated using the wrong value of timeout_clk.
Fix that by moving the override before max_busy_timeout is
calculated.
The result is that the max_busy_timeout and max_discard
increase for BSW devices so that, for example, the time for
mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds
to about 20 seconds.
Note, in the future, the capabilities setting will be tidied up
and this override won't be used anymore. However this fix is
needed for stable.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andy Lutomirski [Wed, 16 Mar 2016 21:14:22 +0000 (14:14 -0700)]
x86/iopl: Fix iopl capability check on Xen PV
[ Upstream commit
c29016cf41fe9fa994a5ecca607cf5f1cd98801e ]
iopl(3) is supposed to work if iopl is already 3, even if
unprivileged. This didn't work right on Xen PV. Fix it.
Reviewewd-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: David Vrabel <david.vrabel@citrix.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jan Beulich <JBeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans de Goede [Sun, 8 Mar 2015 20:53:42 +0000 (21:53 +0100)]
ARM: dts: sunxi: Adjust touchscreen compatible for sun5i and later
[ Upstream commit
8bf1b9b3d90194a174493febc731f7783f2adf1a ]
The touchscreen controller in the A13 and later has a different temperature
curve than the one in the original A10, change the compatible for the A13 and
later so that the kernel will use the correct curve.
Reported-by: Tong Zhang <lovewilliam@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
J. Bruce Fields [Thu, 3 Mar 2016 00:36:21 +0000 (16:36 -0800)]
nfsd: fix deadlock secinfo+readdir compound
[ Upstream commit
2f6fc056e899bd0144a08da5cacaecbe8997cd74 ]
nfsd_lookup_dentry exits with the parent filehandle locked. fh_put also
unlocks if necessary (nfsd filehandle locking is probably too lenient),
so it gets unlocked eventually, but if the following op in the compound
needs to lock it again, we can deadlock.
A fuzzer ran into this; normal clients don't send a secinfo followed by
a readdir in the same compound.
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 15 Mar 2016 11:09:10 +0000 (12:09 +0100)]
ALSA: usb-audio: Fix NULL dereference in create_fixed_stream_quirk()
[ Upstream commit
0f886ca12765d20124bd06291c82951fd49a33be ]
create_fixed_stream_quirk() may cause a NULL-pointer dereference by
accessing the non-existing endpoint when a USB device with a malformed
USB descriptor is used.
This patch avoids it simply by adding a sanity check of bNumEndpoints
before the accesses.
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=971125
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Magnus Damm [Tue, 16 Feb 2016 04:06:41 +0000 (13:06 +0900)]
mmc: mmc_spi: Add Card Detect comments and fix CD GPIO case
[ Upstream commit
bcdc9f260bdce09913db1464be9817170d51044a ]
This patch fixes the MMC SPI driver from doing polling card detect when a
CD GPIO that supports interrupts is specified using the gpios DT property.
Without this patch the DT node below results in the following output:
spi_gpio: spi-gpio { /* SD2 @ CN12 */
compatible = "spi-gpio";
#address-cells = <1>;
#size-cells = <0>;
gpio-sck = <&gpio6 16 GPIO_ACTIVE_HIGH>;
gpio-mosi = <&gpio6 17 GPIO_ACTIVE_HIGH>;
gpio-miso = <&gpio6 18 GPIO_ACTIVE_HIGH>;
num-chipselects = <1>;
cs-gpios = <&gpio6 21 GPIO_ACTIVE_LOW>;
status = "okay";
spi@0 {
compatible = "mmc-spi-slot";
reg = <0>;
voltage-ranges = <3200 3400>;
spi-max-frequency = <
25000000>;
gpios = <&gpio6 22 GPIO_ACTIVE_LOW>; /* CD */
};
};
# dmesg | grep mmc
mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new SDHC card on SPI
mmcblk0: mmc0:0000 SU04G 3.69 GiB
mmcblk0: p1
With this patch applied the "cd polling" portion above disappears.
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Cc: stable@vger.kernel.org # v3.18+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Takashi Iwai [Tue, 15 Mar 2016 15:44:55 +0000 (16:44 +0100)]
ALSA: hda - Fix unconditional GPIO toggle via automute
[ Upstream commit
1f7c6658962fa1260c1658d681bd6bb0c746b99a ]
Cirrus HD-audio driver may adjust GPIO pins for EAPD dynamically
depending on the jack plug state. This works fine for the auto-mute
mode where the speaker gets muted upon the HP jack plug. OTOH, when
the auto-mute mode is off, this turns off the EAPD unexpectedly
depending on the jack state, which results in the silent speaker
output.
This patch fixes the silent speaker output issue by setting GPIO bits
constantly when the auto-mute mode is off.
Reported-and-tested-by: moosotc@gmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Torokhov [Mon, 14 Mar 2016 22:21:04 +0000 (15:21 -0700)]
HID: i2c-hid: fix OOB write in i2c_hid_set_or_send_report()
[ Upstream commit
3b654288b196ceaa156029d9457ccbded0489b98 ]
Even though hid_hw_* checks that passed in data_len is less than
HID_MAX_BUFFER_SIZE it is not enough, as i2c-hid does not necessarily
allocate buffers of HID_MAX_BUFFER_SIZE but rather checks all device
reports and select largest size. In-kernel users normally just send as much
data as report needs, so there is no problem, but hidraw users can do
whatever they please:
BUG: KASAN: slab-out-of-bounds in memcpy+0x34/0x54 at addr
ffffffc07135ea80
Write of size 4101 by task syz-executor/8747
CPU: 2 PID: 8747 Comm: syz-executor Tainted: G BU 3.18.0 #37
Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
Call trace:
[<
ffffffc00020ebcc>] dump_backtrace+0x0/0x258 arch/arm64/kernel/traps.c:83
[<
ffffffc00020ee40>] show_stack+0x1c/0x2c arch/arm64/kernel/traps.c:172
[< inline >] __dump_stack lib/dump_stack.c:15
[<
ffffffc001958114>] dump_stack+0x90/0x140 lib/dump_stack.c:50
[< inline >] print_error_description mm/kasan/report.c:97
[< inline >] kasan_report_error mm/kasan/report.c:278
[<
ffffffc0004597dc>] kasan_report+0x268/0x530 mm/kasan/report.c:305
[<
ffffffc0004592e8>] __asan_storeN+0x20/0x150 mm/kasan/kasan.c:718
[<
ffffffc0004594e0>] memcpy+0x30/0x54 mm/kasan/kasan.c:299
[<
ffffffc001306354>] __i2c_hid_command+0x2b0/0x7b4 drivers/hid/i2c-hid/i2c-hid.c:178
[< inline >] i2c_hid_set_or_send_report drivers/hid/i2c-hid/i2c-hid.c:321
[<
ffffffc0013079a0>] i2c_hid_output_raw_report.isra.2+0x3d4/0x4b8 drivers/hid/i2c-hid/i2c-hid.c:589
[<
ffffffc001307ad8>] i2c_hid_output_report+0x54/0x68 drivers/hid/i2c-hid/i2c-hid.c:602
[< inline >] hid_hw_output_report include/linux/hid.h:1039
[<
ffffffc0012cc7a0>] hidraw_send_report+0x400/0x414 drivers/hid/hidraw.c:154
[<
ffffffc0012cc7f4>] hidraw_write+0x40/0x64 drivers/hid/hidraw.c:177
[<
ffffffc0004681dc>] vfs_write+0x1d4/0x3cc fs/read_write.c:534
[< inline >] SYSC_pwrite64 fs/read_write.c:627
[<
ffffffc000468984>] SyS_pwrite64+0xec/0x144 fs/read_write.c:614
Object at
ffffffc07135ea80, in cache kmalloc-512
Object allocated with size 268 bytes.
Let's check data length against the buffer size before attempting to copy
data over.
Cc: stable@vger.kernel.org
Reported-by: Alexander Potapenko <glider@google.com>
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitri Epshtein [Sat, 12 Mar 2016 17:44:18 +0000 (18:44 +0100)]
net: mvneta: enable change MAC address when interface is up
[ Upstream commit
928b6519afeb2a5e2dc61154380b545ed66c476a ]
Function eth_prepare_mac_addr_change() is called as part of MAC
address change. This function check if interface is running.
To enable change MAC address when interface is running:
IFF_LIVE_ADDR_CHANGE flag must be set to dev->priv_flags field
Fixes: c5aff18204da ("net: mvneta: driver for Marvell Armada 370/XP
network unit")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Ming Lei [Sat, 12 Mar 2016 01:29:40 +0000 (09:29 +0800)]
md: multipath: don't hardcopy bio in .make_request path
[ Upstream commit
fafcde3ac1a418688a734365203a12483b83907a ]
Inside multipath_make_request(), multipath maps the incoming
bio into low level device's bio, but it is totally wrong to
copy the bio into mapped bio via '*mapped_bio = *bio'. For
example, .__bi_remaining is kept in the copy, especially if
the incoming bio is chained to via bio splitting, so .bi_end_io
can't be called for the mapped bio at all in the completing path
in this kind of situation.
This patch fixes the issue by using clone style.
Cc: stable@vger.kernel.org (v3.14+)
Reported-and-tested-by: Andrea Righi <righi.andrea@gmail.com>
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Thu, 10 Mar 2016 20:55:26 +0000 (15:55 -0500)]
drm/radeon: rework fbdev handling on chips with no connectors
[ Upstream commit
e5f243bd2edd95c6cc1d90c1878f821068e83fba ]
Move all the logic to radeon_fb.c and add checks to functions
called frome elsewhere.
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=112781
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dave Airlie [Mon, 23 Feb 2015 23:23:59 +0000 (09:23 +1000)]
radeon/fb: add wrapper functions around fb connector add/remove
[ Upstream commit
bb26270ed2d1944e0d7d573b4c46b5dade8db095 ]
These are just two wrappers to be used in the MST code later.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Josh Boyer [Mon, 14 Mar 2016 16:33:40 +0000 (09:33 -0700)]
Input: powermate - fix oops with malicious USB descriptors
[ Upstream commit
9c6ba456711687b794dcf285856fc14e2c76074f ]
The powermate driver expects at least one valid USB endpoint in its
probe function. If given malicious descriptors that specify 0 for
the number of endpoints, it will crash. Validate the number of
endpoints on the interface before using them.
The full report for this issue can be found here:
http://seclists.org/bugtraq/2016/Mar/85
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sebastian Ott [Mon, 14 Mar 2016 14:47:23 +0000 (15:47 +0100)]
s390/pci: enforce fmb page boundary rule
[ Upstream commit
80c544ded25ac14d7cc3e555abb8ed2c2da99b84 ]
The function measurement block must not cross a page boundary. Ensure
that by raising the alignment requirement to the smallest power of 2
larger than the size of the fmb.
Fixes: d0b088531 ("s390/pci: performance statistics and debug infrastructure")
Cc: stable@vger.kernel.org # v3.8+
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sebastian Ott [Fri, 10 Apr 2015 12:33:08 +0000 (14:33 +0200)]
s390/pci: extract software counters from fmb
[ Upstream commit
6001018ae8c659e624351d2e73b1272bacd68d6a ]
The software counters are not a part of the function measurement
block. Also we do not check for zdev->fmb != NULL when using these
counters (function measurement can be toggled at runtime). Just move
the software counters to struct zpci_dev.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vittorio Gambaletta (VittGam) [Sun, 13 Mar 2016 21:19:34 +0000 (22:19 +0100)]
ALSA: intel8x0: Add clock quirk entry for
AD1981B on IBM ThinkPad X41.
[ Upstream commit
4061db03dd71d195b9973ee466f6ed32f6a3fc16 ]
The clock measurement on the AC'97 audio card found in the IBM ThinkPad X41
will often fail, so add a quirk entry to fix it.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=441087
Cc: <stable@vger.kernel.org>
Signed-off-by: Vittorio Gambaletta <linuxbugs@vittgam.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sasha Levin [Thu, 7 Apr 2016 22:19:07 +0000 (18:19 -0400)]
ALSA: hda - Add new GPU codec ID 0x10de0083 to snd-hda
[ Upstream commit
3ec622f40913ae036f218e5e7e92df9c1f1753d9 ]
Vendor ID 0x10de0083 is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Aaron Plattner [Sun, 13 Mar 2016 20:58:57 +0000 (13:58 -0700)]
ALSA: hda - Add new GPU codec ID 0x10de0082 to snd-hda
[ Upstream commit
2d369c748c2ecc2a012ee85412a04007e67913ec ]
Vendor ID 0x10de0082 is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Aaron Plattner [Tue, 21 Jul 2015 00:14:14 +0000 (17:14 -0700)]
ALSA: hda - Add new GPU codec ID 0x10de007d to snd-hda
[ Upstream commit
6c3d91193d829bf58a35a10650415b05a736ca6c ]
Vendor ID 0x10de007d is used by a yet-to-be-named GPU chip.
This chip also has the 2-ch audio swapping bug, so patch_nvhdmi is
appropriate here.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Fabio Estevam [Mon, 22 Feb 2016 12:01:53 +0000 (09:01 -0300)]
bus: imx-weim: Take the 'status' property value into account
[ Upstream commit
33b96d2c9579213cf3f36d7b29841b1e464750c4 ]
Currently we have an incorrect behaviour when multiple devices
are present under the weim node. For example:
&weim {
...
status = "okay";
sram@0,0 {
...
status = "okay";
};
mram@0,0 {
...
status = "disabled";
};
};
In this case only the 'sram' device should be probed and not 'mram'.
However what happens currently is that the status variable is ignored,
causing the 'sram' device to be disabled and 'mram' to be enabled.
Change the weim_parse_dt() function to use
for_each_available_child_of_node()so that the devices marked with
'status = disabled' are not probed.
Cc: <stable@vger.kernel.org>
Suggested-by: Wolfgang Netbal <wolfgang.netbal@sigmatek.at>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Max Filippov [Thu, 3 Mar 2016 15:34:29 +0000 (18:34 +0300)]
xtensa: clear all DBREAKC registers on start
[ Upstream commit
7de7ac785ae18a2cdc78d7560f48e3213d9ea0ab ]
There are XCHAL_NUM_DBREAK registers, clear them all.
This also fixes cryptic assembler error message with binutils 2.25 when
XCHAL_NUM_DBREAK is 0:
as: out of memory allocating
18446744073709551575 bytes after a total
of 495616 bytes
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Max Filippov [Thu, 25 Feb 2016 20:27:51 +0000 (23:27 +0300)]
xtensa: fix preemption in {clear,copy}_user_highpage
[ Upstream commit
a67cc9aa2dfc6e66addf240bbd79e16e01565e81 ]
Disabling pagefault makes little sense there, preemption disabling is
what was meant.
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Max Filippov [Mon, 8 Feb 2016 22:02:38 +0000 (01:02 +0300)]
xtensa: ISS: don't hang if stdin EOF is reached
[ Upstream commit
362014c8d9d51d504c167c44ac280169457732be ]
Simulator stdin may be connected to a file, when its end is reached
kernel hangs in infinite loop inside rs_poll, because simc_poll always
signals that descriptor 0 is readable and simc_read always returns 0.
Check simc_read return value and exit loop if it's not positive. Also
don't rewind polling timer if it's zero.
Cc: stable@vger.kernel.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hui Wang [Fri, 11 Mar 2016 04:04:02 +0000 (12:04 +0800)]
ALSA: hda - fix the mic mute button and led problem for a Lenovo AIO
[ Upstream commit
6ef2f68fa38bf415830f67903d87180d933e0f47 ]
This Lenovo ThinkCentre AIO also uses Line2 as mic mute button and
uses GPIO2 to control the mic mute led, so applying this quirk can
make both the button and led work.
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1555912
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Thu, 3 Mar 2016 22:32:19 +0000 (01:32 +0300)]
Bluetooth: btusb: Add a new AR3012 ID 13d3:3472
[ Upstream commit
75c6aca4765dbe3d0c1507ab5052f2e373dc2331 ]
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=01 Dev#= 4 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3472 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1552925
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Luck, Tony [Thu, 10 Mar 2016 00:40:48 +0000 (16:40 -0800)]
EDAC/sb_edac: Fix computation of channel address
[ Upstream commit
eb1af3b71f9d83e45f2fd2fd649356e98e1c582c ]
Large memory Haswell-EX systems with multiple DIMMs per channel were
sometimes reporting the wrong DIMM.
Found three problems:
1) Debug printouts for socket and channel interleave were not interpreting
the register fields correctly. The socket interleave field is a 2^X
value (0=1, 1=2, 2=4, 3=8). The channel interleave is X+1 (0=1, 1=2,
2=3. 3=4).
2) Actual use of the socket interleave value didn't interpret as 2^X
3) Conversion of address to channel address was complicated, and wrong.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Acked-by: Aristeu Rozanski <arozansk@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-edac@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
OGAWA Hirofumi [Thu, 10 Mar 2016 04:47:25 +0000 (23:47 -0500)]
jbd2: fix FS corruption possibility in jbd2_journal_destroy() on umount path
[ Upstream commit
c0a2ad9b50dd80eeccd73d9ff962234590d5ec93 ]
On umount path, jbd2_journal_destroy() writes latest transaction ID
(->j_tail_sequence) to be used at next mount.
The bug is that ->j_tail_sequence is not holding latest transaction ID
in some cases. So, at next mount, there is chance to conflict with
remaining (not overwritten yet) transactions.
mount (id=10)
write transaction (id=11)
write transaction (id=12)
umount (id=10) <= the bug doesn't write latest ID
mount (id=10)
write transaction (id=11)
crash
mount
[recovery process]
transaction (id=11)
transaction (id=12) <= valid transaction ID, but old commit
must not replay
Like above, this bug become the cause of recovery failure, or FS
corruption.
So why ->j_tail_sequence doesn't point latest ID?
Because if checkpoint transactions was reclaimed by memory pressure
(i.e. bdev_try_to_free_page()), then ->j_tail_sequence is not updated.
(And another case is, __jbd2_journal_clean_checkpoint_list() is called
with empty transaction.)
So in above cases, ->j_tail_sequence is not pointing latest
transaction ID at umount path. Plus, REQ_FLUSH for checkpoint is not
done too.
So, to fix this problem with minimum changes, this patch updates
->j_tail_sequence, and issue REQ_FLUSH. (With more complex changes,
some optimizations would be possible to avoid unnecessary REQ_FLUSH
for example though.)
BTW,
journal->j_tail_sequence =
++journal->j_transaction_sequence;
Increment of ->j_transaction_sequence seems to be unnecessary, but
ext3 does this.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Douglas Gilbert [Thu, 3 Mar 2016 05:31:29 +0000 (00:31 -0500)]
sg: fix dxferp in from_to case
[ Upstream commit
5ecee0a3ee8d74b6950cb41e8989b0c2174568d4 ]
One of the strange things that the original sg driver did was let the
user provide both a data-out buffer (it followed the sg_header+cdb)
_and_ specify a reply length greater than zero. What happened was that
the user data-out buffer was copied into some kernel buffers and then
the mid level was told a read type operation would take place with the
data from the device overwriting the same kernel buffers. The user would
then read those kernel buffers back into the user space.
From what I can tell, the above action was broken by commit
fad7f01e61bf
("sg: set dxferp to NULL for READ with the older SG interface") in 2008
and syzkaller found that out recently.
Make sure that a user space pointer is passed through when data follows
the sg_header structure and command. Fix the abnormal case when a
non-zero reply_len is also given.
Fixes: fad7f01e61bf737fe8a3740d803f000db57ecac6
Cc: <stable@vger.kernel.org> #v2.6.28+
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com>
Reviewed-by: Ewan Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mario Kleiner [Sun, 6 Mar 2016 01:39:53 +0000 (02:39 +0100)]
drm/radeon: Don't drop DP 2.7 Ghz link setup on some cards.
[ Upstream commit
459ee1c3fd097ab56ababd8ff4bb7ef6a792de33 ]
As observed on Apple iMac10,1, DCE-3.2, RV-730,
link rate of 2.7 Ghz is not selected, because
the args.v1.ucConfig flag setting for 2.7 Ghz
gets overwritten by a following assignment of
the transmitter to use.
Move link rate setup a few lines down to fix this.
In practice this didn't have any positive or
negative effect on display setup on the tested
iMac10,1 so i don't know if backporting to stable
makes sense or not.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Alex Deucher [Wed, 2 Mar 2016 16:47:29 +0000 (11:47 -0500)]
drm/radeon: disable runtime pm on PX laptops without dGPU power control
[ Upstream commit
e64c952efb8e0c15ae82cec8e455ab4910690ef1 ]
Some PX laptops don't provide an ACPI method to control dGPU power. On
those systems, the driver is responsible for handling the dGPU power
state. Disable runtime PM on them until support for this is implemented.
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Maurizio Lombardi [Fri, 4 Mar 2016 09:41:49 +0000 (10:41 +0100)]
be2iscsi: set the boot_kset pointer to NULL in case of failure
[ Upstream commit
84bd64993f916bcf86270c67686ecf4cea7b8933 ]
In beiscsi_setup_boot_info(), the boot_kset pointer should be set to
NULL in case of failure otherwise an invalid pointer dereference may
occur later.
Cc: <stable@vger.kernel.org>
Signed-off-by: Maurizio Lombardi <mlombard@redhat.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Jitendra Bhivare <jitendra.bhivare@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bjorn Helgaas [Fri, 26 Feb 2016 15:15:11 +0000 (09:15 -0600)]
x86/PCI: Mark Broadwell-EP Home Agent & PCU as having non-compliant BARs
[ Upstream commit
b894157145e4ac7598d7062bc93320898a5e059e ]
The Home Agent and PCU PCI devices in Broadwell-EP have a non-BAR register
where a BAR should be. We don't know what the side effects of sizing the
"BAR" would be, and we don't know what address space the "BAR" might appear
to describe.
Mark these devices as having non-compliant BARs so the PCI core doesn't
touch them.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Andi Kleen <ak@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Wheeler [Mon, 7 Mar 2016 23:17:50 +0000 (15:17 -0800)]
bcache: fix cache_set_flush() NULL pointer dereference on OOM
[ Upstream commit
f8b11260a445169989d01df75d35af0f56178f95 ]
When bch_cache_set_alloc() fails to kzalloc the cache_set, the
asyncronous closure handling tries to dereference a cache_set that
hadn't yet been allocated inside of cache_set_flush() which is called
by __cache_set_unregister() during cleanup. This appears to happen only
during an OOM condition on bcache_register.
Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Wheeler [Fri, 26 Feb 2016 22:33:56 +0000 (14:33 -0800)]
bcache: cleaned up error handling around register_cache()
[ Upstream commit
9b299728ed777428b3908ac72ace5f8f84b97789 ]
Fix null pointer dereference by changing register_cache() to return an int
instead of being void. This allows it to return -ENOMEM or -ENODEV and
enables upper layers to handle the OOM case without NULL pointer issues.
See this thread:
http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3521
Fixes this error:
gargamel:/sys/block/md5/bcache# echo /dev/sdh2 > /sys/fs/bcache/register
bcache: register_cache() error opening sdh2: cannot allocate memory
BUG: unable to handle kernel NULL pointer dereference at
00000000000009b8
IP: [<
ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache]
PGD
120dff067 PUD
1119a3067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in: veth ip6table_filter ip6_tables
(...)
CPU: 4 PID: 3371 Comm: kworker/4:3 Not tainted 4.4.2-amd64-i915-volpreempt-
20160213bc1 #3
Hardware name: System manufacturer System Product Name/P8H67-M PRO, BIOS 3904 04/27/2013
Workqueue: events cache_set_flush [bcache]
task:
ffff88020d5dc280 ti:
ffff88020b6f8000 task.ti:
ffff88020b6f8000
RIP: 0010:[<
ffffffffc05a7e8d>] [<
ffffffffc05a7e8d>] cache_set_flush+0x102/0x15c [bcache]
Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
Tested-by: Marc MERLIN <marc@merlins.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eric Wheeler [Fri, 26 Feb 2016 22:39:06 +0000 (14:39 -0800)]
bcache: fix race of writeback thread starting before complete initialization
[ Upstream commit
07cc6ef8edc47f8b4fc1e276d31127a0a5863d4d ]
The bch_writeback_thread might BUG_ON in read_dirty() if
dc->sb==BDEV_STATE_DIRTY and bch_sectors_dirty_init has not yet completed
its related initialization. This patch downs the dc->writeback_lock until
after initialization is complete, thus preventing bch_writeback_thread
from proceeding prematurely.
See this thread:
http://thread.gmane.org/gmane.linux.kernel.bcache.devel/3453
Signed-off-by: Eric Wheeler <bcache@linux.ewheeler.net>
Tested-by: Marc MERLIN <marc@merlins.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Chris Friesen [Sun, 6 Mar 2016 05:18:48 +0000 (23:18 -0600)]
sched/cputime: Fix steal_account_process_tick() to always return jiffies
[ Upstream commit
f9c904b7613b8b4c85b10cd6b33ad41b2843fa9d ]
The callers of steal_account_process_tick() expect it to return
whether a jiffy should be considered stolen or not.
Currently the return value of steal_account_process_tick() is in
units of cputime, which vary between either jiffies or nsecs
depending on CONFIG_VIRT_CPU_ACCOUNTING_GEN.
If cputime has nsecs granularity and there is a tiny amount of
stolen time (a few nsecs, say) then we will consider the entire
tick stolen and will not account the tick on user/system/idle,
causing /proc/stats to show invalid data.
The fix is to change steal_account_process_tick() to accumulate
the stolen time and only account it once it's worth a jiffy.
(Thanks to Frederic Weisbecker for suggestions to fix a bug in my
first version of the patch.)
Signed-off-by: Chris Friesen <chris.friesen@windriver.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@vger.kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/56DBBDB8.40305@mail.usask.ca
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Stephane Eranian [Thu, 3 Mar 2016 19:50:40 +0000 (20:50 +0100)]
perf/x86/intel: Add definition for PT PMI bit
[ Upstream commit
5690ae28e472d25e330ad0c637a5cea3fc39fb32 ]
This patch adds a definition for GLOBAL_OVFL_STATUS bit 55
which is used with the Processor Trace (PT) feature.
Signed-off-by: Stephane Eranian <eranian@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: adrian.hunter@intel.com
Cc: kan.liang@intel.com
Cc: namhyung@kernel.org
Link: http://lkml.kernel.org/r/1457034642-21837-2-git-send-email-eranian@google.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andi Kleen [Sun, 10 May 2015 19:22:41 +0000 (12:22 -0700)]
x86: Add new MSRs and MSR bits used for Intel Skylake PMU support
[ Upstream commit
b83ff1c8617aac03a1cf807aafa848fe0f0908f2 ]
Add new MSRs (LBR_INFO) and some new MSR bits used by the Intel Skylake
PMU driver.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: eranian@google.com
Link: http://lkml.kernel.org/r/1431285767-27027-4-git-send-email-andi@firstfloor.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Radim Krčmář [Wed, 2 Mar 2016 21:56:38 +0000 (22:56 +0100)]
KVM: i8254: change PIT discard tick policy
[ Upstream commit
7dd0fdff145c5be7146d0ac06732ae3613412ac1 ]
Discard policy uses ack_notifiers to prevent injection of PIT interrupts
before EOI from the last one.
This patch changes the policy to always try to deliver the interrupt,
which makes a difference when its vector is in ISR.
Old implementation would drop the interrupt, but proposed one injects to
IRR, like real hardware would.
The old policy breaks legacy NMI watchdogs, where PIT is used through
virtual wire (LVT0): PIT never sends an interrupt before receiving EOI,
thus a guest deadlock with disabled interrupts will stop NMIs.
Note that NMI doesn't do EOI, so PIT also had to send a normal interrupt
through IOAPIC. (KVM's PIT is deeply rotten and luckily not used much
in modern systems.)
Even though there is a chance of regressions, I think we can fix the
LVT0 NMI bug without introducing a new tick policy.
Cc: <stable@vger.kernel.org>
Reported-by: Yuki Shibuya <shibuya.yk@ncos.nec.co.jp>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Oliver Neukum [Wed, 17 Feb 2016 10:52:43 +0000 (11:52 +0100)]
usb: hub: fix a typo in hub_port_init() leading to wrong logic
[ Upstream commit
0d5ce778c43bf888328231bcdce05d5c860655aa ]
A typo of j for i led to a logic bug. To rule out future
confusion, the variable names are made meaningful.
Signed-off-by: Oliver Neukum <ONeukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vinayak Menon [Mon, 22 Feb 2016 13:45:44 +0000 (19:15 +0530)]
of: alloc anywhere from memblock if range not specified
[ Upstream commit
e53b50c0cbe392c946807abf7d07615a3c588642 ]
early_init_dt_alloc_reserved_memory_arch passes end as 0 to
__memblock_alloc_base, when limits are not specified. But
__memblock_alloc_base takes end value of 0 as MEMBLOCK_ALLOC_ACCESSIBLE
and limits the end to memblock.current_limit. This results in regions
never being placed in HIGHMEM area, for e.g. CMA.
Let __memblock_alloc_base allocate from anywhere in memory if limits are
not specified.
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:18:20 +0000 (21:18 -0800)]
mtip32xx: Handle FTL rebuild failure state during device initialization
[ Upstream commit
aae4a033868c496adae86fc6f9c3e0c405bbf360 ]
Allow device initialization to finish gracefully when it is in
FTL rebuild failure state. Also, recover device out of this state
after successfully secure erasing it.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Vignesh Gunasekaran <vgunasekaran@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Mon, 11 May 2015 22:50:50 +0000 (15:50 -0700)]
mtip32xx: fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT
[ Upstream commit
ee04bed690cb49a49512a641405bac42d13c2b2a ]
Fix incorrectly setting MTIP_DDF_SEC_LOCK_BIT
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:18:10 +0000 (21:18 -0800)]
mtip32xx: Handle safe removal during IO
[ Upstream commit
51c6570eb922146470c2fe660c34585414679bd6 ]
Flush inflight IOs using fsync_bdev() when the device is safely
removed. Also, block further IOs in device open function.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Rajesh Kumar Sambandam <rsambandam@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Mon, 11 May 2015 22:53:18 +0000 (15:53 -0700)]
mtip32xx: fix crash on surprise removal of the drive
[ Upstream commit
2132a544727eb17f76bfef8b550a016a41c38821 ]
pci and block layers have changed a lot compared to when SRSI support was added.
Given the current state of pci and block layers, this driver do not have to do
any specific handling.
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Mon, 11 May 2015 22:48:00 +0000 (15:48 -0700)]
mtip32xx: fix rmmod issue
[ Upstream commit
02b48265e7437bfe153af16337b14ee74f00905f ]
put_disk() need to be called after del_gendisk() to free the disk object structure.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:17:32 +0000 (21:17 -0800)]
mtip32xx: Avoid issuing standby immediate cmd during FTL rebuild
[ Upstream commit
d8a18d2d8f5de55666c6011ed175939d22c8e3d8 ]
Prevent standby immediate command from being issued in remove,
suspend and shutdown paths, while drive is in FTL rebuild process.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Vignesh Gunasekaran <vgunasekaran@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Asai Thambi SP [Thu, 25 Feb 2016 05:16:38 +0000 (21:16 -0800)]
mtip32xx: Print exact time when an internal command is interrupted
[ Upstream commit
5b7e0a8ac85e2dfd83830dc9e0b3554d153a37e3 ]
Print exact time when an internal command is interrupted.
Signed-off-by: Selvan Mani <smani@micron.com>
Signed-off-by: Rajesh Kumar Sambandam <rsambandam@micron.com>
Signed-off-by: Asai Thambi S P <asamymuthupa@micron.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Nikolay Borisov [Thu, 3 Mar 2016 09:54:57 +0000 (10:54 +0100)]
quota: Fix possible GPF due to uninitialised pointers
[ Upstream commit
ab73ef46398e2c0159f3a71de834586422d2a44a ]
When dqget() in __dquot_initialize() fails e.g. due to IO error,
__dquot_initialize() will pass an array of uninitialized pointers to
dqput_all() and thus can lead to deference of random data. Fix the
problem by properly initializing the array.
CC: stable@vger.kernel.org
Signed-off-by: Nikolay Borisov <kernel@kyup.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Mateusz Guzik [Tue, 1 Mar 2016 22:51:09 +0000 (09:51 +1100)]
xfs: fix two memory leaks in xfs_attr_list.c error paths
[ Upstream commit
2e83b79b2d6c78bf1b4aa227938a214dcbddc83f ]
This plugs 2 trivial leaks in xfs_attr_shortform_list and
xfs_attr3_leaf_list_int.
Signed-off-by: Mateusz Guzik <mguzik@redhat.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
J. Bruce Fields [Tue, 1 Mar 2016 01:21:21 +0000 (20:21 -0500)]
nfsd4: fix bad bounds checking
[ Upstream commit
4aed9c46afb80164401143aa0fdcfe3798baa9d5 ]
A number of spots in the xdr decoding follow a pattern like
n = be32_to_cpup(p++);
READ_BUF(n + 4);
where n is a u32. The only bounds checking is done in READ_BUF itself,
but since it's checking (n + 4), it won't catch cases where n is very
large, (u32)(-4) or higher. I'm not sure exactly what the consequences
are, but we've seen crashes soon after.
Instead, just break these up into two READ_BUF()s.
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael S. Tsirkin [Sun, 28 Feb 2016 15:44:09 +0000 (17:44 +0200)]
watchdog: rc32434_wdt: fix ioctl error handling
[ Upstream commit
10e7ac22cdd4d211cef99afcb9371b70cb175be6 ]
Calling return copy_to_user(...) in an ioctl will not do the right thing
if there's a pagefault: copy_to_user returns the number of bytes not
copied in this case.
Fix up watchdog/rc32434_wdt to do
return copy_to_user(...)) ? -EFAULT : 0;
instead.
Cc: stable@vger.kernel.org
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans de Goede [Sun, 7 Feb 2016 11:24:29 +0000 (09:24 -0200)]
[media] bttv: Width must be a multiple of 16 when capturing planar formats
[ Upstream commit
5c915c68763889f0183a1cc61c84bb228b60124a ]
On my bttv card "Hauppauge WinTV [card=10]" capturing in YV12 fmt at max
size results in a solid green rectangle being captured (all colors 0 in
YUV).
This turns out to be caused by max-width (924) not being a multiple of 16.
We've likely never hit this problem before since normally xawtv / tvtime,
etc. will prefer packed pixel formats. But when using a video card which
is using xf86-video-modesetting + glamor, only planar XVideo fmts are
available, and xawtv will chose a matching capture format to avoid needing
to do conversion, triggering the solid green window problem.
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bart Van Assche [Thu, 11 Feb 2016 19:03:09 +0000 (11:03 -0800)]
IB/srpt: Simplify srpt_handle_tsk_mgmt()
[ Upstream commit
51093254bf879bc9ce96590400a87897c7498463 ]
Let the target core check task existence instead of the SRP target
driver. Additionally, let the target core check the validity of the
task management request instead of the ib_srpt driver.
This patch fixes the following kernel crash:
BUG: unable to handle kernel NULL pointer dereference at
0000000000000001
IP: [<
ffffffffa0565f37>] srpt_handle_new_iu+0x6d7/0x790 [ib_srpt]
Oops: 0002 [#1] SMP
Call Trace:
[<
ffffffffa05660ce>] srpt_process_completion+0xde/0x570 [ib_srpt]
[<
ffffffffa056669f>] srpt_compl_thread+0x13f/0x160 [ib_srpt]
[<
ffffffff8109726f>] kthread+0xcf/0xe0
[<
ffffffff81613cfc>] ret_from_fork+0x7c/0xb0
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Fixes: 3e4f574857ee ("ib_srpt: Convert TMR path to target_submit_tmr")
Tested-by: Alex Estrin <alex.estrin@intel.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Sagi Grimberg <sagig@mellanox.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Russell King [Tue, 26 Jan 2016 13:41:04 +0000 (13:41 +0000)]
mmc: sdhci: fix data timeout (part 2)
[ Upstream commit
7f05538af71c7d30b5fc821cbe9f318edc645961 ]
The calculation for the timeout based on the number of card clocks is
incorrect. The calculation assumed:
timeout in microseconds = clock cycles / clock in Hz
which is clearly a several orders of magnitude wrong. Fix this by
multiplying the clock cycles by
1000000 prior to dividing by the Hz
based clock. Also, as per part 1, ensure that the division rounds
up.
As this needs 64-bit math via do_div(), avoid it if the clock cycles
is zero.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.15+
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Russell King [Tue, 26 Jan 2016 13:40:58 +0000 (13:40 +0000)]
mmc: sdhci: fix data timeout (part 1)
[ Upstream commit
fafcfda9e78cae8796d1799f14e6457790797555 ]
The data timeout gives the minimum amount of time that should be
waited before timing out if no data is received from the card.
Simply dividing the nanosecond part by 1000 does not give this
required guarantee, since such a division rounds down. Use
DIV_ROUND_UP() to give the desired timeout.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v3.15+
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Sun, 28 Feb 2016 08:04:06 +0000 (11:04 +0300)]
Bluetooth: btusb: Add a new AR3012 ID 04ca:3014
[ Upstream commit
81d90442eac779938217c3444b240aa51fd3db47 ]
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=03 Dev#= 5 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=04ca ProdID=3014 Rev=00.02
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1546694
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Tom Lendacky [Thu, 25 Feb 2016 22:48:13 +0000 (16:48 -0600)]
crypto: ccp - memset request context to zero during import
[ Upstream commit
ce0ae266feaf35930394bd770c69778e4ef03ba9 ]
Since a crypto_ahash_import() can be called against a request context
that has not had a crypto_ahash_init() performed, the request context
needs to be cleared to insure there is no random data present. If not,
the random data can result in a kernel oops during crypto_ahash_update().
Cc: <stable@vger.kernel.org> # 3.14.x-
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jes Sorensen [Tue, 16 Feb 2016 21:44:24 +0000 (16:44 -0500)]
md/raid5: Compare apples to apples (or sectors to sectors)
[ Upstream commit
e7597e69dec59b65c5525db1626b9d34afdfa678 ]
'max_discard_sectors' is in sectors, while 'stripe' is in bytes.
This fixes the problem where DISCARD would get disabled on some larger
RAID5 configurations (6 or more drives in my testing), while it worked
as expected with smaller configurations.
Fixes: 620125f2bf8 ("MD: raid5 trim support")
Cc: stable@vger.kernel.org v3.7+
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Bjorn Helgaas [Thu, 25 Feb 2016 20:35:57 +0000 (14:35 -0600)]
PCI: Disable IO/MEM decoding for devices with non-compliant BARs
[ Upstream commit
b84106b4e2290c081cdab521fa832596cdfea246 ]
The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.
Some non-spec-compliant devices put registers other than BARs where the
BARs should be. When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.
Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Andi Kleen <ak@linux.intel.com>
CC: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Yijing Wang [Thu, 21 May 2015 07:05:02 +0000 (15:05 +0800)]
PCI: Add dev->has_secondary_link to track downstream PCIe links
[ Upstream commit
d0751b98dfa391f862e02dc36a233a54615e3f1d ]
A PCIe Port is an interface to a Link. A Root Port is a PCI-PCI bridge in
a Root Complex and has a Link on its secondary (downstream) side. For
other Ports, the Link may be on either the upstream (closer to the Root
Complex) or downstream side of the Port.
The usual topology has a Root Port connected to an Upstream Port. We
previously assumed this was the only possible topology, and that a
Downstream Port's Link was always on its downstream side, like this:
+---------------------+
+------+ | Downstream |
| Root | | Upstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
But systems do exist (see URL below) where the Root Port is connected to a
Downstream Port. In this case, a Downstream Port's Link may be on either
the upstream or downstream side:
+---------------------+
+------+ | Upstream |
| Root | | Downstream Port +--Link--
| Port +--Link--+ Port |
+------+ | Downstream |
| Port +--Link--
+---------------------+
We can't use the Port type to determine which side the Link is on, so add a
bit in struct pci_dev to keep track.
A Root Port's Link is always on the Port's secondary side. A component
(Endpoint or Port) on the other end of the Link obviously has the Link on
its upstream side. If that component is a Port, it is part of a Switch or
a Bridge. A Bridge has a PCI or PCI-X bus on its secondary side, not a
Link. The internal bus of a Switch connects the Port to another Port whose
Link is on the downstream side.
[bhelgaas: changelog, comment, cache "type", use if/else]
Link: http://lkml.kernel.org/r/54EB81B2.4050904@pobox.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94361
Suggested-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jiang Liu [Mon, 27 Oct 2014 05:21:42 +0000 (13:21 +0800)]
x86, irq: Keep balance of IOAPIC pin reference count
[ Upstream commit
cffe0a2b5a34c95a4dadc9ec7132690a5b0f6687 ]
To keep balance of IOAPIC pin reference count, we need to protect
pirq_enable_irq(), acpi_pci_irq_enable() and intel_mid_pci_irq_enable()
from reentrance. There are two cases which will cause reentrance.
The first case is caused by suspend/hibernation. If pcibios_disable_irq
is called during suspending/hibernating, we don't release the assigned
IRQ number, otherwise it may break the suspend/hibernation. So late when
pcibios_enable_irq is called during resume, we shouldn't allocate IRQ
number again.
The second case is that function acpi_pci_irq_enable() may be called
twice for PCI devices present at boot time as below:
1) pci_acpi_init()
--> acpi_pci_irq_enable() if pci_routeirq is true
2) pci_enable_device()
--> pcibios_enable_device()
--> acpi_pci_irq_enable()
We can't kill kernel parameter pci_routeirq yet because it's still
needed for debugging purpose.
So flag irq_managed is introduced to track whether IRQ number is
assigned by OS and to protect pirq_enable_irq(), acpi_pci_irq_enable()
and intel_mid_pci_irq_enable() from reentrance.
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 <lenb@kernel.org>
Link: http://lkml.kernel.org/r/1414387308-27148-13-git-send-email-jiang.liu@linux.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Aaro Koskinen [Sat, 20 Feb 2016 20:27:48 +0000 (22:27 +0200)]
mtd: onenand: fix deadlock in onenand_block_markbad
[ Upstream commit
5e64c29e98bfbba1b527b0a164f9493f3db9e8cb ]
Commit
5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
incorrectly changed onenand_block_markbad() to call mtd_block_markbad
instead of onenand_chip's block_markbad function. As a result the function
will now recurse and deadlock. Fix by reverting the change.
Fixes: 5942ddbc500d ("mtd: introduce mtd_block_markbad interface")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Acked-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Raghava Aditya Renukunta [Wed, 3 Feb 2016 23:06:02 +0000 (15:06 -0800)]
aacraid: Fix memory leak in aac_fib_map_free
[ Upstream commit
f88fa79a61726ce9434df9b4aede36961f709f17 ]
aac_fib_map_free() calls pci_free_consistent() without checking that
dev->hw_fib_va is not NULL and dev->max_fib_size is not zero.If they are
indeed NULL/0, this will result in a hang as pci_free_consistent() will
attempt to invalidate cache for the entire 64-bit address space
(which would take a very long time).
Fixed by adding a check to make sure that dev->hw_fib_va and
dev->max_fib_size are not NULL and 0 respectively.
Fixes: 9ad5204d6 - "[SCSI]aacraid: incorrect dma mapping mask during blinked recover or user initiated reset"
Cc: stable@vger.kernel.org
Signed-off-by: Raghava Aditya Renukunta <raghavaaditya.renukunta@pmcs.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Tue, 9 Feb 2016 21:49:11 +0000 (00:49 +0300)]
Bluetooth: Add new AR3012 ID 0489:e095
[ Upstream commit
28c971d82fb58ef7cba22e5308be6d2d2590473d ]
T: Bus=01 Lev=01 Prnt=01 Port=04 Cnt=02 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=0489 ProdID=e095 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
This device requires ar3k/AthrBT_0x31010100.dfu and
ar3k/ramps_0x31010100_40.dfu firmware files that are not in
linux-firmware yet.
BugLink: https://bugs.launchpad.net/bugs/1542944
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Dmitry Tunin [Wed, 10 Feb 2016 12:33:17 +0000 (15:33 +0300)]
Bluetooth: btusb: Add new AR3012 ID 13d3:3395
[ Upstream commit
609574eb46335cfac1421a07c0505627cbbab1f0 ]
T: Bus=03 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=13d3 ProdID=3395 Rev=00.01
C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
BugLink: https://bugs.launchpad.net/bugs/1542564
Reported-and-tested-by: Christopher Simerly <kilikopela29@gmail.com>
Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andi Kleen [Wed, 17 Feb 2016 22:44:55 +0000 (14:44 -0800)]
perf tools: Dont stop PMU parsing on alias parse error
[ Upstream commit
940db6dcd3f4659303fdf6befe7416adc4d24118 ]
When an error happens during alias parsing currently the complete
parsing of all attributes of the PMU is stopped. This is breaks old perf
on a newer kernel that may have not-yet-know alias attributes (such as
.scale or .per-pkg).
Continue when some attribute is unparseable.
This is IMHO a stable candidate and should be backported to older
versions to avoid problems with newer kernels.
v2: Print warnings when something goes wrong.
v3: Change warning to debug output
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: stable@vger.kernel.org # v3.6+
Link: http://lkml.kernel.org/r/1455749095-18358-1-git-send-email-andi@firstfloor.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Eryu Guan [Sun, 21 Feb 2016 23:38:44 +0000 (18:38 -0500)]
ext4: iterate over buffer heads correctly in move_extent_per_page()
[ Upstream commit
87f9a031af48defee9f34c6aaf06d6f1988c244d ]
In commit
bcff24887d00 ("ext4: don't read blocks from disk after extents
being swapped") bh is not updated correctly in the for loop and wrong
data has been written to disk. generic/324 catches this on sub-page
block size ext4.
Fixes: bcff24887d00 ("ext4: don't read blocks from disk after extentsbeing swapped")
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans de Goede [Sun, 14 Feb 2016 19:51:37 +0000 (17:51 -0200)]
[media] saa7134: Fix bytesperline not being set correctly for planar formats
[ Upstream commit
3e71da19f9dc22e39a755d6ae9678661abb66adc ]
bytesperline should be the bytesperline for the first plane for planar
formats, not that of all planes combined.
This fixes a crash in xawtv caused by the wrong bpl.
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1305389
Reported-and-tested-by: Stas Sergeev <stsp@list.ru>
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hans Verkuil [Wed, 10 Feb 2016 11:32:25 +0000 (09:32 -0200)]
[media] adv7511: TX_EDID_PRESENT is still 1 after a disconnect
[ Upstream commit
b339a72e04a62f0b1882c43492fc712f1176b3e6 ]
The V4L2_CID_TX_EDID_PRESENT control reports if an EDID is present.
The adv7511 however still reported the EDID present after disconnecting
the HDMI cable. Fix the logic regarding this control. And when the EDID
is disconnected also call ADV7511_EDID_DETECT to notify the bridge driver.
This was also missing.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Cc: <stable@vger.kernel.org> # for v3.12 and up
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Julia Lawall [Wed, 17 Feb 2016 23:16:14 +0000 (00:16 +0100)]
scripts/coccinelle: modernize &
[ Upstream commit
1b669e713f277a4d4b3cec84e13d16544ac8286d ]
& is no longer allowed in column 0, since Coccinelle 1.0.4.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Tested-by: Nishanth Menon <nm@ti.com>
Cc: stable@vger.kernel.org
Signed-off-by: Michal Marek <mmarek@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Romain Perier [Sun, 23 Aug 2015 09:32:37 +0000 (11:32 +0200)]
clk: rockchip: Add pclk_peri to critical clocks on RK3066/RK3188
[ Upstream commit
3bba75a2ec32bd5fa7024a4de3b8cf9ee113a76a ]
Now that the rockchip clock subsystem does clock gating with GPIO banks,
these are no longer enabled once during probe and no longer stay enabled
for eternity. When all these clocks are disabled, the parent clock pclk_peri
might be disabled too, as no other child claims it. So, we need to add pclk_peri
to the critical clocks.
Signed-off-by: Romain Perier <romain.perier@gmail.com>
Tested-by: Michael Niewoehner <linux@mniewoehner.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Michael Niewoehner [Tue, 25 Aug 2015 20:22:07 +0000 (22:22 +0200)]
clk: rockchip: add pclk_cpu to the list of rk3188 critical clocks
[ Upstream commit
1166160ab531198f7abc773992c0e04d0f9b7600 ]
pclk_cpu needs to keep running because it is needed for devices like
the act8865 regulator but with the recent gpio clock handling this is
not always the case anymore. So add it to the list of critical clocks.
Signed-off-by: Michael Niewoehner <linux@mniewoehner.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Vasily Kulikov [Wed, 9 Sep 2015 22:36:00 +0000 (15:36 -0700)]
include/linux/poison.h: fix LIST_POISON{1,2} offset
[ Upstream commit
8a5e5e02fc83aaf67053ab53b359af08c6c49aaf ]
Poison pointer values should be small enough to find a room in
non-mmap'able/hardly-mmap'able space. E.g. on x86 "poison pointer space"
is located starting from 0x0. Given unprivileged users cannot mmap
anything below mmap_min_addr, it should be safe to use poison pointers
lower than mmap_min_addr.
The current poison pointer values of LIST_POISON{1,2} might be too big for
mmap_min_addr values equal or less than 1 MB (common case, e.g. Ubuntu
uses only 0x10000). There is little point to use such a big value given
the "poison pointer space" below 1 MB is not yet exhausted. Changing it
to a smaller value solves the problem for small mmap_min_addr setups.
The values are suggested by Solar Designer:
http://www.openwall.com/lists/oss-security/2015/05/02/6
Signed-off-by: Vasily Kulikov <segoon@openwall.com>
Cc: Solar Designer <solar@openwall.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Howells [Tue, 24 Nov 2015 21:36:31 +0000 (21:36 +0000)]
KEYS: Fix handling of stored error in a negatively instantiated user key
[ Upstream commit
096fe9eaea40a17e125569f9e657e34cdb6d73bd ]
If a user key gets negatively instantiated, an error code is cached in the
payload area. A negatively instantiated key may be then be positively
instantiated by updating it with valid data. However, the ->update key
type method must be aware that the error code may be there.
The following may be used to trigger the bug in the user key type:
keyctl request2 user user "" @u
keyctl add user user "a" @u
which manifests itself as:
BUG: unable to handle kernel paging request at
00000000ffffff8a
IP: [<
ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
PGD
7cc30067 PUD 0
Oops: 0002 [#1] SMP
Modules linked in:
CPU: 3 PID: 2644 Comm: a.out Not tainted 4.3.0+ #49
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task:
ffff88003ddea700 ti:
ffff88003dd88000 task.ti:
ffff88003dd88000
RIP: 0010:[<
ffffffff810a376f>] [<
ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280
[<
ffffffff810a376f>] __call_rcu.constprop.76+0x1f/0x280 kernel/rcu/tree.c:3046
RSP: 0018:
ffff88003dd8bdb0 EFLAGS:
00010246
RAX:
00000000ffffff82 RBX:
0000000000000000 RCX:
0000000000000001
RDX:
ffffffff81e3fe40 RSI:
0000000000000000 RDI:
00000000ffffff82
RBP:
ffff88003dd8bde0 R08:
ffff88007d2d2da0 R09:
0000000000000000
R10:
0000000000000000 R11:
ffff88003e8073c0 R12:
00000000ffffff82
R13:
ffff88003dd8be68 R14:
ffff88007d027600 R15:
ffff88003ddea700
FS:
0000000000b92880(0063) GS:
ffff88007fd00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
CR2:
00000000ffffff8a CR3:
000000007cc5f000 CR4:
00000000000006e0
Stack:
ffff88003dd8bdf0 ffffffff81160a8a 0000000000000000 00000000ffffff82
ffff88003dd8be68 ffff88007d027600 ffff88003dd8bdf0 ffffffff810a39e5
ffff88003dd8be20 ffffffff812a31ab ffff88007d027600 ffff88007d027620
Call Trace:
[<
ffffffff810a39e5>] kfree_call_rcu+0x15/0x20 kernel/rcu/tree.c:3136
[<
ffffffff812a31ab>] user_update+0x8b/0xb0 security/keys/user_defined.c:129
[< inline >] __key_update security/keys/key.c:730
[<
ffffffff8129e5c1>] key_create_or_update+0x291/0x440 security/keys/key.c:908
[< inline >] SYSC_add_key security/keys/keyctl.c:125
[<
ffffffff8129fc21>] SyS_add_key+0x101/0x1e0 security/keys/keyctl.c:60
[<
ffffffff8185f617>] entry_SYSCALL_64_fastpath+0x12/0x6a arch/x86/entry/entry_64.S:185
Note the error code (-ENOKEY) in EDX.
A similar bug can be tripped by:
keyctl request2 trusted user "" @u
keyctl add trusted user "a" @u
This should also affect encrypted keys - but that has to be correctly
parameterised or it will fail with EINVAL before getting to the bit that
will crashes.
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Andrew Honig [Wed, 18 Nov 2015 22:50:23 +0000 (14:50 -0800)]
KVM: x86: Reload pit counters for all channels when restoring state
[ Upstream commit
0185604c2d82c560dab2f2933a18f797e74ab5a8 ]
Currently if userspace restores the pit counters with a count of 0
on channels 1 or 2 and the guest attempts to read the count on those
channels, then KVM will perform a mod of 0 and crash. This will ensure
that 0 values are converted to 65536 as per the spec.
This is CVE-2015-7513.
Signed-off-by: Andy Honig <ahonig@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Linus Torvalds [Mon, 7 Mar 2016 21:15:09 +0000 (13:15 -0800)]
Revert "drm/radeon: call hpd_irq_event on resume"
[ Upstream commit
256faedcfd646161477d47a1a78c32a562d2e845 ]
This reverts commit
dbb17a21c131eca94eb31136eee9a7fe5aff00d9.
It turns out that commit can cause problems for systems with multiple
GPUs, and causes X to hang on at least a HP Pavilion dv7 with hybrid
graphics.
This got noticed originally in 4.4.4, where this patch had already
gotten back-ported, but 4.5-rc7 was verified to have the same problem.
Alexander Deucher says:
"It looks like you have a muxed system so I suspect what's happening is
that one of the display is being reported as connected for both the
IGP and the dGPU and then the desktop environment gets confused or
there some sort problem in the detect functions since the mux is not
switched to the dGPU. I don't see an easy fix unless Dave has any
ideas. I'd say just revert for now"
Reported-by: Jörg-Volker Peetz <jvpeetz@web.de>
Acked-by: Alexander Deucher <Alexander.Deucher@amd.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: stable@kernel.org # wherever dbb17a21c131 got back-ported
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Rusty Russell [Wed, 3 Feb 2016 06:25:26 +0000 (16:55 +1030)]
modules: fix longstanding /proc/kallsyms vs module insertion race.
[ Upstream commit
8244062ef1e54502ef55f54cced659913f244c3e ]
For CONFIG_KALLSYMS, we keep two symbol tables and two string tables.
There's one full copy, marked SHF_ALLOC and laid out at the end of the
module's init section. There's also a cut-down version that only
contains core symbols and strings, and lives in the module's core
section.
After module init (and before we free the module memory), we switch
the mod->symtab, mod->num_symtab and mod->strtab to point to the core
versions. We do this under the module_mutex.
However, kallsyms doesn't take the module_mutex: it uses
preempt_disable() and rcu tricks to walk through the modules, because
it's used in the oops path. It's also used in /proc/kallsyms.
There's nothing atomic about the change of these variables, so we can
get the old (larger!) num_symtab and the new symtab pointer; in fact
this is what I saw when trying to reproduce.
By grouping these variables together, we can use a
carefully-dereferenced pointer to ensure we always get one or the
other (the free of the module init section is already done in an RCU
callback, so that's safe). We allocate the init one at the end of the
module init section, and keep the core one inside the struct module
itself (it could also have been allocated at the end of the module
core, but that's probably overkill).
Reported-by: Weilong Chen <chenweilong@huawei.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=111541
Cc: stable@kernel.org
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Qu Wenruo [Fri, 22 Jan 2016 01:28:38 +0000 (09:28 +0800)]
btrfs: async-thread: Fix a use-after-free error for trace
[ Upstream commit
0a95b851370b84a4b9d92ee6d1fa0926901d0454 ]
Parameter of trace_btrfs_work_queued() can be freed in its workqueue.
So no one use use that pointer after queue_work().
Fix the user-after-free bug by move the trace line before queue_work().
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jann Horn [Wed, 20 Jan 2016 23:00:01 +0000 (15:00 -0800)]
security: let security modules use PTRACE_MODE_* with bitmasks
[ Upstream commit
3dfb7d8cdbc7ea0c2970450e60818bb3eefbad69 ]
It looks like smack and yama weren't aware that the ptrace mode
can have flags ORed into it - PTRACE_MODE_NOAUDIT until now, but
only for /proc/$pid/stat, and with the PTRACE_MODE_*CREDS patch,
all modes have flags ORed into them.
Signed-off-by: Jann Horn <jann@thejh.net>
Acked-by: Kees Cook <keescook@chromium.org>
Acked-by: Casey Schaufler <casey@schaufler-ca.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Simon Guinot [Wed, 9 Sep 2015 22:15:18 +0000 (00:15 +0200)]
kernel/resource.c: fix muxed resource handling in __request_region()
[ Upstream commit
59ceeaaf355fa0fb16558ef7c24413c804932ada ]
In __request_region, if a conflict with a BUSY and MUXED resource is
detected, then the caller goes to sleep and waits for the resource to be
released. A pointer on the conflicting resource is kept. At wake-up
this pointer is used as a parent to retry to request the region.
A first problem is that this pointer might well be invalid (if for
example the conflicting resource have already been freed). Another
problem is that the next call to __request_region() fails to detect a
remaining conflict. The previously conflicting resource is passed as a
parameter and __request_region() will look for a conflict among the
children of this resource and not at the resource itself. It is likely
to succeed anyway, even if there is still a conflict.
Instead, the parent of the conflicting resource should be passed to
__request_region().
As a fix, this patch doesn't update the parent resource pointer in the
case we have to wait for a muxed region right after.
Reported-and-tested-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Simon Guinot <simon.guinot@sequanux.org>
Tested-by: Vincent Donnefort <vdonnefort@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Laura Abbott [Mon, 5 Oct 2015 22:33:29 +0000 (19:33 -0300)]
[media] si2157: return -EINVAL if firmware blob is too big
[ Upstream commit
d2cc2f0b35465951eaaf0387fd55e29835ed7ea6 ]
A previous patch added a check if the firmware is too big, but it didn't
set the return error code with the right value.
[mchehab@osg.samsung.com: I ended by applying a v1 of Laura's patch, without
the proper return code. This patch contains the difference between v2 and v1 of
the Laura's "si2157: Bounds check firmware" patch]
Cc: stable@kernel.org
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Reviewed-by: Olli Salonen <olli.salonen@iki.fi>
Tested-by: Olli Salonen <olli.salonen@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Laura Abbott [Wed, 30 Sep 2015 00:10:10 +0000 (21:10 -0300)]
[media] si2157: Bounds check firmware
[ Upstream commit
a828d72df216c36e9c40b6c24dc4b17b6f7b5a76 ]
When reading the firmware and sending commands, the length
must be bounds checked to avoid overrunning the size of the command
buffer and smashing the stack if the firmware is not in the
expected format. Add the proper check.
Cc: stable@kernel.org
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Sebastian Andrzej Siewior [Fri, 15 Jan 2016 13:37:15 +0000 (14:37 +0100)]
btrfs: initialize the seq counter in struct btrfs_device
[ Upstream commit
546bed631203344611f42b2af1d224d2eedb4e6b ]
I managed to trigger this:
| INFO: trying to register non-static key.
| the code is fine but needs lockdep annotation.
| turning off the locking correctness validator.
| CPU: 1 PID: 781 Comm: systemd-gpt-aut Not tainted 4.4.0-rt2+ #14
| Hardware name: ARM-Versatile Express
| [<
80307cec>] (dump_stack)
| [<
80070e98>] (__lock_acquire)
| [<
8007184c>] (lock_acquire)
| [<
80287800>] (btrfs_ioctl)
| [<
8012a8d4>] (do_vfs_ioctl)
| [<
8012ac14>] (SyS_ioctl)
so I think that btrfs_device_data_ordered_init() is not invoked behind
a macro somewhere.
Fixes: 7cc8e58d53cd ("Btrfs: fix unprotected device's variants on 32bits machine")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Filipe Manana [Tue, 5 Jan 2016 16:24:05 +0000 (16:24 +0000)]
Btrfs: fix transaction handle leak on failure to create hard link
[ Upstream commit
271dba4521aed0c37c063548f876b49f5cd64b2e ]
If we failed to create a hard link we were not always releasing the
the transaction handle we got before, resulting in a memory leak and
preventing any other tasks from being able to commit the current
transaction.
Fix this by always releasing our transaction handle.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Filipe Manana [Thu, 31 Dec 2015 18:16:29 +0000 (18:16 +0000)]
Btrfs: fix number of transaction units required to create symlink
[ Upstream commit
9269d12b2d57d9e3d13036bb750762d1110d425c ]
We weren't accounting for the insertion of an inline extent item for the
symlink inode nor that we need to update the parent inode item (through
the call to btrfs_add_nondir()). So fix this by including two more
transaction units.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Filipe Manana [Thu, 31 Dec 2015 18:07:59 +0000 (18:07 +0000)]
Btrfs: send, don't BUG_ON() when an empty symlink is found
[ Upstream commit
a879719b8c90e15c9e7fa7266d5e3c0ca962f9df ]
When a symlink is successfully created it always has an inline extent
containing the source path. However if an error happens when creating
the symlink, we can leave in the subvolume's tree a symlink inode without
any such inline extent item - this happens if after btrfs_symlink() calls
btrfs_end_transaction() and before it calls the inode eviction handler
(through the final iput() call), the transaction gets committed and a
crash happens before the eviction handler gets called, or if a snapshot
of the subvolume is made before the eviction handler gets called. Sadly
we can't just avoid this by making btrfs_symlink() call
btrfs_end_transaction() after it calls the eviction handler, because the
later can commit the current transaction before it removes any items from
the subvolume tree (if it encounters ENOSPC errors while reserving space
for removing all the items).
So make send fail more gracefully, with an -EIO error, and print a
message to dmesg/syslog informing that there's an empty symlink inode,
so that the user can delete the empty symlink or do something else
about it.
Reported-by: Stephen R. van den Berg <srb@cuci.nl>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
David Sterba [Sat, 10 Oct 2015 15:59:53 +0000 (17:59 +0200)]
btrfs: statfs: report zero available if metadata are exhausted
[ Upstream commit
ca8a51b3a979d57b082b14eda38602b7f52d81d1 ]
There is one ENOSPC case that's very confusing. There's Available
greater than zero but no file operation succeds (besides removing
files). This happens when the metadata are exhausted and there's no
possibility to allocate another chunk.
In this scenario it's normal that there's still some space in the data
chunk and the calculation in df reflects that in the Avail value.
To at least give some clue about the ENOSPC situation, let statfs report
zero value in Avail, even if there's still data space available.
Current:
/dev/sdb1 4.0G 3.3G 719M 83% /mnt/test
New:
/dev/sdb1 4.0G 3.3G 0 100% /mnt/test
We calculate the remaining metadata space minus global reserve. If this
is (supposedly) smaller than zero, there's no space. But this does not
hold in practice, the exhausted state happens where's still some
positive delta. So we apply some guesswork and compare the delta to a 4M
threshold. (Practically observed delta was 2M.)
We probably cannot calculate the exact threshold value because this
depends on the internal reservations requested by various operations, so
some operations that consume a few metadata will succeed even if the
Avail is zero. But this is better than the other way around.
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Josef Bacik [Thu, 22 Oct 2015 19:05:09 +0000 (15:05 -0400)]
Btrfs: igrab inode in writepage
[ Upstream commit
be7bd730841e69fe8f70120098596f648cd1f3ff ]
We hit this panic on a few of our boxes this week where we have an
ordered_extent with an NULL inode. We do an igrab() of the inode in writepages,
but weren't doing it in writepage which can be called directly from the VM on
dirty pages. If the inode has been unlinked then we could have I_FREEING set
which means igrab() would return NULL and we get this panic. Fix this by trying
to igrab in btrfs_writepage, and if it returns NULL then just redirty the page
and return AOP_WRITEPAGE_ACTIVATE; so the VM knows it wasn't successful. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Anand Jain [Wed, 7 Oct 2015 09:23:23 +0000 (17:23 +0800)]
Btrfs: add missing brelse when superblock checksum fails
[ Upstream commit
b2acdddfad13c38a1e8b927d83c3cf321f63601a ]
Looks like oversight, call brelse() when checksum fails. Further down the
code, in the non error path, we do call brelse() and so we don't see
brelse() in the goto error paths.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Hariprasad S [Fri, 11 Dec 2015 08:29:17 +0000 (13:59 +0530)]
iw_cxgb3: Fix incorrectly returning error on success
[ Upstream commit
67f1aee6f45059fd6b0f5b0ecb2c97ad0451f6b3 ]
The cxgb3_*_send() functions return NET_XMIT_ values, which are
positive integers values. So don't treat positive return values
as an error.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Jason Andryuk [Fri, 12 Feb 2016 23:13:33 +0000 (23:13 +0000)]
lib/ucs2_string: Correct ucs2 -> utf8 conversion
[ Upstream commit
a68075908a37850918ad96b056acc9ac4ce1bd90 ]
The comparisons should be >= since 0x800 and 0x80 require an additional bit
to store.
For the 3 byte case, the existing shift would drop off 2 more bits than
intended.
For the 2 byte case, there should be 5 bits bits in byte 1, and 6 bits in
byte 2.
Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@coreos.com>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Matt Fleming [Mon, 15 Feb 2016 10:34:05 +0000 (10:34 +0000)]
efi: Add pstore variables to the deletion whitelist
[ Upstream commit
e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 ]
Laszlo explains why this is a good idea,
'This is because the pstore filesystem can be backed by UEFI variables,
and (for example) a crash might dump the last kilobytes of the dmesg
into a number of pstore entries, each entry backed by a separate UEFI
variable in the above GUID namespace, and with a variable name
according to the above pattern.
Please see "drivers/firmware/efi/efi-pstore.c".
While this patch series will not prevent the user from deleting those
UEFI variables via the pstore filesystem (i.e., deleting a pstore fs
entry will continue to delete the backing UEFI variable), I think it
would be nice to preserve the possibility for the sysadmin to delete
Linux-created UEFI variables that carry portions of the crash log,
*without* having to mount the pstore filesystem.'
There's also no chance of causing machines to become bricked by
deleting these variables, which is the whole purpose of excluding
things from the whitelist.
Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so
that we don't have to update the string in the future if new variable
name formats are created for crash dump variables.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Peter Jones <pjones@redhat.com>
Tested-by: Peter Jones <pjones@redhat.com>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: "Lee, Chun-Yi" <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Jones [Mon, 8 Feb 2016 19:48:15 +0000 (14:48 -0500)]
efi: Make efivarfs entries immutable by default
[ Upstream commit
ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 ]
"rm -rf" is bricking some peoples' laptops because of variables being
used to store non-reinitializable firmware driver data that's required
to POST the hardware.
These are 100% bugs, and they need to be fixed, but in the mean time it
shouldn't be easy to *accidentally* brick machines.
We have to have delete working, and picking which variables do and don't
work for deletion is quite intractable, so instead make everything
immutable by default (except for a whitelist), and make tools that
aren't quite so broad-spectrum unset the immutable flag.
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Jones [Mon, 8 Feb 2016 19:48:14 +0000 (14:48 -0500)]
efi: Make our variable validation list include the guid
[ Upstream commit
8282f5d9c17fe15a9e658c06e3f343efae1a2a2f ]
All the variables in this list so far are defined to be in the global
namespace in the UEFI spec, so this just further ensures we're
validating the variables we think we are.
Including the guid for entries will become more important in future
patches when we decide whether or not to allow deletion of variables
based on presence in this list.
Signed-off-by: Peter Jones <pjones@redhat.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Peter Jones [Mon, 8 Feb 2016 19:48:13 +0000 (14:48 -0500)]
efi: Do variable name validation tests in utf8
[ Upstream commit
3dcb1f55dfc7631695e69df4a0d589ce5274bd07 ]
Actually translate from ucs2 to utf8 before doing the test, and then
test against our other utf8 data, instead of fudging it.
Signed-off-by: Peter Jones <pjones@redhat.com>
Acked-by: Matthew Garrett <mjg59@coreos.com>
Tested-by: Lee, Chun-Yi <jlee@suse.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
projects / wrapfs-5.10.y.git / log