OSDN Git Service
Guillaume Nault [Fri, 13 Oct 2017 17:22:35 +0000 (19:22 +0200)]
l2tp: check ps->sock before running pppol2tp_session_ioctl()
[ Upstream commit
5903f594935a3841137c86b9d5b75143a5b7121c ]
When pppol2tp_session_ioctl() is called by pppol2tp_tunnel_ioctl(),
the session may be unconnected. That is, it was created by
pppol2tp_session_create() and hasn't been connected with
pppol2tp_connect(). In this case, ps->sock is NULL, so we need to check
for this case in order to avoid dereferencing a NULL pointer.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Tue, 31 Oct 2017 06:08:20 +0000 (23:08 -0700)]
tcp: fix tcp_mtu_probe() vs highest_sack
[ Upstream commit
2b7cda9c35d3b940eb9ce74b30bbd5eb30db493d ]
Based on SNMP values provided by Roman, Yuchung made the observation
that some crashes in tcp_sacktag_walk() might be caused by MTU probing.
Looking at tcp_mtu_probe(), I found that when a new skb was placed
in front of the write queue, we were not updating tcp highest sack.
If one skb is freed because all its content was copied to the new skb
(for MTU probing), then tp->highest_sack could point to a now freed skb.
Bad things would then happen, including infinite loops.
This patch renames tcp_highest_sack_combine() and uses it
from tcp_mtu_probe() to fix the bug.
Note that I also removed one test against tp->sacked_out,
since we want to replace tp->highest_sack regardless of whatever
condition, since keeping a stale pointer to freed skb is a recipe
for disaster.
Fixes:
a47e5a988a57 ("[TCP]: Convert highest_sack to sk_buff to allow direct access")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Reported-by: Roman Gushchin <guro@fb.com>
Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Craig Gallek [Mon, 30 Oct 2017 22:50:11 +0000 (18:50 -0400)]
tun/tap: sanitize TUNSETSNDBUF input
[ Upstream commit
93161922c658c714715686cd0cf69b090cb9bf1d ]
Syzkaller found several variants of the lockup below by setting negative
values with the TUNSETSNDBUF ioctl. This patch adds a sanity check
to both the tun and tap versions of this ioctl.
watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [repro:2389]
Modules linked in:
irq event stamp:
329692056
hardirqs last enabled at (
329692055): [<
ffffffff824b8381>] _raw_spin_unlock_irqrestore+0x31/0x75
hardirqs last disabled at (
329692056): [<
ffffffff824b9e58>] apic_timer_interrupt+0x98/0xb0
softirqs last enabled at (
35659740): [<
ffffffff824bc958>] __do_softirq+0x328/0x48c
softirqs last disabled at (
35659731): [<
ffffffff811c796c>] irq_exit+0xbc/0xd0
CPU: 0 PID: 2389 Comm: repro Not tainted 4.14.0-rc7 #23
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task:
ffff880009452140 task.stack:
ffff880006a20000
RIP: 0010:_raw_spin_lock_irqsave+0x11/0x80
RSP: 0018:
ffff880006a27c50 EFLAGS:
00000282 ORIG_RAX:
ffffffffffffff10
RAX:
ffff880009ac68d0 RBX:
ffff880006a27ce0 RCX:
0000000000000000
RDX:
0000000000000001 RSI:
ffff880006a27ce0 RDI:
ffff880009ac6900
RBP:
ffff880006a27c60 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000001 R11:
000000000063ff00 R12:
ffff880009ac6900
R13:
ffff880006a27cf8 R14:
0000000000000001 R15:
ffff880006a27cf8
FS:
00007f4be4838700(0000) GS:
ffff88000cc00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000020101000 CR3:
0000000009616000 CR4:
00000000000006f0
Call Trace:
prepare_to_wait+0x26/0xc0
sock_alloc_send_pskb+0x14e/0x270
? remove_wait_queue+0x60/0x60
tun_get_user+0x2cc/0x19d0
? __tun_get+0x60/0x1b0
tun_chr_write_iter+0x57/0x86
__vfs_write+0x156/0x1e0
vfs_write+0xf7/0x230
SyS_write+0x57/0xd0
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x7f4be4356df9
RSP: 002b:
00007ffc18101c08 EFLAGS:
00000293 ORIG_RAX:
0000000000000001
RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007f4be4356df9
RDX:
0000000000000046 RSI:
0000000020101000 RDI:
0000000000000005
RBP:
00007ffc18101c40 R08:
0000000000000001 R09:
0000000000000001
R10:
0000000000000001 R11:
0000000000000293 R12:
0000559c75f64780
R13:
00007ffc18101d30 R14:
0000000000000000 R15:
0000000000000000
Fixes:
33dccbb050bb ("tun: Limit amount of queued packets per device")
Fixes:
20d29d7a916a ("net: macvtap driver")
Signed-off-by: Craig Gallek <kraig@google.com>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 12 Sep 2017 10:41:20 +0000 (12:41 +0200)]
ALSA: seq: Cancel pending autoload work at unbinding device
commit
fc27fe7e8deef2f37cba3f2be2d52b6ca5eb9d57 upstream.
ALSA sequencer core has a mechanism to load the enumerated devices
automatically, and it's performed in an off-load work. This seems
causing some race when a sequencer is removed while the pending
autoload work is running. As syzkaller spotted, it may lead to some
use-after-free:
BUG: KASAN: use-after-free in snd_rawmidi_dev_seq_free+0x69/0x70
sound/core/rawmidi.c:1617
Write of size 8 at addr
ffff88006c611d90 by task kworker/2:1/567
CPU: 2 PID: 567 Comm: kworker/2:1 Not tainted 4.13.0+ #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: events autoload_drivers
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0x192/0x22c lib/dump_stack.c:52
print_address_description+0x78/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x230/0x340 mm/kasan/report.c:409
__asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
snd_rawmidi_dev_seq_free+0x69/0x70 sound/core/rawmidi.c:1617
snd_seq_dev_release+0x4f/0x70 sound/core/seq_device.c:192
device_release+0x13f/0x210 drivers/base/core.c:814
kobject_cleanup lib/kobject.c:648 [inline]
kobject_release lib/kobject.c:677 [inline]
kref_put include/linux/kref.h:70 [inline]
kobject_put+0x145/0x240 lib/kobject.c:694
put_device+0x25/0x30 drivers/base/core.c:1799
klist_devices_put+0x36/0x40 drivers/base/bus.c:827
klist_next+0x264/0x4a0 lib/klist.c:403
next_device drivers/base/bus.c:270 [inline]
bus_for_each_dev+0x17e/0x210 drivers/base/bus.c:312
autoload_drivers+0x3b/0x50 sound/core/seq_device.c:117
process_one_work+0x9fb/0x1570 kernel/workqueue.c:2097
worker_thread+0x1e4/0x1350 kernel/workqueue.c:2231
kthread+0x324/0x3f0 kernel/kthread.c:231
ret_from_fork+0x25/0x30 arch/x86/entry/entry_64.S:425
The fix is simply to assure canceling the autoload work at removing
the device.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Sat, 7 Oct 2017 18:07:47 +0000 (11:07 -0700)]
Input: ims-psu - check if CDC union descriptor is sane
commit
ea04efee7635c9120d015dcdeeeb6988130cb67a upstream.
Before trying to use CDC union descriptor, try to validate whether that it
is sane by checking that intf->altsetting->extra is big enough and that
descriptor bLength is not too big and not too small.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Fri, 29 Sep 2017 14:54:24 +0000 (10:54 -0400)]
usb: usbtest: fix NULL pointer dereference
commit
7c80f9e4a588f1925b07134bb2e3689335f6c6d8 upstream.
If the usbtest driver encounters a device with an IN bulk endpoint but
no OUT bulk endpoint, it will try to dereference a NULL pointer
(out->desc.bEndpointAddress). The problem can be solved by adding a
missing test.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Tue, 24 Oct 2017 19:12:13 +0000 (21:12 +0200)]
mac80211: don't compare TKIP TX MIC key in reinstall prevention
commit
cfbb0d90a7abb289edc91833d0905931f8805f12 upstream.
For the reinstall prevention, the code I had added compares the
whole key. It turns out though that iwlwifi firmware doesn't
provide the TKIP TX MIC key as it's not needed in client mode,
and thus the comparison will always return false.
For client mode, thus always zero out the TX MIC key part before
doing the comparison in order to avoid accepting the reinstall
of the key with identical encryption and RX MIC key, but not the
same TX MIC key (since the supplicant provides the real one.)
Fixes:
fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason A. Donenfeld [Tue, 17 Oct 2017 18:32:07 +0000 (20:32 +0200)]
mac80211: use constant time comparison with keys
commit
2bdd713b92a9cade239d3c7d15205a09f556624d upstream.
Otherwise we risk leaking information via timing side channel.
Fixes:
fdf7cb4185b6 ("mac80211: accept key reinstall without changing anything")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Tue, 5 Sep 2017 12:54:54 +0000 (14:54 +0200)]
mac80211: accept key reinstall without changing anything
commit
fdf7cb4185b60c68e1a75e61691c4afdc15dea0e upstream.
When a key is reinstalled we can reset the replay counters
etc. which can lead to nonce reuse and/or replay detection
being impossible, breaking security properties, as described
in the "KRACK attacks".
In particular, CVE-2017-13080 applies to GTK rekeying that
happened in firmware while the host is in D3, with the second
part of the attack being done after the host wakes up. In
this case, the wpa_supplicant mitigation isn't sufficient
since wpa_supplicant doesn't know the GTK material.
In case this happens, simply silently accept the new key
coming from userspace but don't take any action on it since
it's the same key; this keeps the PN replay counters intact.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 15 Nov 2017 16:13:14 +0000 (17:13 +0100)]
Linux 4.4.98
Colin Ian King [Sat, 27 Feb 2016 12:45:26 +0000 (12:45 +0000)]
PKCS#7: fix unitialized boolean 'want'
commit
06aae592425701851e02bb850cb9f4997f0ae163 upstream.
The boolean want is not initialized and hence garbage. The default should
be false (later it is only set to true on tne sinfo->authattrs check).
Found with static analysis using CoverityScan
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Borislav Petkov [Tue, 7 Nov 2017 17:53:07 +0000 (18:53 +0100)]
x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context
commit
a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream.
The warning below says it all:
BUG: using __this_cpu_read() in preemptible [
00000000] code: swapper/0/1
caller is __this_cpu_preempt_check
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4
Call Trace:
dump_stack
check_preemption_disabled
? do_early_param
__this_cpu_preempt_check
arch_perfmon_init
op_nmi_init
? alloc_pci_root_info
oprofile_arch_init
oprofile_init
do_one_initcall
...
These accessors should not have been used in the first place: it is PPro so
no mixed silicon revisions and thus it can simply use boot_cpu_data.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Fix-creation-mandated-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Robert Richter <rric@kernel.org>
Cc: x86@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Richard Schütz [Sun, 29 Oct 2017 12:03:22 +0000 (13:03 +0100)]
can: c_can: don't indicate triple sampling support for D_CAN
commit
fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream.
The D_CAN controller doesn't provide a triple sampling mode, so don't set
the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling
triple sampling is a no-op.
Signed-off-by: Richard Schütz <rschuetz@uni-koblenz.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gerhard Bertelsmann [Mon, 6 Nov 2017 17:16:56 +0000 (18:16 +0100)]
can: sun4i: handle overrun in RX FIFO
commit
4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream.
SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not
drained fast enough (overrun) it's getting mangled. Already received
frames are dropped - the data can't be restored.
Signed-off-by: Gerhard Bertelsmann <info@gerhard-bertelsmann.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilya Dryomov [Mon, 6 Nov 2017 10:33:36 +0000 (11:33 +0100)]
rbd: use GFP_NOIO for parent stat and data requests
commit
1e37f2f84680fa7f8394fd444b6928e334495ccc upstream.
rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on
the writeback path for cloned images -- we attempt a stat on the parent
object to see if it exists and potentially read it in to call copyup.
GFP_NOIO should be used instead of GFP_KERNEL here.
Link: http://tracker.ceph.com/issues/22014
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Reviewed-by: David Disseldorp <ddiss@suse.de>
[idryomov@gmail.com: backport to < 4.9: context]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sinclair Yeh [Wed, 1 Nov 2017 17:47:05 +0000 (10:47 -0700)]
drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue
commit
cef75036c40408ba3bc308bcb00a3d440da713fc upstream.
This is an extension of Commit
7c20d213dd3c ("drm/vmwgfx: Work
around mode set failure in 2D VMs")
With Wayland desktop and atomic mode set, during the mode setting
process there is a moment when two framebuffer sized surfaces
are being pinned. This was not an issue with Xorg.
Since this only happens during a mode change, there should be no
performance impact by increasing allowable mem_size.
Signed-off-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kai-Heng Feng [Wed, 8 Nov 2017 00:19:24 +0000 (16:19 -0800)]
Input: elan_i2c - add ELAN060C to the ACPI table
commit
cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream.
ELAN060C touchpad uses elan_i2c as its driver. It can be
found on Lenovo ideapad 320-14AST.
BugLink: https://bugs.launchpad.net/bugs/1727544
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oswald Buddenhagen [Sun, 29 Oct 2017 15:27:20 +0000 (16:27 +0100)]
MIPS: AR7: Ensure that serial ports are properly set up
commit
b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream.
Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is
never copied, resulting in a dead port.
Fixes:
154615d55459 ("MIPS: AR7: Use correct UART port type")
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
[jonas.gorski: add Fixes tag]
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Cc: Nicolas Schichan <nschichan@freebox.fr>
Cc: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Cc: linux-mips@linux-mips.org
Cc: linux-serial@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17543/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jonas Gorski [Sun, 29 Oct 2017 15:27:19 +0000 (16:27 +0100)]
MIPS: AR7: Defer registration of GPIO
commit
e6b03ab63b4d270e0249f96536fde632409dc1dc upstream.
When called from prom init code, ar7_gpio_init() will fail as it will
call gpiochip_add() which relies on a working kmalloc() to alloc
the gpio_desc array and kmalloc is not useable yet at prom init time.
Move ar7_gpio_init() to ar7_register_devices() (a device_initcall)
where kmalloc works.
Fixes:
14e85c0e69d5 ("gpio: remove gpio_descs global array")
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@hitachi.com>
Cc: Nicolas Schichan <nschichan@freebox.fr>
Cc: linux-mips@linux-mips.org
Cc: linux-serial@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17542/
Signed-off-by: James Hogan <jhogan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luis R. Rodriguez [Mon, 23 Jan 2017 16:11:07 +0000 (08:11 -0800)]
tools: firmware: check for distro fallback udev cancel rule
commit
afb999cdef69148f366839e74470d8f5375ba5f1 upstream.
Some distributions (Debian, OpenSUSE) have a udev rule in place to cancel
all fallback mechanism uevents immediately. This would obviously
make it hard to test against the fallback mechanism test interface,
so we need to check for this.
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luis R. Rodriguez [Fri, 16 Dec 2016 11:10:35 +0000 (03:10 -0800)]
selftests: firmware: send expected errors to /dev/null
commit
880444e214cfd293a2e8cc4bd3505f7ffa6ce33a upstream.
Error that we expect should not be spilled to stdout.
Without this we get:
./fw_filesystem.sh: line 58: printf: write error: Invalid argument
./fw_filesystem.sh: line 63: printf: write error: No such device
./fw_filesystem.sh: line 69: echo: write error: No such file or directory
./fw_filesystem.sh: filesystem loading works
./fw_filesystem.sh: async filesystem loading works
With it:
./fw_filesystem.sh: filesystem loading works
./fw_filesystem.sh: async filesystem loading works
Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
[AmitP: Dropped the async trigger testing parts from original commit]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Wed, 9 Dec 2015 22:50:29 +0000 (14:50 -0800)]
selftests: firmware: add empty string and async tests
commit
1b1fe542b6f010cf6bc7e1c92805e1c0e133e007 upstream.
Now that we've added a 'trigger_async_request' knob to test the
request_firmware_nowait() API, let's use it. Also add tests for the
empty ("") string, since there have been a couple errors in that
handling already.
Since we now have real ways that the sysfs write might fail, let's add
the appropriate check on the 'echo' lines too.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
[AmitP: Dropped the async trigger testing parts from original commit]
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Brian Norris [Wed, 9 Dec 2015 22:50:25 +0000 (14:50 -0800)]
test: firmware_class: report errors properly on failure
commit
47e0bbb7fa985a0f1b5794a8653fae4f8f49de77 upstream.
request_firmware() failures currently won't get reported at all (the
error code is discarded). What's more, we get confusing messages, like:
# echo -n notafile > /sys/devices/virtual/misc/test_firmware/trigger_request
[ 8280.311856] test_firmware: loading 'notafile'
[ 8280.317042] test_firmware: load of 'notafile' failed: -2
[ 8280.322445] test_firmware: loaded: 0
# echo $?
0
Report the failures via write() errors, and don't say we "loaded"
anything.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Redfearn [Wed, 27 Sep 2017 09:13:25 +0000 (10:13 +0100)]
MIPS: SMP: Fix deadlock & online race
commit
9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream.
Commit
6f542ebeaee0 ("MIPS: Fix race on setting and getting
cpu_online_mask") effectively reverted commit
8f46cca1e6c06 ("MIPS: SMP:
Fix possibility of deadlock when bringing CPUs online") and thus has
reinstated the possibility of deadlock.
The commit was based on testing of kernel v4.4, where the CPU hotplug
core code issued a BUG() if the starting CPU is not marked online when
the boot CPU returns from __cpu_up. The commit fixes this race (in
v4.4), but re-introduces the deadlock situation.
As noted in the commit message, upstream differs in this area. Commit
8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up")
adds a completion event in the CPU hotplug core code, making this race
impossible. However, people were unhappy with relying on the core code
to do the right thing.
To address the issues both commits were trying to fix, add a second
completion event in the MIPS smp hotplug path. It removes the
possibility of a race, since the MIPS smp hotplug code now synchronises
both the boot and secondary CPUs before they return to the hotplug core
code. It also addresses the deadlock by ensuring that the secondary CPU
is not marked online before it's counters are synchronised.
This fix should also be backported to fix the race condition introduced
by the backport of commit
8f46cca1e6c06 ("MIPS: SMP: Fix possibility of
deadlock when bringing CPUs online"), through really that race only
existed before commit
8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu
bring itself fully up").
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Fixes:
6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask")
CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
Patchwork: https://patchwork.linux-mips.org/patch/17376/
Signed-off-by: James Hogan <jhogan@kernel.org>
[jhogan@kernel.org: Backported 4.1..4.9]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matija Glavinic Pecotic [Thu, 3 Aug 2017 06:20:22 +0000 (08:20 +0200)]
MIPS: Fix race on setting and getting cpu_online_mask
commit
6f542ebeaee0ee552a902ce3892220fc22c7ec8e upstream.
While testing cpu hoptlug (cpu down and up in loops) on kernel 4.4, it was
observed that occasionally check for cpu online will fail in kernel/cpu.c,
_cpu_up:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/kernel/cpu.c?h=v4.4.79#n485
518 /* Arch-specific enabling code. */
519 ret = __cpu_up(cpu, idle);
520
521 if (ret != 0)
522 goto out_notify;
523 BUG_ON(!cpu_online(cpu));
Reason is race between start_secondary and _cpu_up. cpu_callin_map is set
before cpu_online_mask. In __cpu_up, cpu_callin_map is waited for, but cpu
online mask is not, resulting in race in which secondary processor started
and set cpu_callin_map, but not yet set the online mask,resulting in above
BUG being hit.
Upstream differs in the area. cpu_online check is in bringup_wait_for_ap,
which is after cpu reached AP_ONLINE_IDLE,where secondary passed its start
function. Nonetheless, fix makes start_secondary safe and not depending on
other locks throughout the code. It protects as well against cpu_online
checks put in between sometimes in the future.
Fix this by moving completion after all flags are set.
Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16925/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matt Redfearn [Fri, 4 Nov 2016 09:28:56 +0000 (09:28 +0000)]
MIPS: SMP: Use a completion event to signal CPU up
commit
a00eeede507c975087b7b8df8cf2c9f88ba285de upstream.
If a secondary CPU failed to start, for any reason, the CPU requesting
the secondary to start would get stuck in the loop waiting for the
secondary to be present in the cpu_callin_map.
Rather than that, use a completion event to signal that the secondary
CPU has started and is waiting to synchronise counters.
Since the CPU presence will no longer be marked in cpu_callin_map,
remove the redundant test from arch_cpu_idle_dead().
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Maciej W. Rozycki <macro@imgtec.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Qais Yousef <qsyousef@gmail.com>
Cc: James Hogan <james.hogan@imgtec.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Marcin Nowakowski <marcin.nowakowski@imgtec.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14502/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Burton [Tue, 31 Oct 2017 22:09:22 +0000 (15:09 -0700)]
MIPS: Fix CM region target definitions
commit
6a6cba1d945a7511cdfaf338526871195e420762 upstream.
The default CM target field in the GCR_BASE register is encoded with 0
meaning memory & 1 being reserved. However the definitions we use for
those bits effectively get these two values backwards - likely because
they were copied from the definitions for the CM regions where the
target is encoded differently. This results in use setting up GCR_BASE
with the reserved target value by default, rather than targeting memory
as intended. Although we currently seem to get away with this it's not a
great idea to rely upon.
Fix this by changing our macros to match the documentated target values.
The incorrect encoding became used as of commit
9f98f3dd0c51 ("MIPS: Add
generic CM probe & access code") in the Linux v3.15 cycle, and was
likely carried forwards from older but unused code introduced by
commit
39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the
v2.6.26 cycle.
Fixes:
9f98f3dd0c51 ("MIPS: Add generic CM probe & access code")
Signed-off-by: Paul Burton <paul.burton@mips.com>
Reported-by: Matt Redfearn <matt.redfearn@mips.com>
Reviewed-by: James Hogan <jhogan@kernel.org>
Cc: Matt Redfearn <matt.redfearn@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # v3.15+
Patchwork: https://patchwork.linux-mips.org/patch/17562/
Signed-off-by: James Hogan <jhogan@kernel.org>
[jhogan@kernel.org: Backported 3.15..4.13]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Tue, 31 Oct 2017 05:35:03 +0000 (00:35 -0500)]
MIPS: microMIPS: Fix incorrect mask in insn_table_MM
commit
77238e76b9156d28d86c1e31c00ed2960df0e4de upstream.
It seems that this is a typo error and the proper bit masking is
"RT | RS" instead of "RS | RS".
This issue was detected with the help of Coccinelle.
Fixes:
d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Reviewed-by: James Hogan <jhogan@kernel.org>
Patchwork: https://patchwork.linux-mips.org/patch/17551/
Signed-off-by: James Hogan <jhogan@kernel.org>
[jhogan@kernel.org: Backported 3.16..4.12]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Mon, 6 Nov 2017 19:16:50 +0000 (20:16 +0100)]
ALSA: seq: Avoid invalid lockdep class warning
commit
3510c7aa069aa83a2de6dab2b41401a198317bdc upstream.
The recent fix for adding rwsem nesting annotation was using the given
"hop" argument as the lock subclass key. Although the idea itself
works, it may trigger a kernel warning like:
BUG: looking up invalid subclass: 8
....
since the lockdep has a smaller number of subclasses (8) than we
currently allow for the hops there (10).
The current definition is merely a sanity check for avoiding the too
deep delivery paths, and the 8 hops are already enough. So, as a
quick fix, just follow the max hops as same as the max lockdep
subclasses.
Fixes:
1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 7 Nov 2017 15:05:24 +0000 (16:05 +0100)]
ALSA: seq: Fix OSS sysex delivery in OSS emulation
commit
132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream.
The SYSEX event delivery in OSS sequencer emulation assumed that the
event is encoded in the variable-length data with the straight
buffering. This was the normal behavior in the past, but during the
development, the chained buffers were introduced for carrying more
data, while the OSS code was left intact. As a result, when a SYSEX
event with the chained buffer data is passed to OSS sequencer port,
it may end up with the wrong memory access, as if it were having a too
large buffer.
This patch addresses the bug, by applying the buffer data expansion by
the generic snd_seq_dump_var_event() helper function.
Reported-by: syzbot <syzkaller@googlegroups.com>
Reported-by: Mark Salyzyn <salyzyn@android.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Thu, 2 Nov 2017 17:44:28 +0000 (18:44 +0100)]
ARM: 8720/1: ensure dump_instr() checks addr_limit
commit
b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream.
When CONFIG_DEBUG_USER is enabled, it's possible for a user to
deliberately trigger dump_instr() with a chosen kernel address.
Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.
So that we can use the same code to dump user instructions and kernel
instructions, the common dumping code is factored out to __dump_instr(),
with the fs manipulated appropriately in dump_instr() around calls to
this.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Tue, 7 Nov 2017 22:29:02 +0000 (22:29 +0000)]
KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]
commit
624f5ab8720b3371367327a822c267699c1823b8 upstream.
syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It
can be reproduced by the following command, assuming
CONFIG_PKCS7_TEST_KEY=y:
keyctl add pkcs7_test desc '' @s
The bug is that if the data buffer is empty, an integer underflow occurs
in the following check:
if (unlikely(dp >= datalen - 1))
goto data_overrun_error;
This results in the NULL data pointer being dereferenced.
Fix it by checking for 'datalen - dp < 2' instead.
Also fix the similar check for 'dp >= datalen - n' later in the same
function. That one possibly could result in a buffer overread.
The NULL pointer dereference was reproducible using the "pkcs7_test" key
type but not the "asymmetric" key type because the "asymmetric" key type
checks for a 0-length payload before calling into the ASN.1 decoder but
the "pkcs7_test" key type does not.
The bug report was:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233
PGD
7b708067 P4D
7b708067 PUD
7b6ee067 PMD 0
Oops: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014
task:
ffff9b6b3798c040 task.stack:
ffff9b6b37970000
RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233
RSP: 0018:
ffff9b6b37973c78 EFLAGS:
00010216
RAX:
0000000000000000 RBX:
0000000000000000 RCX:
000000000000021c
RDX:
ffffffff814a04ed RSI:
ffffb1524066e000 RDI:
ffffffff910759e0
RBP:
ffff9b6b37973d60 R08:
0000000000000001 R09:
ffff9b6b3caa4180
R10:
0000000000000000 R11:
0000000000000000 R12:
0000000000000002
R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000000
FS:
00007f10ed1f2700(0000) GS:
ffff9b6b3ea00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000000000000 CR3:
000000007b6f3000 CR4:
00000000000006f0
Call Trace:
pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139
verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216
pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63
key_create_or_update+0x180/0x530 security/keys/key.c:855
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4585c9
RSP: 002b:
00007f10ed1f1bd8 EFLAGS:
00000216 ORIG_RAX:
00000000000000f8
RAX:
ffffffffffffffda RBX:
00007f10ed1f2700 RCX:
00000000004585c9
RDX:
0000000020000000 RSI:
0000000020008ffb RDI:
0000000020008000
RBP:
0000000000000000 R08:
ffffffffffffffff R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000216 R12:
00007fff1b2260ae
R13:
00007fff1b2260af R14:
00007f10ed1f2700 R15:
0000000000000000
Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff
RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP:
ffff9b6b37973c78
CR2:
0000000000000000
Fixes:
42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrey Ryabinin [Mon, 16 Oct 2017 15:51:31 +0000 (18:51 +0300)]
crypto: x86/sha1-mb - fix panic due to unaligned access
commit
d041b557792c85677f17e08eee535eafbd6b9aa2 upstream.
struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc()
and later passed in sha1_mb_flusher_mgr_flush_avx2() function where
instructions vmovdqa used to access the struct. vmovdqa requires
16-bytes aligned argument, but nothing guarantees that struct
sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will
generate GP fault.
Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment
requirements.
Fixes:
2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Bin [Sat, 28 Oct 2017 03:07:28 +0000 (11:07 +0800)]
workqueue: Fix NULL pointer dereference
commit
cef572ad9bd7f85035ba8272e5352040e8be0152 upstream.
When queue_work() is used in irq (not in task context), there is
a potential case that trigger NULL pointer dereference.
----------------------------------------------------------------
worker_thread()
|-spin_lock_irq()
|-process_one_work()
|-worker->current_pwq = pwq
|-spin_unlock_irq()
|-worker->current_func(work)
|-spin_lock_irq()
|-worker->current_pwq = NULL
|-spin_unlock_irq()
//interrupt here
|-irq_handler
|-__queue_work()
//assuming that the wq is draining
|-is_chained_work(wq)
|-current_wq_worker()
//Here, 'current' is the interrupted worker!
|-current->current_pwq is NULL here!
|-schedule()
----------------------------------------------------------------
Avoid it by checking for task context in current_wq_worker(), and
if not in task context, we shouldn't use the 'current' to check the
condition.
Reported-by: Xiaofei Tan <tanxiaofei@huawei.com>
Signed-off-by: Li Bin <huawei.libin@huawei.com>
Reviewed-by: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Fixes:
8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()")
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Tue, 22 Nov 2016 09:57:15 +0000 (10:57 +0100)]
x86/uaccess, sched/preempt: Verify access_ok() context
commit
7c4788950ba5922fde976d80b72baf46f14dee8d upstream.
I recently encountered wreckage because access_ok() was used where it
should not be, add an explicit WARN when access_ok() is used wrongly.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
[add include/preempt.h to fix build error - gregkh]
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlo Caione [Wed, 19 Apr 2017 20:36:39 +0000 (22:36 +0200)]
platform/x86: hp-wmi: Do not shadow error values
commit
d313876925f3e7a480a02773fd333bcab9202d5e upstream.
All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state,
...) using hp_wmi_perform_query to perform an HP WMI query shadow the
returned value in case of error.
We return -EINVAL only when the HP WMI query returns a positive value
(the specific error code) to not mix this up with the actual value
returned by the helper function.
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Cc: Philip Müller <philm@manjaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlo Caione [Sun, 9 Apr 2017 13:56:07 +0000 (15:56 +0200)]
platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state
commit
c7dfc2facbd69dad89b75e13c608da709668dcd0 upstream.
hp_wmi_tablet_state() fails to return the correct error code when
hp_wmi_perform_query() returns the HP WMI query specific error code
that is a positive value.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Cc: Philip Müller <philm@manjaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 2 Nov 2017 00:47:12 +0000 (00:47 +0000)]
KEYS: trusted: fix writing past end of buffer in trusted_read()
commit
a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream.
When calling keyctl_read() on a key of type "trusted", if the
user-supplied buffer was too small, the kernel ignored the buffer length
and just wrote past the end of the buffer, potentially corrupting
userspace memory. Fix it by instead returning the size required, as per
the documentation for keyctl_read().
We also don't even fill the buffer at all in this case, as this is
slightly easier to implement than doing a short read, and either
behavior appears to be permitted. It also makes it match the behavior
of the "encrypted" key type.
Fixes:
d00a1c72f7f4 ("keys: add new trusted key-type")
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 8 Jun 2017 13:49:18 +0000 (14:49 +0100)]
KEYS: trusted: sanitize all key material
commit
ee618b4619b72527aaed765f0f0b74072b281159 upstream.
As the previous patch did for encrypted-keys, zero sensitive any
potentially sensitive data related to the "trusted" key type before it
is freed. Notably, we were not zeroing the tpm_buf structures in which
the actual key is stored for TPM seal and unseal, nor were we zeroing
the trusted_key_payload in certain error paths.
Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: David Safford <safford@us.ibm.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Enrico Mioso [Tue, 11 Jul 2017 15:21:52 +0000 (17:21 +0200)]
cdc_ncm: Set NTB format again after altsetting switch for Huawei devices
commit
2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f upstream.
Some firmwares in Huawei E3372H devices have been observed to switch back
to NTB 32-bit format after altsetting switch.
This patch implements a driver flag to check for the device settings and
set NTB format to 16-bit again if needed.
The flag has been activated for devices controlled by the huawei_cdc_ncm.c
driver.
V1->V2:
- fixed broken error checks
- some corrections to the commit message
V2->V3:
- variable name changes, to clarify what's happening
- check (and possibly set) the NTB format later in the common bind code path
Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
Reported-and-tested-by: Christian Panton <christian@panton.org>
Reviewed-by: Bjørn Mork <bjorn@mork.no>
CC: Bjørn Mork <bjorn@mork.no>
CC: Christian Panton <christian@panton.org>
CC: linux-usb@vger.kernel.org
CC: netdev@vger.kernel.org
CC: Oliver Neukum <oliver@neukum.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Porto Rio <porto.rio@gmx.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Carlo Caione [Sun, 9 Apr 2017 13:56:08 +0000 (15:56 +0200)]
platform/x86: hp-wmi: Fix detection for dock and tablet mode
commit
298747b7579f5bbbced793d997b333fd10a24921 upstream.
The current driver code is not checking for the error values returned by
'hp_wmi_dock_state()' and 'hp_wmi_tablet_state()' before passing the
returned values down to 'input_report_switch()'. This error code is
being translated to '1' in the input subsystem, reporting the wrong
status.
The biggest problem caused by this issue is that several laptops are
wrongly reported by the driver as docked, preventing them to be put to
sleep using the LID (and in most cases they are not even dockable).
With this patch we create the report switches only if we are able to
read the dock and tablet mode status correctly from ACPI.
Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org>
Cc: Philip Müller <philm@manjaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vivien Didelot [Mon, 9 Jan 2017 21:49:26 +0000 (16:49 -0500)]
net: dsa: select NET_SWITCHDEV
[ Upstream commit
3a89eaa65db68bf53bf92dedc60084f810e1779a ]
The support for DSA Ethernet switch chips depends on TCP/IP networking,
thus explicit that HAVE_NET_DSA depends on INET.
DSA uses SWITCHDEV, thus select it instead of depending on it.
Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julian Wiedmann [Thu, 12 Jan 2017 14:48:42 +0000 (15:48 +0100)]
s390/qeth: issue STARTLAN as first IPA command
[ Upstream commit
1034051045d125579ab1e8fcd5a724eeb0e70149 ]
STARTLAN needs to be the first IPA command after MPC initialization
completes.
So move the qeth_send_startlan() call from the layer disciplines
into the core path, right after the MPC handshake.
While at it, replace the magic LAN OFFLINE return code
with the existing enum.
Signed-off-by: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Reviewed-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Reviewed-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Feras Daoud [Wed, 28 Dec 2016 12:47:28 +0000 (14:47 +0200)]
IB/ipoib: Change list_del to list_del_init in the tx object
[ Upstream commit
27d41d29c7f093f6f77843624fbb080c1b4a8b9c ]
Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function
belong to different work queues, they can run in parallel.
In this case if ipoib_cm_tx_reap calls list_del and release the
lock, ipoib_cm_tx_start may acquire it and call list_del_init
on the already deleted object.
Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem.
Fixes:
839fcaba355a ("IPoIB: Connected mode experimental support")
Signed-off-by: Feras Daoud <ferasda@mellanox.com>
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Reviewed-by: Alex Vesker <valex@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Sun, 15 Jan 2017 22:44:05 +0000 (14:44 -0800)]
Input: mpr121 - set missing event capability
[ Upstream commit
9723ddc8fe0d76ce41fe0dc16afb241ec7d0a29d ]
This driver reports misc scan input events on the sensor's status
register changes. But the event capability for them was not set in the
device initialization, so these events were ignored.
This change adds the missing event capability.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Akinobu Mita [Sun, 15 Jan 2017 22:44:30 +0000 (14:44 -0800)]
Input: mpr121 - handle multiple bits change of status register
[ Upstream commit
08fea55e37f58371bffc5336a59e55d1f155955a ]
This driver reports input events on their interrupts which are triggered
by the sensor's status register changes. But only single bit change is
reported in the interrupt handler. So if there are multiple bits are
changed at almost the same time, other press or release events are ignored.
This fixes it by detecting all changed bits in the status register.
Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gilad Ben-Yossef [Mon, 16 Jan 2017 11:17:55 +0000 (13:17 +0200)]
IPsec: do not ignore crypto err in ah4 input
[ Upstream commit
ebd89a2d0675f1325c2be5b7576fd8cb7e8defd0 ]
ah4 input processing uses the asynchronous hash crypto API which
supplies an error code as part of the operation completion but
the error code was being ignored.
Treat a crypto API error indication as a verification failure.
While a crypto API reported error would almost certainly result
in a memcpy of the digest failing anyway and thus the security
risk seems minor, performing a memory compare on what might be
uninitialized memory is wrong.
Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liping Zhang [Sat, 7 Jan 2017 13:33:55 +0000 (21:33 +0800)]
netfilter: nft_meta: deal with PACKET_LOOPBACK in netdev family
[ Upstream commit
f169fd695b192dd7b23aff8e69d25a1bc881bbfa ]
After adding the following nft rule, then ping 224.0.0.1:
# nft add rule netdev t c pkttype host counter
The warning complain message will be printed out again and again:
WARNING: CPU: 0 PID: 10182 at net/netfilter/nft_meta.c:163 \
nft_meta_get_eval+0x3fe/0x460 [nft_meta]
[...]
Call Trace:
<IRQ>
dump_stack+0x85/0xc2
__warn+0xcb/0xf0
warn_slowpath_null+0x1d/0x20
nft_meta_get_eval+0x3fe/0x460 [nft_meta]
nft_do_chain+0xff/0x5e0 [nf_tables]
So we should deal with PACKET_LOOPBACK in netdev family too. For ipv4,
convert it to PACKET_BROADCAST/MULTICAST according to the destination
address's type; For ipv6, convert it to PACKET_MULTICAST directly.
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William wu [Fri, 13 Jan 2017 03:04:22 +0000 (11:04 +0800)]
usb: hcd: initialize hcd->flags to 0 when rm hcd
[ Upstream commit
76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ]
On some platforms(e.g. rk3399 board), we can call hcd_add/remove
consecutively without calling usb_put_hcd/usb_create_hcd in between,
so hcd->flags can be stale.
If the HC dies due to whatever reason then without this patch we get
the below error on next hcd_add.
[173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller
[173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6
[173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003
[173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[173.297222] usb usb6: Product: xHCI Host Controller
[173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd
[173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto
[173.298680] hub 6-0:1.0: USB hub found
[173.298749] hub 6-0:1.0: 1 port detected
[173.299382] rockchip-dwc3 usb@
fe800000: USB HOST connected
[173.395418] hub 5-0:1.0: activate --> -19
[173.603447] irq 228: nobody cared (try booting with the "irqpoll" option)
[173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9
[173.603513] Hardware name: Google Kevin (DT)
[173.603531] Call trace:
[173.603568] [<
ffffffc0002087dc>] dump_backtrace+0x0/0x160
[173.603596] [<
ffffffc00020895c>] show_stack+0x20/0x28
[173.603623] [<
ffffffc0004b28a8>] dump_stack+0x90/0xb0
[173.603650] [<
ffffffc00027347c>] __report_bad_irq+0x48/0xe8
[173.603674] [<
ffffffc0002737cc>] note_interrupt+0x1e8/0x28c
[173.603698] [<
ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c
[173.603722] [<
ffffffc000270b0c>] handle_irq_event+0x4c/0x7c
[173.603748] [<
ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124
[173.603777] [<
ffffffc00026fe3c>] generic_handle_irq+0x30/0x44
[173.603804] [<
ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc
[173.603827] [<
ffffffc0002006f4>] gic_handle_irq+0xcc/0x188
...
[173.604500] [<
ffffffc000203700>] el1_irq+0x80/0xf8
[173.604530] [<
ffffffc000261388>] cpu_startup_entry+0x38/0x3cc
[173.604558] [<
ffffffc00090f7d8>] rest_init+0x8c/0x94
[173.604585] [<
ffffffc000e009ac>] start_kernel+0x3d0/0x3fc
[173.604607] [<
0000000000b16000>] 0xb16000
[173.604622] handlers:
[173.604648] [<
ffffffc000642084>] usb_hcd_irq
[173.604673] Disabling IRQ #228
Signed-off-by: William wu <wulf@rock-chips.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Pinchart [Wed, 11 Jan 2017 14:43:32 +0000 (16:43 +0200)]
serial: sh-sci: Fix register offsets for the IRDA serial port
[ Upstream commit
a752ba18af8285e3eeda572f40dddaebff0c3621 ]
Even though most of its registers are 8-bit wide, the IRDA has two
16-bit registers that make it a 16-bit peripheral and not a 8-bit
peripheral with addresses shifted by one. Fix the registers offset in
the driver and the platform data regshift value.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Volodymyr Bendiuga [Thu, 19 Jan 2017 16:05:04 +0000 (17:05 +0100)]
phy: increase size of MII_BUS_ID_SIZE and bus_id
[ Upstream commit
4567d686f5c6d955e57a3afa1741944c1e7f4033 ]
Some bus names are pretty long and do not fit into
17 chars. Increase therefore MII_BUS_ID_SIZE and
phy_fixup.bus_id to larger number. Now mii_bus.id
can host larger name.
Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com>
Signed-off-by: Magnus Öberg <magnus.oberg@westermo.se>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alison Schofield [Fri, 20 Jan 2017 03:47:38 +0000 (19:47 -0800)]
iio: trigger: free trigger resource correctly
[ Upstream commit
10e840dfb0b7fc345082dd9e5fff3c1c02e7690e ]
These stand-alone trigger drivers were using iio_trigger_put()
where they should have been using iio_trigger_free(). The
iio_trigger_put() adds a module_put which is bad since they
never did a module_get.
In the sysfs driver, module_get/put's are used as triggers are
added & removed. This extra module_put() occurs on an error path
in the probe routine (probably rare).
In the bfin-timer & interrupt trigger drivers, the module resources
are not explicitly managed, so it's doing a put on something that
was never get'd. It occurs on the probe error path and on the
remove path (not so rare).
Tested with the sysfs trigger driver.
The bfin & interrupt drivers were build tested & inspected only.
Signed-off-by: Alison Schofield <amsfield22@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Zhong [Fri, 20 Jan 2017 08:35:33 +0000 (16:35 +0800)]
crypto: vmx - disable preemption to enable vsx in aes_ctr.c
[ Upstream commit
7dede913fc2ab9c0d3bff3a49e26fa9e858b0c13 ]
Some preemptible check warnings were reported from enable_kernel_vsx(). This
patch disables preemption in aes_ctr.c before enabling vsx, and they are now
consistent with other files in the same directory.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tony Lindgren [Fri, 20 Jan 2017 20:13:19 +0000 (12:13 -0800)]
ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6
[ Upstream commit
4cd6a59f5c1a9b0cca0da09fbba42b9450ffc899 ]
We have more than four uarts on some SoCs and that can cause
noise with errors while booting.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Valentin Longchamp [Thu, 15 Dec 2016 13:22:26 +0000 (14:22 +0100)]
powerpc/corenet: explicitly disable the SDHC controller on kmcoge4
[ Upstream commit
a674c7d470bb47e82f4eb1fa944eadeac2f6bbaf ]
It is not implemented on the kmcoge4 hardware and if not disabled it
leads to error messages with the corenet32_smp_defconfig.
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nate Watterson [Wed, 21 Dec 2016 04:11:48 +0000 (23:11 -0500)]
iommu/arm-smmu-v3: Clear prior settings when updating STEs
[ Upstream commit
810871c57011eb3e89e6768932757f169d666cd2 ]
To prevent corruption of the stage-1 context pointer field when
updating STEs, rebuild the entire containing dword instead of
clearing individual fields.
Signed-off-by: Nate Watterson <nwatters@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Li Zhong [Fri, 11 Nov 2016 04:57:33 +0000 (12:57 +0800)]
KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter
[ Upstream commit
37451bc95dee0e666927d6ffdda302dbbaaae6fa ]
Some counters are added in Commit
6e0365b78273 ("KVM: PPC: Book3S HV:
Add ICP real mode counters"), to provide some performance statistics to
determine whether further optimizing is needed for real mode functions.
The n_reject counter counts how many times ICP rejects an irq because of
priority in real mode. The redelivery of an lsi that is still asserted
after eoi doesn't fall into this category, so the increasement there is
removed.
Also, it needs to be increased in icp_rm_deliver_irq() if it rejects
another one.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noralf Trønnes [Thu, 26 Jan 2017 22:56:04 +0000 (23:56 +0100)]
drm: drm_minor_register(): Clean up debugfs on failure
[ Upstream commit
a67834f8bfa1e2f48bb27d07b9a552ba7c3af82a ]
Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to
cover for failure in the drm_driver.debugfs_init callback.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@tronnes.org
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Tue, 10 Jan 2017 13:32:52 +0000 (14:32 +0100)]
xen/netback: set default upper limit of tx/rx queues to 8
[ Upstream commit
56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ]
The default for the maximum number of tx/rx queues of one interface is
the number of cpus of the system today. As each queue pair reserves 512
grant pages this default consumes a ridiculous number of grants for
large guests.
Limit the queue number to 8 as default. This value can be modified
via a module parameter if required.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Gunthorpe [Mon, 12 Dec 2016 18:30:20 +0000 (11:30 -0700)]
PCI: mvebu: Handle changes to the bridge windows while enabled
[ Upstream commit
d9bf28e2650fe3eeefed7e34841aea07d10c6543 ]
The PCI core will write to the bridge window config multiple times while
they are enabled. This can lead to mbus failures like this:
mvebu_mbus: cannot add window '4:e8', conflicts with another window
mvebu-pcie mbus:pex@
e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22
For me this is happening during a hotplug cycle. The PCI core is not
changing the values, just writing them twice while active.
The patch addresses the general case of any change to an active window, but
not atomically. The code is slightly refactored so io and mem can share
more of the window logic.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maciej W. Rozycki [Mon, 30 Jan 2017 16:39:48 +0000 (17:39 +0100)]
video: fbdev: pmag-ba-fb: Remove bad `__init' annotation
[ Upstream commit
879e5a0df626f39cbb3c61bb90373e56d67012c4 ]
Fix:
WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor()
The function pmagbafb_probe()
references the function __init pmagbafb_erase_cursor().
This is often because pmagbafb_probe lacks a __init
annotation or the annotation of pmagbafb_erase_cursor is wrong.
-- a fallout from a missed update from commit
9625b51350cc ("VIDEO:
PMAG-BA: Fix section mismatch") and then commit
48c68c4f1b54 ("Drivers:
video: remove __dev* attributes.")
Signed-off-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lars-Peter Clausen [Tue, 29 Nov 2016 11:23:48 +0000 (09:23 -0200)]
adv7604: Initialize drive strength to default when using DT
[ Upstream commit
da8892d410db224d9a24104529794e6e37e0c100 ]
The adv7604 driver platform data contains fields for configuring the drive
strength of the output pins. When probing the driver through DT these
fields are not explicitly initialized, which means they are left at 0. This
is a reserved setting for the drive strength configuration though and can
cause signal integrity issues.
Whether these signal integrity issues are visible depends on the PCB
specifics (e.g. the higher the load capacitance for the output the more
visible the issue). But it has been observed on existing solutions at high
pixel clock rates.
Initialize the drive strength settings to the power-on-reset value of the
device when probing through devicetree to avoid this issue.
Fixes:
0e158be0162b ("adv7604: Add DT support")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Wed, 8 Nov 2017 09:06:31 +0000 (10:06 +0100)]
Linux 4.4.97
Larry Finger [Sat, 11 Feb 2017 03:30:27 +0000 (21:30 -0600)]
staging: r8712u: Fix Sparse warning in rtl871x_xmit.c
[ Upstream commit
07222e535831b916221dd2a48a3047ec7e45dc72 ]
Sparse reports the following:
CHECK drivers/staging/rtl8712/rtl871x_xmit.c
drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: expected unsigned short [usertype] *fctrl
drivers/staging/rtl8712/rtl871x_xmit.c:491:23: got restricted __le16 *<noident>
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types)
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: expected unsigned short [unsigned] [short] [usertype] <noident>
drivers/staging/rtl8712/rtl871x_xmit.c:580:36: got restricted __be16 [usertype] <noident>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Tue, 30 May 2017 18:52:26 +0000 (20:52 +0200)]
xen: don't print error message in case of missing Xenstore entry
[ Upstream commit
4e93b6481c87ea5afde944a32b4908357ec58992 ]
When registering for the Xenstore watch of the node control/sysrq the
handler will be called at once. Don't issue an error message if the
Xenstore node isn't there, as it will be created only when an event
is being triggered.
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudip Mukherjee [Sat, 7 Oct 2017 22:37:49 +0000 (22:37 +0000)]
bt8xx: fix memory leak
[ Upstream commit
6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ]
If dvb_attach() fails then we were just printing an error message and
exiting but the memory allocated to state was not released.
Signed-off-by: Sudip Mukherjee <sudip.mukherjee@codethink.co.uk>
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Haberland [Sat, 7 Oct 2017 22:37:49 +0000 (22:37 +0000)]
s390/dasd: check for device error pointer within state change interrupts
[ Upstream commit
2202134e48a3b50320aeb9e3dd1186833e9d7e66 ]
Check if the device pointer is valid. Just a sanity check since we already
are in the int handler of the device.
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Usyskin [Sat, 7 Oct 2017 22:37:48 +0000 (22:37 +0000)]
mei: return error on notification request to a disconnected client
[ Upstream commit
7c47d2ca0feca767479329da23523ed798acb854 ]
Request for a notification from a disconnected client will be ignored
silently by the FW but the caller should know that the operation hasn't
succeeded.
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arvind Yadav [Sat, 7 Oct 2017 22:37:48 +0000 (22:37 +0000)]
exynos4-is: fimc-is: Unmap region obtained by of_iomap()
[ Upstream commit
4742575cde1f3cee0ea6b41af42781672315b04b ]
Free memory mapping, if fimc_is_probe is not successful.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Boyko [Sat, 7 Oct 2017 22:37:48 +0000 (22:37 +0000)]
staging: lustre: ptlrpc: skip lock if export failed
[ Upstream commit
4c43c27ddc461d8473cedd70f2549614641dfbc7 ]
This patch resolves IO vs eviction race.
After eviction failed export stayed at stale list,
a client had IO processing and reconnected during it.
A client sent brw rpc with last lock cookie and new connection.
The lock with failed export was found and assert was happened.
(ost_handler.c:1812:ost_prolong_lock_one())
ASSERTION( lock->l_export == opd->opd_exp ) failed:
1. Skip the lock at ldlm_handle2lock if lock export failed.
2. Validation of lock for IO was added at hpreq_check(). The lock
searching is based on granted interval tree. If server doesn`t
have a valid lock, it reply to client with ESTALE.
Signed-off-by: Alexander Boyko <alexander.boyko@seagate.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702
Seagate-bug-id: MRP-2787
Reviewed-on: http://review.whamcloud.com/18120
Reviewed-by: Fan Yong <fan.yong@intel.com>
Reviewed-by: Vitaly Fertman <vitaly.fertman@seagate.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
frank zago [Sat, 7 Oct 2017 22:37:48 +0000 (22:37 +0000)]
staging: lustre: hsm: stack overrun in hai_dump_data_field
[ Upstream commit
22aadb91c0a0055935109c175f5446abfb130702 ]
The function hai_dump_data_field will do a stack buffer
overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has
some data in it.
hai_dump_data_field uses snprintf. But there is no check for
truncation, and the value returned by snprintf is used as-is. The
coordinator code calls hai_dump_data_field with 12 bytes in the
buffer. The 6th byte of data is printed incompletely to make room for
the terminating NUL. However snprintf still returns 2, so when
hai_dump_data_field writes the final NUL, it does it outside the
reserved buffer, in the 13th byte of the buffer. This stack buffer
overrun hangs my VM.
Fix by checking that there is enough room for the next 2 characters
plus the NUL terminator. Don't print half bytes. Change the format to
02X instead of .2X, which makes more sense.
Signed-off-by: frank zago <fzago@cray.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171
Reviewed-on: http://review.whamcloud.com/20338
Reviewed-by: John L. Hammond <john.hammond@intel.com>
Reviewed-by: Jean-Baptiste Riaux <riaux.jb@intel.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yang Sheng [Sat, 7 Oct 2017 22:37:48 +0000 (22:37 +0000)]
staging: lustre: llite: don't invoke direct_IO for the EOF case
[ Upstream commit
77759771fb95420d23876cb104ab65c022613325 ]
The function generic_file_read_iter() does not check EOF
before invoke direct_IO callback. So we have to check it
ourselves.
Signed-off-by: Yang Sheng <yang.sheng@intel.com>
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969
Reviewed-on: https://review.whamcloud.com/24552
Reviewed-by: Bob Glossman <bob.glossman@intel.com>
Reviewed-by: Bobi Jam <bobijam@hotmail.com>
Reviewed-by: Oleg Drokin <oleg.drokin@intel.com>
Signed-off-by: James Simmons <jsimmons@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Javier Martinez Canillas [Sat, 7 Oct 2017 22:37:47 +0000 (22:37 +0000)]
platform/x86: intel_mid_thermal: Fix module autoload
[ Upstream commit
a93151a72061e944a4915458b1b1d6d505c03bbf ]
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
$
After this patch:
$ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias
alias: platform:msic_thermal
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Raghava Aditya Renukunta [Sat, 7 Oct 2017 22:37:47 +0000 (22:37 +0000)]
scsi: aacraid: Process Error for response I/O
[ Upstream commit
4ec57fb4edaec523f0f78a0449a3b063749ac58b ]
Make sure that the driver processes error conditions even in the fast
response path for response from the adapter.
Signed-off-by: Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com>
Signed-off-by: Dave Carroll <David.Carroll@microsemi.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Beulich [Sat, 7 Oct 2017 22:37:47 +0000 (22:37 +0000)]
xen/manage: correct return value check on xenbus_scanf()
[ Upstream commit
4fed1b125eb6252bde478665fc05d4819f774fa8 ]
A negative return value indicates an error; in fact the function at
present won't ever return zero.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleh Kravchenko [Sat, 7 Oct 2017 22:37:46 +0000 (22:37 +0000)]
cx231xx: Fix I2C on Internal Master 3 Bus
[ Upstream commit
6c5da8031a3abfad259190d35f83d89568b72ee2 ]
Internal Master 3 Bus can send and receive only 4 bytes per time.
Signed-off-by: Oleh Kravchenko <oleg@kaa.org.ua>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Taeung Song [Sat, 7 Oct 2017 22:37:46 +0000 (22:37 +0000)]
perf tools: Only increase index if perf_evsel__new_idx() succeeds
[ Upstream commit
75fc5ae5cc53fff71041ecadeb3354a2b4c9fe42 ]
Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1485952447-7013-2-git-send-email-treeze.taeung@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rex Zhu [Sat, 7 Oct 2017 22:37:46 +0000 (22:37 +0000)]
drm/amdgpu: when dpm disabled, also need to stop/start vce.
[ Upstream commit
28ed5504ab4b211a4e589e648e5ebd1e0caa7a6a ]
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chris Brandt [Sat, 7 Oct 2017 22:37:45 +0000 (22:37 +0000)]
i2c: riic: correctly finish transfers
[ Upstream commit
71ccea095ea1d4efd004dab971be6d599e06fc3f ]
This fixes the condition where the controller has not fully completed its
final transfer and leaves the bus and controller in a undesirable state.
At the end of the last transmitted byte, the existing driver would just
signal for a STOP condition to be transmitted then immediately signal
completion. However, the full STOP procedure might not have fully taken
place by the time the runtime PM shuts off the peripheral clock, leaving
the bus in a suspended state.
Alternatively, the STOP condition on the bus may have completed, but when
the next transaction is requested by the upper layer, not all the
necessary register cleanup was finished from the last transfer which made
the driver return BUS BUSY when it really wasn't.
This patch now makes all transmit and receive transactions wait for the
STOP condition to fully complete before signaling a completed transaction.
With this new method, runtime PM no longer seems to be an issue.
Fixes:
310c18a41450 ("i2c: riic: add driver")
Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Sat, 7 Oct 2017 22:37:45 +0000 (22:37 +0000)]
ext4: do not use stripe_width if it is not set
[ Upstream commit
5469d7c3087ecaf760f54b447f11af6061b7c897 ]
Avoid using stripe_width for sbi->s_stripe value if it is not actually
set. It prevents using the stride for sbi->s_stripe.
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Sat, 7 Oct 2017 22:37:45 +0000 (22:37 +0000)]
ext4: fix stripe-unaligned allocations
[ Upstream commit
d9b22cf9f5466a057f2a4f1e642b469fa9d73117 ]
When a filesystem is created using:
mkfs.ext4 -b 4096 -E stride=512 <dev>
and we try to allocate 64MB extent, we will end up directly in
ext4_mb_complex_scan_group(). This is because the request is detected
as power-of-two allocation (so we start in ext4_mb_regular_allocator()
with ac_criteria == 0) however the check before
ext4_mb_simple_scan_group() refuses the direct buddy scan because the
allocation request is too large. Since cr == 0, the check whether we
should use ext4_mb_scan_aligned() fails as well and we fall back to
ext4_mb_complex_scan_group().
Fix the problem by checking for upper limit on power-of-two requests
directly when detecting them.
Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Larry Finger [Sat, 7 Oct 2017 22:37:45 +0000 (22:37 +0000)]
staging: rtl8712u: Fix endian settings for structs describing network packets
[ Upstream commit
221c46d28957bd6e2158abc2179ce4a8c9ce07d3 ]
The headers describing a number of network packets do not have the
correct endian settings for several types of data.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sat, 7 Oct 2017 22:37:44 +0000 (22:37 +0000)]
mfd: axp20x: Fix axp288 PEK_DBR and PEK_DBF irqs being swapped
[ Upstream commit
1af468ebe45591651ec3bafc2e9ddc6fdef70ae0 ]
The R in PEK_DBR stands for rising, so it should be mapped to
AXP288_IRQ_POKP where the last P stands for positive edge.
Likewise PEK_DBF should be mapped to the falling edge, aka the
_N_egative edge, so it should be mapped to AXP288_IRQ_POKN.
This fixes the inverted powerbutton status reporting by the
axp20x-pek driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Sat, 7 Oct 2017 22:37:44 +0000 (22:37 +0000)]
mfd: ab8500-sysctrl: Handle probe deferral
[ Upstream commit
7e9c40c63933a643908d686bd89dfc2315e8c70a ]
In the current boot, clients making use of the AB8500 sysctrl
may be probed before the ab8500-sysctrl driver. This gives them
-EINVAL, but should rather give -EPROBE_DEFER.
Before this, the abx500 clock driver didn't probe properly,
and as a result the codec driver in turn using the clocks did
not probe properly. After this patch, everything probes
properly.
Also add OF compatible-string probing. This driver is all
device tree, so let's just make a drive-by-fix of that as
well.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ulf Hansson [Sat, 7 Oct 2017 22:37:44 +0000 (22:37 +0000)]
ARM: pxa: Don't rely on public mmc header to include leds.h
[ Upstream commit
40d727a2defa176b78159d445bcf7afcc2ed9021 ]
Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.
Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Sat, 7 Oct 2017 22:37:44 +0000 (22:37 +0000)]
mmc: s3cmci: include linux/interrupt.h for tasklet_struct
[ Upstream commit
e1c6ec26b853e9062f0b3daaf695c546d0702953 ]
I got this new build error on today's linux-next
drivers/mmc/host/s3cmci.h:69:24: error: field 'pio_tasklet' has incomplete type
struct tasklet_struct pio_tasklet;
drivers/mmc/host/s3cmci.c: In function 's3cmci_enable_irq':
drivers/mmc/host/s3cmci.c:390:4: error: implicit declaration of function 'enable_irq';did you mean 'enable_imask'? [-Werror=implicit-function-declaration]
While I haven't found out why this happened now and not earlier, the
solution is obvious, we should include the header that defines
the structure.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grygorii Strashko [Sat, 7 Oct 2017 22:37:43 +0000 (22:37 +0000)]
PM / wakeirq: report a wakeup_event on dedicated wekup irq
[ Upstream commit
09bb6e93956ae5175b96905b723ec879c3ca0765 ]
There are two reasons for reporting wakeup event when dedicated wakeup
IRQ is triggered:
- wakeup events accounting, so proper statistical data will be
displayed in sysfs and debugfs;
- there are small window when System is entering suspend during which
dedicated wakeup IRQ can be lost:
dpm_suspend_noirq()
|- device_wakeup_arm_wake_irqs()
|- dev_pm_arm_wake_irq(X)
|- IRQ is enabled and marked as wakeup source
[1]...
|- suspend_device_irqs()
|- suspend_device_irq(X)
|- irqd_set(X, IRQD_WAKEUP_ARMED);
|- wakup IRQ armed
The wakeup IRQ can be lost if it's triggered at point [1]
and not armed yet.
Hence, fix above cases by adding simple pm_wakeup_event() call in
handle_threaded_wake_irq().
Fixes:
4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Keerthy <j-keerthy@ti.com>
[ tony@atomide.com: added missing return to avoid warnings ]
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Sat, 28 Oct 2017 03:35:31 +0000 (20:35 -0700)]
Fix tracing sample code warning.
commit
a0cb2b5c390151837b08e5f7bca4a6ecddbcd39c upstream.
Commit
6575257c60e1 ("tracing/samples: Fix creation and deletion of
simple_thread_fn creation") introduced a new warning due to using a
boolean as a counter.
Just make it "int".
Fixes:
6575257c60e1 ("tracing/samples: Fix creation and deletion of simple_thread_fn creation")
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (VMware) [Tue, 17 Oct 2017 18:55:24 +0000 (14:55 -0400)]
tracing/samples: Fix creation and deletion of simple_thread_fn creation
commit
6575257c60e1a26a5319ccf2b5ce5b6449001017 upstream.
Commit
7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and
DEFINE_EVENT()") added template examples for all the events. It created a
DEFINE_EVENT_FN() example which reused the foo_bar_reg and foo_bar_unreg
functions.
Enabling both the TRACE_EVENT_FN() and DEFINE_EVENT_FN() example trace
events caused the foo_bar_reg to be called twice, creating the test thread
twice. The foo_bar_unreg would remove it only once, even if it was called
multiple times, leaving a thread existing when the module is unloaded,
causing an oops.
Add a ref count and allow foo_bar_reg() and foo_bar_unreg() be called by
multiple trace events.
Fixes:
7496946a8 ("tracing: Add samples of DECLARE_EVENT_CLASS() and DEFINE_EVENT()")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 30 Jun 2017 07:59:15 +0000 (10:59 +0300)]
drm/msm: fix an integer overflow test
commit
65e93108891e571f177c202add9288eda9ac4100 upstream.
We recently added an integer overflow check but it needs an additional
tweak to work properly on 32 bit systems.
The problem is that we're doing the right hand side of the assignment as
type unsigned long so the max it will have an integer overflow instead
of being larger than SIZE_MAX. That means the "sz > SIZE_MAX" condition
is never true even on 32 bit systems. We need to first cast it to u64
and then do the math.
Fixes:
4a630fadbb29 ("drm/msm: Fix potential buffer overflow issue")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kasin Li [Mon, 19 Jun 2017 21:36:53 +0000 (15:36 -0600)]
drm/msm: Fix potential buffer overflow issue
commit
4a630fadbb29d9efaedb525f1a8f7449ad107641 upstream.
In function submit_create, if nr_cmds or nr_bos is assigned with
negative value, the allocated buffer may be small than intended.
Using this buffer will lead to buffer overflow issue.
Signed-off-by: Kasin Li <donglil@codeaurora.org>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Namhyung Kim [Tue, 2 Aug 2016 02:43:17 +0000 (11:43 +0900)]
perf tools: Fix build failure on perl script context
commit
b581c01fff646b5075d65359c8667de9c667da9e upstream.
On my Archlinux machine, perf faild to build like below:
CC scripts/perl/Perf-Trace-Util/Context.o
In file included from /usr/lib/perl5/core/perl/CORE/perl.h:3905:0,
from Context.xs:23:
/usr/lib/perl5/core/perl/CORE/inline.h: In function :
/usr/lib/perl5/core/perl/CORE/cop.h:612:13: warning: declaration of 'av'
shadows a previous local [-Werror-shadow]
AV *av =3D GvAV(PL_defgv);
^
/usr/lib/perl5/core/perl/CORE/inline.h:526:5: note: in expansion of
macro 'CX_POP_SAVEARRAY'
CX_POP_SAVEARRAY(cx);
^~~~~~~~~~~~~~~~
In file included from /usr/lib/perl5/core/perl/CORE/perl.h:5853:0,
from Context.xs:23:
/usr/lib/perl5/core/perl/CORE/inline.h:518:9: note:
shadowed declaration is here
AV *av;
^~
What I did to fix is adding '-Wno-shadow' as the error message said it's
the cause of the failure. Since it's from the perl (not perf) code
base, we don't have the control so I just wanted to ignore the warning
when compiling perl scripting code.
Committer note:
This also fixes the build on Fedora Rawhide.
Signed-off-by: Namhyung Kim <namhyung@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160802024317.31725-1-namhyung@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ashish Samant [Thu, 2 Nov 2017 22:59:37 +0000 (15:59 -0700)]
ocfs2: fstrim: Fix start offset of first cluster group during fstrim
commit
105ddc93f06ebe3e553f58563d11ed63dbcd59f0 upstream.
The first cluster group descriptor is not stored at the start of the
group but at an offset from the start. We need to take this into
account while doing fstrim on the first cluster group. Otherwise we
will wrongly start fstrim a few blocks after the desired start block and
the range can cross over into the next cluster group and zero out the
group descriptor there. This can cause filesytem corruption that cannot
be fixed by fsck.
Link: http://lkml.kernel.org/r/1507835579-7308-1-git-send-email-ashish.samant@oracle.com
Signed-off-by: Ashish Samant <ashish.samant@oracle.com>
Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
Cc: Mark Fasheh <mfasheh@versity.com>
Cc: Joel Becker <jlbec@evilplan.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>
Arnd Bergmann [Fri, 20 Oct 2017 20:17:05 +0000 (21:17 +0100)]
ARM: 8715/1: add a private asm/unaligned.h
commit
1cce91dfc8f7990ca3aea896bfb148f240b12860 upstream.
The asm-generic/unaligned.h header provides two different implementations
for accessing unaligned variables: the access_ok.h version used when
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is set pretends that all pointers
are in fact aligned, while the le_struct.h version convinces gcc that the
alignment of a pointer is '1', to make it issue the correct load/store
instructions depending on the architecture flags.
On ARMv5 and older, we always use the second version, to let the compiler
use byte accesses. On ARMv6 and newer, we currently use the access_ok.h
version, so the compiler can use any instruction including stm/ldm and
ldrd/strd that will cause an alignment trap. This trap can significantly
impact performance when we have to do a lot of fixups and, worse, has
led to crashes in the LZ4 decompressor code that does not have a trap
handler.
This adds an ARM specific version of asm/unaligned.h that uses the
le_struct.h/be_struct.h implementation unconditionally. This should lead
to essentially the same code on ARMv6+ as before, with the exception of
using regular load/store instructions instead of the trapping instructions
multi-register variants.
The crash in the LZ4 decompressor code was probably introduced by the
patch replacing the LZ4 implementation, commit
4e1a33b105dd ("lib: update
LZ4 compressor module"), so linux-4.11 and higher would be affected most.
However, we probably want to have this backported to all older stable
kernels as well, to help with the performance issues.
There are two follow-ups that I think we should also work on, but not
backport to stable kernels, first to change the asm-generic version of
the header to remove the ARM special case, and second to review all
other uses of CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS to see if they
might be affected by the same problem on ARM.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yan Markman [Sat, 15 Oct 2016 21:22:32 +0000 (00:22 +0300)]
ARM: dts: mvebu: pl310-cache disable double-linefill
commit
cda80a82ac3e89309706c027ada6ab232be1d640 upstream.
Under heavy system stress mvebu SoC using Cortex A9 sporadically
encountered instability issues.
The "double linefill" feature of L2 cache was identified as causing
dependency between read and write which lead to the deadlock.
Especially, it was the cause of deadlock seen under heavy PCIe traffic,
as this dependency violates PCIE overtaking rule.
Fixes:
c8f5a878e554 ("ARM: mvebu: use DT properties to fine-tune the L2 configuration")
Signed-off-by: Yan Markman <ymarkman@marvell.com>
Signed-off-by: Igal Liberman <igall@marvell.com>
Signed-off-by: Nadav Haklai <nadavh@marvell.com>
[gregory.clement@free-electrons.com: reformulate commit log, add Armada
375 and add Fixes tag]
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Thu, 2 Nov 2017 16:12:03 +0000 (16:12 +0000)]
arm64: ensure __dump_instr() checks addr_limit
commit
7a7003b1da010d2b0d1dc8bf21c10f5c73b389f1 upstream.
It's possible for a user to deliberately trigger __dump_instr with a
chosen kernel address.
Let's avoid problems resulting from this by using get_user() rather than
__get_user(), ensuring that we don't erroneously access kernel memory.
Where we use __dump_instr() on kernel text, we already switch to
KERNEL_DS, so this shouldn't adversely affect those cases.
Fixes:
60ffc30d5652810d ("arm64: Exception handling")
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ricard Wanderlof [Thu, 7 Sep 2017 13:31:38 +0000 (15:31 +0200)]
ASoC: adau17x1: Workaround for noise bug in ADC
commit
1e6f4fc06f6411adf98bbbe7fcd79442cd2b2a75 upstream.
The ADC in the ADAU1361 (and possibly other Analog Devices codecs)
exhibits a cyclic variation in the noise floor (in our test setup between
-87 and -93 dB), a new value being attained within this range whenever a
new capture stream is started. The cycle repeats after about 10 or 11
restarts.
The workaround recommended by the manufacturer is to toggle the ADOSR bit
in the Converter Control 0 register each time a new capture stream is
started.
I have verified that the patch fixes this problem on the ADAU1361, and
according to the manufacturer toggling the bit in question in this manner
will at least have no detrimental effect on other chips served by this
driver.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 2 Nov 2017 00:47:19 +0000 (00:47 +0000)]
KEYS: fix out-of-bounds read during ASN.1 parsing
commit
2eb9eabf1e868fda15808954fb29b0f105ed65f1 upstream.
syzkaller with KASAN reported an out-of-bounds read in
asn1_ber_decoder(). It can be reproduced by the following command,
assuming CONFIG_X509_CERTIFICATE_PARSER=y and CONFIG_KASAN=y:
keyctl add asymmetric desc $'\x30\x30' @s
The bug is that the length of an ASN.1 data value isn't validated in the
case where it is encoded using the short form, causing the decoder to
read past the end of the input buffer. Fix it by validating the length.
The bug report was:
BUG: KASAN: slab-out-of-bounds in asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
Read of size 1 at addr
ffff88003cccfa02 by task syz-executor0/6818
CPU: 1 PID: 6818 Comm: syz-executor0 Not tainted
4.14.0-rc7-00008-g5f479447d983 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xb3/0x10b lib/dump_stack.c:52
print_address_description+0x79/0x2a0 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351 [inline]
kasan_report+0x236/0x340 mm/kasan/report.c:409
__asan_report_load1_noabort+0x14/0x20 mm/kasan/report.c:427
asn1_ber_decoder+0x10cb/0x1730 lib/asn1_decoder.c:233
x509_cert_parse+0x1db/0x650 crypto/asymmetric_keys/x509_cert_parser.c:89
x509_key_preparse+0x64/0x7a0 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xcb/0x1a0 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x347/0xb20 security/keys/key.c:855
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0x1cd/0x340 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x447c89
RSP: 002b:
00007fca7a5d3bd8 EFLAGS:
00000246 ORIG_RAX:
00000000000000f8
RAX:
ffffffffffffffda RBX:
00007fca7a5d46cc RCX:
0000000000447c89
RDX:
0000000020006f4a RSI:
0000000020006000 RDI:
0000000020001ff5
RBP:
0000000000000046 R08:
fffffffffffffffd R09:
0000000000000000
R10:
0000000000000002 R11:
0000000000000246 R12:
0000000000000000
R13:
0000000000000000 R14:
00007fca7a5d49c0 R15:
00007fca7a5d4700
Fixes:
42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 2 Nov 2017 00:47:03 +0000 (00:47 +0000)]
KEYS: return full count in keyring_read() if buffer is too small
commit
3239b6f29bdfb4b0a2ba59df995fc9e6f4df7f1f upstream.
Commit
e645016abc80 ("KEYS: fix writing past end of user-supplied buffer
in keyring_read()") made keyring_read() stop corrupting userspace memory
when the user-supplied buffer is too small. However it also made the
return value in that case be the short buffer size rather than the size
required, yet keyctl_read() is actually documented to return the size
required. Therefore, switch it over to the documented behavior.
Note that for now we continue to have it fill the short buffer, since it
did that before (pre-v3.13) and dump_key_tree_aux() in keyutils arguably
relies on it.
Fixes:
e645016abc80 ("KEYS: fix writing past end of user-supplied buffer in keyring_read()")
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ronnie Sahlberg [Mon, 30 Oct 2017 02:28:03 +0000 (13:28 +1100)]
cifs: check MaxPathNameComponentLength != 0 before using it
commit
f74bc7c6679200a4a83156bb89cbf6c229fe8ec0 upstream.
And fix tcon leak in error path.
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: David Disseldorp <ddiss@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>