--- /dev/null
+From 08fe007968b2b45e831daf74899f79a54d73f773 Mon Sep 17 00:00:00 2001
+From: Vineet Gupta <vgupta@synopsys.com>
+Date: Mon, 19 Dec 2016 11:38:38 -0800
+Subject: ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcache
+
+From: Vineet Gupta <vgupta@synopsys.com>
+
+commit 08fe007968b2b45e831daf74899f79a54d73f773 upstream.
+
+An ARC700 customer reported linux boot crashes when upgrading to bigger
+L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and
+current code only assumed 2 colours, while theirs had 4. So default to 4
+colours and complain if there are fewer. Ideally this needs to be a
+Kconfig option, but heck that's too much of hassle for a single user.
+
+Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arc/include/asm/cacheflush.h | 6 ++++--
+ arch/arc/mm/cache.c | 11 ++++++++---
+ 2 files changed, 12 insertions(+), 5 deletions(-)
+
+--- a/arch/arc/include/asm/cacheflush.h
++++ b/arch/arc/include/asm/cacheflush.h
+@@ -85,6 +85,10 @@ void flush_anon_page(struct vm_area_stru
+ */
+ #define PG_dc_clean PG_arch_1
+
++#define CACHE_COLORS_NUM 4
++#define CACHE_COLORS_MSK (CACHE_COLORS_NUM - 1)
++#define CACHE_COLOR(addr) (((unsigned long)(addr) >> (PAGE_SHIFT)) & CACHE_COLORS_MSK)
++
+ /*
+ * Simple wrapper over config option
+ * Bootup code ensures that hardware matches kernel configuration
+@@ -94,8 +98,6 @@ static inline int cache_is_vipt_aliasing
+ return IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
+ }
+
+-#define CACHE_COLOR(addr) (((unsigned long)(addr) >> (PAGE_SHIFT)) & 1)
+-
+ /*
+ * checks if two addresses (after page aligning) index into same cache set
+ */
+--- a/arch/arc/mm/cache.c
++++ b/arch/arc/mm/cache.c
+@@ -960,11 +960,16 @@ void arc_cache_init(void)
+ /* check for D-Cache aliasing on ARCompact: ARCv2 has PIPT */
+ if (is_isa_arcompact()) {
+ int handled = IS_ENABLED(CONFIG_ARC_CACHE_VIPT_ALIASING);
++ int num_colors = dc->sz_k/dc->assoc/TO_KB(PAGE_SIZE);
+
+- if (dc->alias && !handled)
+- panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
+- else if (!dc->alias && handled)
++ if (dc->alias) {
++ if (!handled)
++ panic("Enable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
++ if (CACHE_COLORS_NUM != num_colors)
++ panic("CACHE_COLORS_NUM not optimized for config\n");
++ } else if (!dc->alias && handled) {
+ panic("Disable CONFIG_ARC_CACHE_VIPT_ALIASING\n");
++ }
+ }
+ }
+
--- /dev/null
+From af309226db916e2c6e08d3eba3fa5c34225200c4 Mon Sep 17 00:00:00 2001
+From: Rabin Vincent <rabinv@axis.com>
+Date: Thu, 1 Dec 2016 09:18:28 +0100
+Subject: block: protect iterate_bdevs() against concurrent close
+
+From: Rabin Vincent <rabinv@axis.com>
+
+commit af309226db916e2c6e08d3eba3fa5c34225200c4 upstream.
+
+If a block device is closed while iterate_bdevs() is handling it, the
+following NULL pointer dereference occurs because bdev->b_disk is NULL
+in bdev_get_queue(), which is called from blk_get_backing_dev_info() (in
+turn called by the mapping_cap_writeback_dirty() call in
+__filemap_fdatawrite_range()):
+
+ BUG: unable to handle kernel NULL pointer dereference at 0000000000000508
+ IP: [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
+ PGD 9e62067 PUD 9ee8067 PMD 0
+ Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
+ Modules linked in:
+ CPU: 1 PID: 2422 Comm: sync Not tainted 4.5.0-rc7+ #400
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
+ task: ffff880009f4d700 ti: ffff880009f5c000 task.ti: ffff880009f5c000
+ RIP: 0010:[<ffffffff81314790>] [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
+ RSP: 0018:ffff880009f5fe68 EFLAGS: 00010246
+ RAX: 0000000000000000 RBX: ffff88000ec17a38 RCX: ffffffff81a4e940
+ RDX: 7fffffffffffffff RSI: 0000000000000000 RDI: ffff88000ec176c0
+ RBP: ffff880009f5fe68 R08: 0000000000000000 R09: 0000000000000000
+ R10: 0000000000000001 R11: 0000000000000000 R12: ffff88000ec17860
+ R13: ffffffff811b25c0 R14: ffff88000ec178e0 R15: ffff88000ec17a38
+ FS: 00007faee505d700(0000) GS:ffff88000fb00000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
+ CR2: 0000000000000508 CR3: 0000000009e8a000 CR4: 00000000000006e0
+ Stack:
+ ffff880009f5feb8 ffffffff8112e7f5 0000000000000000 7fffffffffffffff
+ 0000000000000000 0000000000000000 7fffffffffffffff 0000000000000001
+ ffff88000ec178e0 ffff88000ec17860 ffff880009f5fec8 ffffffff8112e81f
+ Call Trace:
+ [<ffffffff8112e7f5>] __filemap_fdatawrite_range+0x85/0x90
+ [<ffffffff8112e81f>] filemap_fdatawrite+0x1f/0x30
+ [<ffffffff811b25d6>] fdatawrite_one_bdev+0x16/0x20
+ [<ffffffff811bc402>] iterate_bdevs+0xf2/0x130
+ [<ffffffff811b2763>] sys_sync+0x63/0x90
+ [<ffffffff815d4272>] entry_SYSCALL_64_fastpath+0x12/0x76
+ Code: 0f 1f 44 00 00 48 8b 87 f0 00 00 00 55 48 89 e5 <48> 8b 80 08 05 00 00 5d
+ RIP [<ffffffff81314790>] blk_get_backing_dev_info+0x10/0x20
+ RSP <ffff880009f5fe68>
+ CR2: 0000000000000508
+ ---[ end trace 2487336ceb3de62d ]---
+
+The crash is easily reproducible by running the following command, if an
+msleep(100) is inserted before the call to func() in iterate_devs():
+
+ while :; do head -c1 /dev/nullb0; done > /dev/null & while :; do sync; done
+
+Fix it by holding the bd_mutex across the func() call and only calling
+func() if the bdev is opened.
+
+Fixes: 5c0d6b60a0ba ("vfs: Create function for iterating over block devices")
+Reported-and-tested-by: Wei Fang <fangwei1@huawei.com>
+Signed-off-by: Rabin Vincent <rabinv@axis.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/block_dev.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/fs/block_dev.c
++++ b/fs/block_dev.c
+@@ -1806,6 +1806,7 @@ void iterate_bdevs(void (*func)(struct b
+ spin_lock(&blockdev_superblock->s_inode_list_lock);
+ list_for_each_entry(inode, &blockdev_superblock->s_inodes, i_sb_list) {
+ struct address_space *mapping = inode->i_mapping;
++ struct block_device *bdev;
+
+ spin_lock(&inode->i_lock);
+ if (inode->i_state & (I_FREEING|I_WILL_FREE|I_NEW) ||
+@@ -1826,8 +1827,12 @@ void iterate_bdevs(void (*func)(struct b
+ */
+ iput(old_inode);
+ old_inode = inode;
++ bdev = I_BDEV(inode);
+
+- func(I_BDEV(inode), arg);
++ mutex_lock(&bdev->bd_mutex);
++ if (bdev->bd_openers)
++ func(bdev, arg);
++ mutex_unlock(&bdev->bd_mutex);
+
+ spin_lock(&blockdev_superblock->s_inode_list_lock);
+ }
--- /dev/null
+From 794de08a16cf1fc1bf785dc48f66d36218cf6d88 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+Date: Thu, 8 Dec 2016 20:54:49 -0500
+Subject: fgraph: Handle a case where a tracer ignores set_graph_notrace
+
+From: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
+
+commit 794de08a16cf1fc1bf785dc48f66d36218cf6d88 upstream.
+
+Both the wakeup and irqsoff tracers can use the function graph tracer when
+the display-graph option is set. The problem is that they ignore the notrace
+file, and record the entry of functions that would be ignored by the
+function_graph tracer. This causes the trace->depth to be recorded into the
+ring buffer. The set_graph_notrace uses a trick by adding a large negative
+number to the trace->depth when a graph function is to be ignored.
+
+On trace output, the graph function uses the depth to record a stack of
+functions. But since the depth is negative, it accesses the array with a
+negative number and causes an out of bounds access that can cause a kernel
+oops or corrupt data.
+
+Have the print functions handle cases where a tracer still records functions
+even when they are in set_graph_notrace.
+
+Also add warnings if the depth is below zero before accessing the array.
+
+Note, the function graph logic will still prevent the return of these
+functions from being recorded, which means that they will be left hanging
+without a return. For example:
+
+ # echo '*spin*' > set_graph_notrace
+ # echo 1 > options/display-graph
+ # echo wakeup > current_tracer
+ # cat trace
+ [...]
+ _raw_spin_lock() {
+ preempt_count_add() {
+ do_raw_spin_lock() {
+ update_rq_clock();
+
+Where it should look like:
+
+ _raw_spin_lock() {
+ preempt_count_add();
+ do_raw_spin_lock();
+ }
+ update_rq_clock();
+
+Cc: Namhyung Kim <namhyung.kim@lge.com>
+Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter")
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_functions_graph.c | 17 ++++++++++++++---
+ 1 file changed, 14 insertions(+), 3 deletions(-)
+
+--- a/kernel/trace/trace_functions_graph.c
++++ b/kernel/trace/trace_functions_graph.c
+@@ -780,6 +780,10 @@ print_graph_entry_leaf(struct trace_iter
+
+ cpu_data = per_cpu_ptr(data->cpu_data, cpu);
+
++ /* If a graph tracer ignored set_graph_notrace */
++ if (call->depth < -1)
++ call->depth += FTRACE_NOTRACE_DEPTH;
++
+ /*
+ * Comments display at + 1 to depth. Since
+ * this is a leaf function, keep the comments
+@@ -788,7 +792,8 @@ print_graph_entry_leaf(struct trace_iter
+ cpu_data->depth = call->depth - 1;
+
+ /* No need to keep this function around for this depth */
+- if (call->depth < FTRACE_RETFUNC_DEPTH)
++ if (call->depth < FTRACE_RETFUNC_DEPTH &&
++ !WARN_ON_ONCE(call->depth < 0))
+ cpu_data->enter_funcs[call->depth] = 0;
+ }
+
+@@ -818,11 +823,16 @@ print_graph_entry_nested(struct trace_it
+ struct fgraph_cpu_data *cpu_data;
+ int cpu = iter->cpu;
+
++ /* If a graph tracer ignored set_graph_notrace */
++ if (call->depth < -1)
++ call->depth += FTRACE_NOTRACE_DEPTH;
++
+ cpu_data = per_cpu_ptr(data->cpu_data, cpu);
+ cpu_data->depth = call->depth;
+
+ /* Save this function pointer to see if the exit matches */
+- if (call->depth < FTRACE_RETFUNC_DEPTH)
++ if (call->depth < FTRACE_RETFUNC_DEPTH &&
++ !WARN_ON_ONCE(call->depth < 0))
+ cpu_data->enter_funcs[call->depth] = call->func;
+ }
+
+@@ -1052,7 +1062,8 @@ print_graph_return(struct ftrace_graph_r
+ */
+ cpu_data->depth = trace->depth - 1;
+
+- if (trace->depth < FTRACE_RETFUNC_DEPTH) {
++ if (trace->depth < FTRACE_RETFUNC_DEPTH &&
++ !WARN_ON_ONCE(trace->depth < 0)) {
+ if (cpu_data->enter_funcs[trace->depth] != trace->func)
+ func_match = 0;
+ cpu_data->enter_funcs[trace->depth] = 0;
--- /dev/null
+From 2e700f8d85975f516ccaad821278c1fe66b2cc98 Mon Sep 17 00:00:00 2001
+From: Yves-Alexis Perez <corsac@corsac.net>
+Date: Fri, 11 Nov 2016 11:28:40 -0800
+Subject: firmware: fix usermode helper fallback loading
+
+From: Yves-Alexis Perez <corsac@corsac.net>
+
+commit 2e700f8d85975f516ccaad821278c1fe66b2cc98 upstream.
+
+When you use the firmware usermode helper fallback with a timeout value set to a
+value greater than INT_MAX (2147483647) a cast overflow issue causes the
+timeout value to go negative and breaks all usermode helper loading. This
+regression was introduced through commit 68ff2a00dbf5 ("firmware_loader:
+handle timeout via wait_for_completion_interruptible_timeout()") on kernel
+v4.0.
+
+The firmware_class drivers relies on the firmware usermode helper
+fallback as a mechanism to look for firmware if the direct filesystem
+search failed only if:
+
+ a) You've enabled CONFIG_FW_LOADER_USER_HELPER_FALLBACK (not many distros):
+
+ Then all of these callers will rely on the fallback mechanism in case
+ the firmware is not found through an initial direct filesystem lookup:
+
+ o request_firmware()
+ o request_firmware_into_buf()
+ o request_firmware_nowait()
+
+ b) If you've only enabled CONFIG_FW_LOADER_USER_HELPER (most distros):
+
+ Then only callers using request_firmware_nowait() with the second
+ argument set to false, this explicitly is requesting the UMH firmware
+ fallback to be relied on in case the first filesystem lookup fails.
+
+ Using Coccinelle SmPL grammar we have identified only two drivers
+ explicitly requesting the UMH firmware fallback mechanism:
+
+ - drivers/firmware/dell_rbu.c
+ - drivers/leds/leds-lp55xx-common.c
+
+Since most distributions only enable CONFIG_FW_LOADER_USER_HELPER the
+biggest impact of this regression are users of the dell_rbu and
+leds-lp55xx-common device driver which required the UMH to find their
+respective needed firmwares.
+
+The default timeout for the UMH is set to 60 seconds always, as of
+commit 68ff2a00dbf5 ("firmware_loader: handle timeout via
+wait_for_completion_interruptible_timeout()") the timeout was bumped
+to MAX_JIFFY_OFFSET ((LONG_MAX >> 1)-1). Additionally the MAX_JIFFY_OFFSET
+value was also used if the timeout was configured by a user to 0.
+
+The following works:
+
+echo 2147483647 > /sys/class/firmware/timeout
+
+But both of the following set the timeout to MAX_JIFFY_OFFSET even if
+we display 0 back to userspace:
+
+echo 2147483648 > /sys/class/firmware/timeout
+cat /sys/class/firmware/timeout
+0
+
+echo 0> /sys/class/firmware/timeout
+cat /sys/class/firmware/timeout
+0
+
+A max value of INT_MAX (2147483647) seconds is therefore implicit due to the
+another cast with simple_strtol().
+
+This fixes the secondary cast (the first one is simple_strtol() but its an
+issue only by forcing an implicit limit) by re-using the timeout variable and
+only setting retval in appropriate cases.
+
+Lastly worth noting systemd had ripped out the UMH firmware fallback
+mechanism from udev since udev 2014 via commit be2ea723b1d023b3d
+("udev: remove userspace firmware loading support"), so as of systemd v217.
+
+Signed-off-by: Yves-Alexis Perez <corsac@corsac.net>
+Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()"
+Cc: Luis R. Rodriguez <mcgrof@kernel.org>
+Cc: Ming Lei <ming.lei@canonical.com>
+Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
+Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Acked-by: Luis R. Rodriguez <mcgrof@kernel.org>
+Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
+[mcgrof@kernel.org: gave commit log a whole lot of love]
+Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/base/firmware_class.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/base/firmware_class.c
++++ b/drivers/base/firmware_class.c
+@@ -942,13 +942,14 @@ static int _request_firmware_load(struct
+ timeout = MAX_JIFFY_OFFSET;
+ }
+
+- retval = wait_for_completion_interruptible_timeout(&buf->completion,
++ timeout = wait_for_completion_interruptible_timeout(&buf->completion,
+ timeout);
+- if (retval == -ERESTARTSYS || !retval) {
++ if (timeout == -ERESTARTSYS || !timeout) {
++ retval = timeout;
+ mutex_lock(&fw_lock);
+ fw_load_abort(fw_priv);
+ mutex_unlock(&fw_lock);
+- } else if (retval > 0) {
++ } else if (timeout > 0) {
+ retval = 0;
+ }
+
--- /dev/null
+From 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Red Hat)" <rostedt@goodmis.org>
+Date: Thu, 8 Dec 2016 12:48:26 -0500
+Subject: ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it
+
+From: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
+
+commit 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 upstream.
+
+With new binutils, gcc may get smart with its optimization and change a jmp
+from a 5 byte jump to a 2 byte one even though it was jumping to a global
+function. But that global function existed within a 2 byte radius, and gcc
+was able to optimize it. Unfortunately, that jump was also being modified
+when function graph tracing begins. Since ftrace expected that jump to be 5
+bytes, but it was only two, it overwrote code after the jump, causing a
+crash.
+
+This was fixed for x86_64 with commit 8329e818f149, with the same subject as
+this commit, but nothing was done for x86_32.
+
+Fixes: d61f82d06672 ("ftrace: use dynamic patching for updating mcount calls")
+Reported-by: Colin Ian King <colin.king@canonical.com>
+Tested-by: Colin Ian King <colin.king@canonical.com>
+Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/entry/entry_32.S | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/entry/entry_32.S
++++ b/arch/x86/entry/entry_32.S
+@@ -766,8 +766,8 @@ ftrace_graph_call:
+ jmp ftrace_stub
+ #endif
+
+-.globl ftrace_stub
+-ftrace_stub:
++/* This is weak to keep gas from relaxing the jumps */
++WEAK(ftrace_stub)
+ ret
+ END(ftrace_caller)
+
--- /dev/null
+From fba332b079029c2f4f7e84c1c1cd8e3867310c90 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+Date: Mon, 19 Dec 2016 18:00:05 +0100
+Subject: IB/cma: Fix a race condition in iboe_addr_get_sgid()
+
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+
+commit fba332b079029c2f4f7e84c1c1cd8e3867310c90 upstream.
+
+Code that dereferences the struct net_device ip_ptr member must be
+protected with an in_dev_get() / in_dev_put() pair. Hence insert
+calls to these functions.
+
+Fixes: commit 7b85627b9f02 ("IB/cma: IBoE (RoCE) IP-based GID addressing")
+Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
+Reviewed-by: Moni Shoua <monis@mellanox.com>
+Cc: Or Gerlitz <ogerlitz@mellanox.com>
+Cc: Roland Dreier <roland@purestorage.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/rdma/ib_addr.h | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/include/rdma/ib_addr.h
++++ b/include/rdma/ib_addr.h
+@@ -197,10 +197,12 @@ static inline void iboe_addr_get_sgid(st
+
+ dev = dev_get_by_index(&init_net, dev_addr->bound_dev_if);
+ if (dev) {
+- ip4 = (struct in_device *)dev->ip_ptr;
+- if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address)
++ ip4 = in_dev_get(dev);
++ if (ip4 && ip4->ifa_list && ip4->ifa_list->ifa_address) {
+ ipv6_addr_set_v4mapped(ip4->ifa_list->ifa_address,
+ (struct in6_addr *)gid);
++ in_dev_put(ip4);
++ }
+ dev_put(dev);
+ }
+ }
--- /dev/null
+From 2fe2f378dd45847d2643638c07a7658822087836 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+Date: Mon, 21 Nov 2016 10:21:17 -0800
+Subject: IB/mad: Fix an array index check
+
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+
+commit 2fe2f378dd45847d2643638c07a7658822087836 upstream.
+
+The array ib_mad_mgmt_class_table.method_table has MAX_MGMT_CLASS
+(80) elements. Hence compare the array index with that value instead
+of with IB_MGMT_MAX_METHODS (128). This patch avoids that Coverity
+reports the following:
+
+Overrunning array class->method_table of 80 8-byte elements at element index 127 (byte offset 1016) using index convert_mgmt_class(mad_hdr->mgmt_class) (which evaluates to 127).
+
+Fixes: commit b7ab0b19a85f ("IB/mad: Verify mgmt class in received MADs")
+Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
+Cc: Sean Hefty <sean.hefty@intel.com>
+Reviewed-by: Hal Rosenstock <hal@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/mad.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/infiniband/core/mad.c
++++ b/drivers/infiniband/core/mad.c
+@@ -1745,7 +1745,7 @@ find_mad_agent(struct ib_mad_port_privat
+ if (!class)
+ goto out;
+ if (convert_mgmt_class(mad_hdr->mgmt_class) >=
+- IB_MGMT_MAX_METHODS)
++ ARRAY_SIZE(class->method_table))
+ goto out;
+ method = class->method_table[convert_mgmt_class(
+ mad_hdr->mgmt_class)];
--- /dev/null
+From d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+Date: Mon, 21 Nov 2016 10:22:17 -0800
+Subject: IB/multicast: Check ib_find_pkey() return value
+
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+
+commit d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 upstream.
+
+This patch avoids that Coverity complains about not checking the
+ib_find_pkey() return value.
+
+Fixes: commit 547af76521b3 ("IB/multicast: Report errors on multicast groups if P_key changes")
+Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
+Cc: Sean Hefty <sean.hefty@intel.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/multicast.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/core/multicast.c
++++ b/drivers/infiniband/core/multicast.c
+@@ -517,8 +517,11 @@ static void join_handler(int status, str
+ process_join_error(group, status);
+ else {
+ int mgids_changed, is_mgid0;
+- ib_find_pkey(group->port->dev->device, group->port->port_num,
+- be16_to_cpu(rec->pkey), &pkey_index);
++
++ if (ib_find_pkey(group->port->dev->device,
++ group->port->port_num, be16_to_cpu(rec->pkey),
++ &pkey_index))
++ pkey_index = MCAST_INVALID_PKEY_INDEX;
+
+ spin_lock_irq(&group->port->lock);
+ if (group->state == MCAST_BUSY &&
--- /dev/null
+From 5a8a6b89c15766446d845671d574a9243b6d8786 Mon Sep 17 00:00:00 2001
+From: Jingkui Wang <jkwang@google.com>
+Date: Mon, 12 Dec 2016 13:51:46 -0800
+Subject: Input: drv260x - fix input device's parent assignment
+
+From: Jingkui Wang <jkwang@google.com>
+
+commit 5a8a6b89c15766446d845671d574a9243b6d8786 upstream.
+
+We were assigning I2C bus controller instead of client as parent device.
+Besides being logically wrong, it messed up with devm handling of input
+device. As a result we were leaving input device and event node behind
+after rmmod-ing the driver, which lead to a kernel oops if one were to
+access the event node later.
+
+Let's remove the assignment and rely on devm_input_allocate_device() to
+set it up properly for us.
+
+Signed-off-by: Jingkui Wang <jkwang@google.com>
+Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver")
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/misc/drv260x.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/input/misc/drv260x.c
++++ b/drivers/input/misc/drv260x.c
+@@ -592,7 +592,6 @@ static int drv260x_probe(struct i2c_clie
+ }
+
+ haptics->input_dev->name = "drv260x:haptics";
+- haptics->input_dev->dev.parent = client->dev.parent;
+ haptics->input_dev->close = drv260x_close;
+ input_set_drvdata(haptics->input_dev, haptics);
+ input_set_capability(haptics->input_dev, EV_FF, FF_RUMBLE);
--- /dev/null
+From 11b642b84e8c43e8597de031678d15c08dd057bc Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+Date: Mon, 21 Nov 2016 10:21:41 -0800
+Subject: IPoIB: Avoid reading an uninitialized member variable
+
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+
+commit 11b642b84e8c43e8597de031678d15c08dd057bc upstream.
+
+This patch avoids that Coverity reports the following:
+
+ Using uninitialized value port_attr.state when calling printk
+
+Fixes: commit 94232d9ce817 ("IPoIB: Start multicast join process only on active ports")
+Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
+Cc: Erez Shitrit <erezsh@mellanox.com>
+Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/ulp/ipoib/ipoib_multicast.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
++++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+@@ -563,8 +563,11 @@ void ipoib_mcast_join_task(struct work_s
+ if (!test_bit(IPOIB_FLAG_OPER_UP, &priv->flags))
+ return;
+
+- if (ib_query_port(priv->ca, priv->port, &port_attr) ||
+- port_attr.state != IB_PORT_ACTIVE) {
++ if (ib_query_port(priv->ca, priv->port, &port_attr)) {
++ ipoib_dbg(priv, "ib_query_port() failed\n");
++ return;
++ }
++ if (port_attr.state != IB_PORT_ACTIVE) {
+ ipoib_dbg(priv, "port state is not ACTIVE (state = %d) suspending join task\n",
+ port_attr.state);
+ return;
--- /dev/null
+From ef85b67385436ddc1998f45f1d6a210f935b3388 Mon Sep 17 00:00:00 2001
+From: Jim Mattson <jmattson@google.com>
+Date: Mon, 12 Dec 2016 11:01:37 -0800
+Subject: kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
+
+From: Jim Mattson <jmattson@google.com>
+
+commit ef85b67385436ddc1998f45f1d6a210f935b3388 upstream.
+
+When L2 exits to L0 due to "exception or NMI", software exceptions
+(#BP and #OF) for which L1 has requested an intercept should be
+handled by L1 rather than L0. Previously, only hardware exceptions
+were forwarded to L1.
+
+Signed-off-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -1247,10 +1247,10 @@ static inline bool nested_cpu_has_posted
+ return vmcs12->pin_based_vm_exec_control & PIN_BASED_POSTED_INTR;
+ }
+
+-static inline bool is_exception(u32 intr_info)
++static inline bool is_nmi(u32 intr_info)
+ {
+ return (intr_info & (INTR_INFO_INTR_TYPE_MASK | INTR_INFO_VALID_MASK))
+- == (INTR_TYPE_HARD_EXCEPTION | INTR_INFO_VALID_MASK);
++ == (INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK);
+ }
+
+ static void nested_vmx_vmexit(struct kvm_vcpu *vcpu, u32 exit_reason,
+@@ -5234,7 +5234,7 @@ static int handle_exception(struct kvm_v
+ if (is_machine_check(intr_info))
+ return handle_machine_check(vcpu);
+
+- if ((intr_info & INTR_INFO_INTR_TYPE_MASK) == INTR_TYPE_NMI_INTR)
++ if (is_nmi(intr_info))
+ return 1; /* already handled by vmx_vcpu_run() */
+
+ if (is_no_device(intr_info)) {
+@@ -7722,7 +7722,7 @@ static bool nested_vmx_exit_handled(stru
+
+ switch (exit_reason) {
+ case EXIT_REASON_EXCEPTION_NMI:
+- if (!is_exception(intr_info))
++ if (is_nmi(intr_info))
+ return false;
+ else if (is_page_fault(intr_info))
+ return enable_ept;
+@@ -8329,8 +8329,7 @@ static void vmx_complete_atomic_exit(str
+ kvm_machine_check();
+
+ /* We need to handle NMIs before interrupts are enabled */
+- if ((exit_intr_info & INTR_INFO_INTR_TYPE_MASK) == INTR_TYPE_NMI_INTR &&
+- (exit_intr_info & INTR_INFO_VALID_MASK)) {
++ if (is_nmi(exit_intr_info)) {
+ kvm_before_handle_nmi(&vmx->vcpu);
+ asm("int $2");
+ kvm_after_handle_nmi(&vmx->vcpu);
--- /dev/null
+From f064a0de1579fabded8990bed93971e30deb9ecb Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Wed, 16 Nov 2016 16:43:28 +1100
+Subject: KVM: PPC: Book3S HV: Don't lose hardware R/C bit updates in H_PROTECT
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit f064a0de1579fabded8990bed93971e30deb9ecb upstream.
+
+The hashed page table MMU in POWER processors can update the R
+(reference) and C (change) bits in a HPTE at any time until the
+HPTE has been invalidated and the TLB invalidation sequence has
+completed. In kvmppc_h_protect, which implements the H_PROTECT
+hypercall, we read the HPTE, modify the second doubleword,
+invalidate the HPTE in memory, do the TLB invalidation sequence,
+and then write the modified value of the second doubleword back
+to memory. In doing so we could overwrite an R/C bit update done
+by hardware between when we read the HPTE and when the TLB
+invalidation completed. To fix this we re-read the second
+doubleword after the TLB invalidation and OR in the (possibly)
+new values of R and C. We can use an OR since hardware only ever
+sets R and C, never clears them.
+
+This race was found by code inspection. In principle this bug could
+cause occasional guest memory corruption under host memory pressure.
+
+Fixes: a8606e20e41a ("KVM: PPC: Handle some PAPR hcalls in the kernel", 2011-06-29)
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_hv_rm_mmu.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
++++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+@@ -653,6 +653,8 @@ long kvmppc_h_protect(struct kvm_vcpu *v
+ HPTE_V_ABSENT);
+ do_tlbies(kvm, &rb, 1, global_invalidates(kvm, flags),
+ true);
++ /* Don't lose R/C bit updates done by hardware */
++ r |= be64_to_cpu(hpte[1]) & (HPTE_R_R | HPTE_R_C);
+ hpte[1] = cpu_to_be64(r);
+ }
+ }
--- /dev/null
+From 0d808df06a44200f52262b6eb72bcb6042f5a7c5 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Mon, 7 Nov 2016 15:09:58 +1100
+Subject: KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 0d808df06a44200f52262b6eb72bcb6042f5a7c5 upstream.
+
+When switching from/to a guest that has a transaction in progress,
+we need to save/restore the checkpointed register state. Although
+XER is part of the CPU state that gets checkpointed, the code that
+does this saving and restoring doesn't save/restore XER.
+
+This fixes it by saving and restoring the XER. To allow userspace
+to read/write the checkpointed XER value, we also add a new ONE_REG
+specifier.
+
+The visible effect of this bug is that the guest may see its XER
+value being corrupted when it uses transactions.
+
+Fixes: e4e38121507a ("KVM: PPC: Book3S HV: Add transactional memory support")
+Fixes: 0a8eccefcb34 ("KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit")
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Reviewed-by: Thomas Huth <thuth@redhat.com>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ Documentation/virtual/kvm/api.txt | 1 +
+ arch/powerpc/include/asm/kvm_host.h | 1 +
+ arch/powerpc/include/uapi/asm/kvm.h | 1 +
+ arch/powerpc/kernel/asm-offsets.c | 1 +
+ arch/powerpc/kvm/book3s_hv.c | 6 ++++++
+ arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 ++++
+ 6 files changed, 14 insertions(+)
+
+--- a/Documentation/virtual/kvm/api.txt
++++ b/Documentation/virtual/kvm/api.txt
+@@ -1991,6 +1991,7 @@ registers, find a list below:
+ PPC | KVM_REG_PPC_TM_VSCR | 32
+ PPC | KVM_REG_PPC_TM_DSCR | 64
+ PPC | KVM_REG_PPC_TM_TAR | 64
++ PPC | KVM_REG_PPC_TM_XER | 64
+ | |
+ MIPS | KVM_REG_MIPS_R0 | 64
+ ...
+--- a/arch/powerpc/include/asm/kvm_host.h
++++ b/arch/powerpc/include/asm/kvm_host.h
+@@ -545,6 +545,7 @@ struct kvm_vcpu_arch {
+ u64 tfiar;
+
+ u32 cr_tm;
++ u64 xer_tm;
+ u64 lr_tm;
+ u64 ctr_tm;
+ u64 amr_tm;
+--- a/arch/powerpc/include/uapi/asm/kvm.h
++++ b/arch/powerpc/include/uapi/asm/kvm.h
+@@ -587,6 +587,7 @@ struct kvm_get_htab_header {
+ #define KVM_REG_PPC_TM_VSCR (KVM_REG_PPC_TM | KVM_REG_SIZE_U32 | 0x67)
+ #define KVM_REG_PPC_TM_DSCR (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x68)
+ #define KVM_REG_PPC_TM_TAR (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x69)
++#define KVM_REG_PPC_TM_XER (KVM_REG_PPC_TM | KVM_REG_SIZE_U64 | 0x6a)
+
+ /* PPC64 eXternal Interrupt Controller Specification */
+ #define KVM_DEV_XICS_GRP_SOURCES 1 /* 64-bit source attributes */
+--- a/arch/powerpc/kernel/asm-offsets.c
++++ b/arch/powerpc/kernel/asm-offsets.c
+@@ -584,6 +584,7 @@ int main(void)
+ DEFINE(VCPU_VRS_TM, offsetof(struct kvm_vcpu, arch.vr_tm.vr));
+ DEFINE(VCPU_VRSAVE_TM, offsetof(struct kvm_vcpu, arch.vrsave_tm));
+ DEFINE(VCPU_CR_TM, offsetof(struct kvm_vcpu, arch.cr_tm));
++ DEFINE(VCPU_XER_TM, offsetof(struct kvm_vcpu, arch.xer_tm));
+ DEFINE(VCPU_LR_TM, offsetof(struct kvm_vcpu, arch.lr_tm));
+ DEFINE(VCPU_CTR_TM, offsetof(struct kvm_vcpu, arch.ctr_tm));
+ DEFINE(VCPU_AMR_TM, offsetof(struct kvm_vcpu, arch.amr_tm));
+--- a/arch/powerpc/kvm/book3s_hv.c
++++ b/arch/powerpc/kvm/book3s_hv.c
+@@ -1186,6 +1186,9 @@ static int kvmppc_get_one_reg_hv(struct
+ case KVM_REG_PPC_TM_CR:
+ *val = get_reg_val(id, vcpu->arch.cr_tm);
+ break;
++ case KVM_REG_PPC_TM_XER:
++ *val = get_reg_val(id, vcpu->arch.xer_tm);
++ break;
+ case KVM_REG_PPC_TM_LR:
+ *val = get_reg_val(id, vcpu->arch.lr_tm);
+ break;
+@@ -1393,6 +1396,9 @@ static int kvmppc_set_one_reg_hv(struct
+ case KVM_REG_PPC_TM_CR:
+ vcpu->arch.cr_tm = set_reg_val(id, *val);
+ break;
++ case KVM_REG_PPC_TM_XER:
++ vcpu->arch.xer_tm = set_reg_val(id, *val);
++ break;
+ case KVM_REG_PPC_TM_LR:
+ vcpu->arch.lr_tm = set_reg_val(id, *val);
+ break;
+--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
++++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+@@ -2514,11 +2514,13 @@ kvmppc_save_tm:
+ mfctr r7
+ mfspr r8, SPRN_AMR
+ mfspr r10, SPRN_TAR
++ mfxer r11
+ std r5, VCPU_LR_TM(r9)
+ stw r6, VCPU_CR_TM(r9)
+ std r7, VCPU_CTR_TM(r9)
+ std r8, VCPU_AMR_TM(r9)
+ std r10, VCPU_TAR_TM(r9)
++ std r11, VCPU_XER_TM(r9)
+
+ /* Restore r12 as trap number. */
+ lwz r12, VCPU_TRAP(r9)
+@@ -2611,11 +2613,13 @@ kvmppc_restore_tm:
+ ld r7, VCPU_CTR_TM(r4)
+ ld r8, VCPU_AMR_TM(r4)
+ ld r9, VCPU_TAR_TM(r4)
++ ld r10, VCPU_XER_TM(r4)
+ mtlr r5
+ mtcr r6
+ mtctr r7
+ mtspr SPRN_AMR, r8
+ mtspr SPRN_TAR, r9
++ mtxer r10
+
+ /*
+ * Load up PPR and DSCR values but don't put them in the actual SPRs
--- /dev/null
+From e8d7c33232e5fdfa761c3416539bc5b4acd12db5 Mon Sep 17 00:00:00 2001
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Date: Sun, 27 Nov 2016 19:32:32 +0300
+Subject: md/raid5: limit request size according to implementation limits
+
+From: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+
+commit e8d7c33232e5fdfa761c3416539bc5b4acd12db5 upstream.
+
+Current implementation employ 16bit counter of active stripes in lower
+bits of bio->bi_phys_segments. If request is big enough to overflow
+this counter bio will be completed and freed too early.
+
+Fortunately this not happens in default configuration because several
+other limits prevent that: stripe_cache_size * nr_disks effectively
+limits count of active stripes. And small max_sectors_kb at lower
+disks prevent that during normal read/write operations.
+
+Overflow easily happens in discard if it's enabled by module parameter
+"devices_handle_discard_safely" and stripe_cache_size is set big enough.
+
+This patch limits requests size with 256Mb - 8Kb to prevent overflows.
+
+Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
+Cc: Shaohua Li <shli@kernel.org>
+Cc: Neil Brown <neilb@suse.com>
+Signed-off-by: Shaohua Li <shli@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/raid5.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/md/raid5.c
++++ b/drivers/md/raid5.c
+@@ -6980,6 +6980,15 @@ static int run(struct mddev *mddev)
+ stripe = (stripe | (stripe-1)) + 1;
+ mddev->queue->limits.discard_alignment = stripe;
+ mddev->queue->limits.discard_granularity = stripe;
++
++ /*
++ * We use 16-bit counter of active stripes in bi_phys_segments
++ * (minus one for over-loaded initialization)
++ */
++ blk_queue_max_hw_sectors(mddev->queue, 0xfffe * STRIPE_SECTORS);
++ blk_queue_max_discard_sectors(mddev->queue,
++ 0xfffe * STRIPE_SECTORS);
++
+ /*
+ * unaligned part of discard request will be ignored, so can't
+ * guarantee discard_zeroes_data
--- /dev/null
+From 5fc4b067ec082c3127e0156f800769b7e0dce078 Mon Sep 17 00:00:00 2001
+From: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
+Date: Sat, 22 Oct 2016 13:34:36 -0200
+Subject: [media] media: solo6x10: fix lockup by avoiding delayed register write
+
+From: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
+
+commit 5fc4b067ec082c3127e0156f800769b7e0dce078 upstream.
+
+This fixes a lockup at device probing which happens on some solo6010
+hardware samples. This is a regression introduced by commit e1ceb25a1569
+("[media] SOLO6x10: remove unneeded register locking and barriers")
+
+The observed lockup happens in solo_set_motion_threshold() called from
+solo_motion_config().
+
+This extra "flushing" is not fundamentally needed for every write, but
+apparently the code in driver assumes such behaviour at last in some
+places.
+
+Actual fix was proposed by Hans Verkuil.
+
+Fixes: e1ceb25a1569 ("[media] SOLO6x10: remove unneeded register locking and barriers")
+
+Signed-off-by: Andrey Utkin <andrey.utkin@corp.bluecherry.net>
+Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/pci/solo6x10/solo6x10.h | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/media/pci/solo6x10/solo6x10.h
++++ b/drivers/media/pci/solo6x10/solo6x10.h
+@@ -286,7 +286,10 @@ static inline u32 solo_reg_read(struct s
+ static inline void solo_reg_write(struct solo_dev *solo_dev, int reg,
+ u32 data)
+ {
++ u16 val;
++
+ writel(data, solo_dev->reg_base + reg);
++ pci_read_config_word(solo_dev->pdev, PCI_STATUS, &val);
+ }
+
+ static inline void solo_irq_on(struct solo_dev *dev, u32 mask)
--- /dev/null
+From d5f8e166c25750adc147b0adf64a62a91653438a Mon Sep 17 00:00:00 2001
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+Date: Thu, 24 Nov 2016 13:34:02 +0200
+Subject: mei: request async autosuspend at the end of enumeration
+
+From: Alexander Usyskin <alexander.usyskin@intel.com>
+
+commit d5f8e166c25750adc147b0adf64a62a91653438a upstream.
+
+pm_runtime_autosuspend can take synchronous or asynchronous
+paths, Because we are calling pm_runtime_mark_last_busy just before
+this most of the cases it takes the asynchronous way. However,
+when the FW or driver resets during already running runtime suspend,
+the call will result in calling to the driver's rpm callback and results
+in a deadlock on device_lock.
+The simplest fix is to replace pm_runtime_autosuspend with
+asynchronous pm_request_autosuspend.
+
+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>
+
+---
+ drivers/misc/mei/client.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/misc/mei/client.c
++++ b/drivers/misc/mei/client.c
+@@ -698,7 +698,7 @@ void mei_host_client_init(struct work_st
+
+ pm_runtime_mark_last_busy(dev->dev);
+ dev_dbg(dev->dev, "rpm: autosuspend\n");
+- pm_runtime_autosuspend(dev->dev);
++ pm_request_autosuspend(dev->dev);
+ }
+
+ /**
--- /dev/null
+From e74e259939275a5dd4e0d02845c694f421e249ad Mon Sep 17 00:00:00 2001
+From: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
+Date: Tue, 29 Nov 2016 23:23:06 -0200
+Subject: platform/x86: asus-nb-wmi.c: Add X45U quirk
+
+From: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
+
+commit e74e259939275a5dd4e0d02845c694f421e249ad upstream.
+
+Without this patch, the Asus X45U wireless card can't be turned
+on (hard-blocked), but after a suspend/resume it just starts working.
+
+Following this bug report[1], there are other cases like this one, but
+this Asus is the only model that I can test.
+
+[1] https://ubuntuforums.org/showthread.php?t=2181558
+
+Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/platform/x86/asus-nb-wmi.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/platform/x86/asus-nb-wmi.c
++++ b/drivers/platform/x86/asus-nb-wmi.c
+@@ -128,6 +128,15 @@ static const struct dmi_system_id asus_q
+ },
+ {
+ .callback = dmi_matched,
++ .ident = "ASUSTeK COMPUTER INC. X45U",
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X45U"),
++ },
++ .driver_data = &quirk_asus_wapf4,
++ },
++ {
++ .callback = dmi_matched,
+ .ident = "ASUSTeK COMPUTER INC. X456UA",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
--- /dev/null
+From 5457e03de918f7a3e294eb9d26a608ab8a579976 Mon Sep 17 00:00:00 2001
+From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Date: Mon, 21 Nov 2016 12:13:58 +0100
+Subject: s390/vmlogrdr: fix IUCV buffer allocation
+
+From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+
+commit 5457e03de918f7a3e294eb9d26a608ab8a579976 upstream.
+
+The buffer for iucv_message_receive() needs to be below 2 GB. In
+__iucv_message_receive(), the buffer address is casted to an u32, which
+would result in either memory corruption or an addressing exception when
+using addresses >= 2 GB.
+
+Fix this by using GFP_DMA for the buffer allocation.
+
+Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
+Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/char/vmlogrdr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/s390/char/vmlogrdr.c
++++ b/drivers/s390/char/vmlogrdr.c
+@@ -872,7 +872,7 @@ static int __init vmlogrdr_init(void)
+ goto cleanup;
+
+ for (i=0; i < MAXMINOR; ++i ) {
+- sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL);
++ sys_ser[i].buffer = (char *) get_zeroed_page(GFP_KERNEL | GFP_DMA);
+ if (!sys_ser[i].buffer) {
+ rc = -ENOMEM;
+ break;
--- /dev/null
+From 04da73803c05dc1150ccc31cbf93e8cd56679c09 Mon Sep 17 00:00:00 2001
+From: Josh Cartwright <joshc@ni.com>
+Date: Thu, 13 Oct 2016 10:44:33 -0500
+Subject: sc16is7xx: Drop bogus use of IRQF_ONESHOT
+
+From: Josh Cartwright <joshc@ni.com>
+
+commit 04da73803c05dc1150ccc31cbf93e8cd56679c09 upstream.
+
+The use of IRQF_ONESHOT when registering an interrupt handler with
+request_irq() is non-sensical.
+
+Not only that, it also prevents the handler from being threaded when it
+otherwise should be w/ IRQ_FORCED_THREADING is enabled. This causes the
+following deadlock observed by Sean Nyekjaer on -rt:
+
+Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
+[..]
+ rt_spin_lock_slowlock from queue_kthread_work
+ queue_kthread_work from sc16is7xx_irq
+ sc16is7xx_irq [sc16is7xx] from handle_irq_event_percpu
+ handle_irq_event_percpu from handle_irq_event
+ handle_irq_event from handle_level_irq
+ handle_level_irq from generic_handle_irq
+ generic_handle_irq from mxc_gpio_irq_handler
+ mxc_gpio_irq_handler from mx3_gpio_irq_handler
+ mx3_gpio_irq_handler from generic_handle_irq
+ generic_handle_irq from __handle_domain_irq
+ __handle_domain_irq from gic_handle_irq
+ gic_handle_irq from __irq_svc
+ __irq_svc from rt_spin_unlock
+ rt_spin_unlock from kthread_worker_fn
+ kthread_worker_fn from kthread
+ kthread from ret_from_fork
+
+Fixes: 9e6f4ca3e567 ("sc16is7xx: use kthread_worker for tx_work and irq")
+Reported-by: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
+Signed-off-by: Josh Cartwright <joshc@ni.com>
+Cc: linux-rt-users@vger.kernel.org
+Cc: Jakub Kicinski <moorray3@wp.pl>
+Cc: linux-serial@vger.kernel.org
+Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Julia Cartwright <julia@ni.com>
+Acked-by: Jakub Kicinski <kubakici@wp.pl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/serial/sc16is7xx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/sc16is7xx.c
++++ b/drivers/tty/serial/sc16is7xx.c
+@@ -1230,7 +1230,7 @@ static int sc16is7xx_probe(struct device
+
+ /* Setup interrupt */
+ ret = devm_request_irq(dev, irq, sc16is7xx_irq,
+- IRQF_ONESHOT | flags, dev_name(dev), s);
++ flags, dev_name(dev), s);
+ if (!ret)
+ return 0;
+
--- /dev/null
+From d2a145252c52792bc59e4767b486b26c430af4bb Mon Sep 17 00:00:00 2001
+From: Wei Fang <fangwei1@huawei.com>
+Date: Tue, 13 Dec 2016 09:25:21 +0800
+Subject: scsi: avoid a permanent stop of the scsi device's request queue
+
+From: Wei Fang <fangwei1@huawei.com>
+
+commit d2a145252c52792bc59e4767b486b26c430af4bb upstream.
+
+A race between scanning and fc_remote_port_delete() may result in a
+permanent stop if the device gets blocked before scsi_sysfs_add_sdev()
+and unblocked after. The reason is that blocking a device sets both the
+SDEV_BLOCKED state and the QUEUE_FLAG_STOPPED. However,
+scsi_sysfs_add_sdev() unconditionally sets SDEV_RUNNING which causes the
+device to be ignored by scsi_target_unblock() and thus never have its
+QUEUE_FLAG_STOPPED cleared leading to a device which is apparently
+running but has a stopped queue.
+
+We actually have two places where SDEV_RUNNING is set: once in
+scsi_add_lun() which respects the blocked flag and once in
+scsi_sysfs_add_sdev() which doesn't. Since the second set is entirely
+spurious, simply remove it to fix the problem.
+
+Reported-by: Zengxi Chen <chenzengxi@huawei.com>
+Signed-off-by: Wei Fang <fangwei1@huawei.com>
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/scsi_sysfs.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/scsi/scsi_sysfs.c
++++ b/drivers/scsi/scsi_sysfs.c
+@@ -1031,10 +1031,6 @@ int scsi_sysfs_add_sdev(struct scsi_devi
+ struct request_queue *rq = sdev->request_queue;
+ struct scsi_target *starget = sdev->sdev_target;
+
+- error = scsi_device_set_state(sdev, SDEV_RUNNING);
+- if (error)
+- return error;
+-
+ error = scsi_target_add(starget);
+ if (error)
+ return error;
--- /dev/null
+From d5573584429254a14708cf8375c47092b5edaf2c Mon Sep 17 00:00:00 2001
+From: Kashyap Desai <kashyap.desai@broadcom.com>
+Date: Fri, 21 Oct 2016 06:33:35 -0700
+Subject: scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map
+
+From: Kashyap Desai <kashyap.desai@broadcom.com>
+
+commit d5573584429254a14708cf8375c47092b5edaf2c upstream.
+
+Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Tomas Henzl <thenzl@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/megaraid/megaraid_sas_fusion.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
++++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
+@@ -1856,6 +1856,8 @@ megasas_build_syspd_fusion(struct megasa
+ io_request->DevHandle = pd_sync->seq[pd_index].devHandle;
+ pRAID_Context->regLockFlags |=
+ (MR_RL_FLAGS_SEQ_NUM_ENABLE|MR_RL_FLAGS_GRANT_DESTINATION_CUDA);
++ pRAID_Context->Type = MPI2_TYPE_CUDA;
++ pRAID_Context->nseg = 0x1;
+ } else if (fusion->fast_path_io) {
+ pRAID_Context->VirtualDiskTgtId = cpu_to_le16(device_id);
+ pRAID_Context->configSeqNum = 0;
+@@ -1891,12 +1893,10 @@ megasas_build_syspd_fusion(struct megasa
+ pRAID_Context->timeoutValue =
+ cpu_to_le16((os_timeout_value > timeout_limit) ?
+ timeout_limit : os_timeout_value);
+- if (fusion->adapter_type == INVADER_SERIES) {
+- pRAID_Context->Type = MPI2_TYPE_CUDA;
+- pRAID_Context->nseg = 0x1;
++ if (fusion->adapter_type == INVADER_SERIES)
+ io_request->IoFlags |=
+ cpu_to_le16(MPI25_SAS_DEVICE0_FLAGS_ENABLED_FAST_PATH);
+- }
++
+ cmd->request_desc->SCSIIO.RequestFlags =
+ (MPI2_REQ_DESCRIPT_FLAGS_HIGH_PRIORITY <<
+ MEGASAS_REQ_DESCRIPT_FLAGS_TYPE_SHIFT);
--- /dev/null
+From 18e1c7f68a5814442abad849abe6eacbf02ffd7c Mon Sep 17 00:00:00 2001
+From: Kashyap Desai <kashyap.desai@broadcom.com>
+Date: Fri, 21 Oct 2016 06:33:29 -0700
+Subject: scsi: megaraid_sas: For SRIOV enabled firmware, ensure VF driver waits for 30secs before reset
+
+From: Kashyap Desai <kashyap.desai@broadcom.com>
+
+commit 18e1c7f68a5814442abad849abe6eacbf02ffd7c upstream.
+
+For SRIOV enabled firmware, if there is a OCR(online controller reset)
+possibility driver set the convert flag to 1, which is not happening if
+there are outstanding commands even after 180 seconds. As driver does
+not set convert flag to 1 and still making the OCR to run, VF(Virtual
+function) driver is directly writing on to the register instead of
+waiting for 30 seconds. Setting convert flag to 1 will cause VF driver
+will wait for 30 secs before going for reset.
+
+Signed-off-by: Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com>
+Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
+Reviewed-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Tomas Henzl <thenzl@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/megaraid/megaraid_sas_fusion.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
++++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
+@@ -2648,6 +2648,7 @@ int megasas_wait_for_outstanding_fusion(
+ dev_err(&instance->pdev->dev, "pending commands remain after waiting, "
+ "will reset adapter scsi%d.\n",
+ instance->host->host_no);
++ *convert = 1;
+ retval = 1;
+ }
+ out:
--- /dev/null
+From 56d23ed7adf3974f10e91b643bd230e9c65b5f79 Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Date: Fri, 9 Dec 2016 17:16:32 +0100
+Subject: scsi: zfcp: do not trace pure benign residual HBA responses at default level
+
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+
+commit 56d23ed7adf3974f10e91b643bd230e9c65b5f79 upstream.
+
+Since quite a while, Linux issues enough SCSI commands per scsi_device
+which successfully return with FCP_RESID_UNDER, FSF_FCP_RSP_AVAILABLE,
+and SAM_STAT_GOOD. This floods the HBA trace area and we cannot see
+other and important HBA trace records long enough.
+
+Therefore, do not trace HBA response errors for pure benign residual
+under counts at the default trace level.
+
+This excludes benign residual under count combined with other validity
+bits set in FCP_RSP_IU, such as FCP_SNS_LEN_VAL. For all those other
+cases, we still do want to see both the HBA record and the corresponding
+SCSI record by default.
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.")
+Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_dbf.h | 30 ++++++++++++++++++++++++++++--
+ drivers/s390/scsi/zfcp_fsf.h | 3 ++-
+ 2 files changed, 30 insertions(+), 3 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.h
++++ b/drivers/s390/scsi/zfcp_dbf.h
+@@ -2,7 +2,7 @@
+ * zfcp device driver
+ * debug feature declarations
+ *
+- * Copyright IBM Corp. 2008, 2015
++ * Copyright IBM Corp. 2008, 2016
+ */
+
+ #ifndef ZFCP_DBF_H
+@@ -283,6 +283,30 @@ struct zfcp_dbf {
+ struct zfcp_dbf_scsi scsi_buf;
+ };
+
++/**
++ * zfcp_dbf_hba_fsf_resp_suppress - true if we should not trace by default
++ * @req: request that has been completed
++ *
++ * Returns true if FCP response with only benign residual under count.
++ */
++static inline
++bool zfcp_dbf_hba_fsf_resp_suppress(struct zfcp_fsf_req *req)
++{
++ struct fsf_qtcb *qtcb = req->qtcb;
++ u32 fsf_stat = qtcb->header.fsf_status;
++ struct fcp_resp *fcp_rsp;
++ u8 rsp_flags, fr_status;
++
++ if (qtcb->prefix.qtcb_type != FSF_IO_COMMAND)
++ return false; /* not an FCP response */
++ fcp_rsp = (struct fcp_resp *)&qtcb->bottom.io.fcp_rsp;
++ rsp_flags = fcp_rsp->fr_flags;
++ fr_status = fcp_rsp->fr_status;
++ return (fsf_stat == FSF_FCP_RSP_AVAILABLE) &&
++ (rsp_flags == FCP_RESID_UNDER) &&
++ (fr_status == SAM_STAT_GOOD);
++}
++
+ static inline
+ void zfcp_dbf_hba_fsf_resp(char *tag, int level, struct zfcp_fsf_req *req)
+ {
+@@ -304,7 +328,9 @@ void zfcp_dbf_hba_fsf_response(struct zf
+ zfcp_dbf_hba_fsf_resp("fs_perr", 1, req);
+
+ } else if (qtcb->header.fsf_status != FSF_GOOD) {
+- zfcp_dbf_hba_fsf_resp("fs_ferr", 1, req);
++ zfcp_dbf_hba_fsf_resp("fs_ferr",
++ zfcp_dbf_hba_fsf_resp_suppress(req)
++ ? 5 : 1, req);
+
+ } else if ((req->fsf_command == FSF_QTCB_OPEN_PORT_WITH_DID) ||
+ (req->fsf_command == FSF_QTCB_OPEN_LUN)) {
+--- a/drivers/s390/scsi/zfcp_fsf.h
++++ b/drivers/s390/scsi/zfcp_fsf.h
+@@ -3,7 +3,7 @@
+ *
+ * Interface to the FSF support functions.
+ *
+- * Copyright IBM Corp. 2002, 2015
++ * Copyright IBM Corp. 2002, 2016
+ */
+
+ #ifndef FSF_H
+@@ -78,6 +78,7 @@
+ #define FSF_APP_TAG_CHECK_FAILURE 0x00000082
+ #define FSF_REF_TAG_CHECK_FAILURE 0x00000083
+ #define FSF_ADAPTER_STATUS_AVAILABLE 0x000000AD
++#define FSF_FCP_RSP_AVAILABLE 0x000000AF
+ #define FSF_UNKNOWN_COMMAND 0x000000E2
+ #define FSF_UNKNOWN_OP_SUBTYPE 0x000000E3
+ #define FSF_INVALID_COMMAND_OPTION 0x000000E5
--- /dev/null
+From 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c Mon Sep 17 00:00:00 2001
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+Date: Fri, 9 Dec 2016 17:16:33 +0100
+Subject: scsi: zfcp: fix rport unblock race with LUN recovery
+
+From: Steffen Maier <maier@linux.vnet.ibm.com>
+
+commit 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c upstream.
+
+It is unavoidable that zfcp_scsi_queuecommand() has to finish requests
+with DID_IMM_RETRY (like fc_remote_port_chkready()) during the time
+window when zfcp detected an unavailable rport but
+fc_remote_port_delete(), which is asynchronous via
+zfcp_scsi_schedule_rport_block(), has not yet blocked the rport.
+
+However, for the case when the rport becomes available again, we should
+prevent unblocking the rport too early. In contrast to other FCP LLDDs,
+zfcp has to open each LUN with the FCP channel hardware before it can
+send I/O to a LUN. So if a port already has LUNs attached and we
+unblock the rport just after port recovery, recoveries of LUNs behind
+this port can still be pending which in turn force
+zfcp_scsi_queuecommand() to unnecessarily finish requests with
+DID_IMM_RETRY.
+
+This also opens a time window with unblocked rport (until the followup
+LUN reopen recovery has finished). If a scsi_cmnd timeout occurs during
+this time window fc_timed_out() cannot work as desired and such command
+would indeed time out and trigger scsi_eh. This prevents a clean and
+timely path failover. This should not happen if the path issue can be
+recovered on FC transport layer such as path issues involving RSCNs.
+
+Fix this by only calling zfcp_scsi_schedule_rport_register(), to
+asynchronously trigger fc_remote_port_add(), after all LUN recoveries as
+children of the rport have finished and no new recoveries of equal or
+higher order were triggered meanwhile. Finished intentionally includes
+any recovery result no matter if successful or failed (still unblock
+rport so other successful LUNs work). For simplicity, we check after
+each finished LUN recovery if there is another LUN recovery pending on
+the same port and then do nothing. We handle the special case of a
+successful recovery of a port without LUN children the same way without
+changing this case's semantics.
+
+For debugging we introduce 2 new trace records written if the rport
+unblock attempt was aborted due to still unfinished or freshly triggered
+recovery. The records are only written above the default trace level.
+
+Benjamin noticed the important special case of new recovery that can be
+triggered between having given up the erp_lock and before calling
+zfcp_erp_action_cleanup() within zfcp_erp_strategy(). We must avoid the
+following sequence:
+
+ERP thread rport_work other context
+------------------------- -------------- --------------------------------
+port is unblocked, rport still blocked,
+ due to pending/running ERP action,
+ so ((port->status & ...UNBLOCK) != 0)
+ and (port->rport == NULL)
+unlock ERP
+zfcp_erp_action_cleanup()
+case ZFCP_ERP_ACTION_REOPEN_LUN:
+zfcp_erp_try_rport_unblock()
+((status & ...UNBLOCK) != 0) [OLD!]
+ zfcp_erp_port_reopen()
+ lock ERP
+ zfcp_erp_port_block()
+ port->status clear ...UNBLOCK
+ unlock ERP
+ zfcp_scsi_schedule_rport_block()
+ port->rport_task = RPORT_DEL
+ queue_work(rport_work)
+ zfcp_scsi_rport_work()
+ (port->rport_task != RPORT_ADD)
+ port->rport_task = RPORT_NONE
+ zfcp_scsi_rport_block()
+ if (!port->rport) return
+zfcp_scsi_schedule_rport_register()
+port->rport_task = RPORT_ADD
+queue_work(rport_work)
+ zfcp_scsi_rport_work()
+ (port->rport_task == RPORT_ADD)
+ port->rport_task = RPORT_NONE
+ zfcp_scsi_rport_register()
+ (port->rport == NULL)
+ rport = fc_remote_port_add()
+ port->rport = rport;
+
+Now the rport was erroneously unblocked while the zfcp_port is blocked.
+This is another situation we want to avoid due to scsi_eh
+potential. This state would at least remain until the new recovery from
+the other context finished successfully, or potentially forever if it
+failed. In order to close this race, we take the erp_lock inside
+zfcp_erp_try_rport_unblock() when checking the status of zfcp_port or
+LUN. With that, the possible corresponding rport state sequences would
+be: (unblock[ERP thread],block[other context]) if the ERP thread gets
+erp_lock first and still sees ((port->status & ...UNBLOCK) != 0),
+(block[other context],NOP[ERP thread]) if the ERP thread gets erp_lock
+after the other context has already cleard ...UNBLOCK from port->status.
+
+Since checking fields of struct erp_action is unsafe because they could
+have been overwritten (re-used for new recovery) meanwhile, we only
+check status of zfcp_port and LUN since these are only changed under
+erp_lock elsewhere. Regarding the check of the proper status flags (port
+or port_forced are similar to the shown adapter recovery):
+
+[zfcp_erp_adapter_shutdown()]
+zfcp_erp_adapter_reopen()
+ zfcp_erp_adapter_block()
+ * clear UNBLOCK ---------------------------------------+
+ zfcp_scsi_schedule_rports_block() |
+ write_lock_irqsave(&adapter->erp_lock, flags);-------+ |
+ zfcp_erp_action_enqueue() | |
+ zfcp_erp_setup_act() | |
+ * set ERP_INUSE -----------------------------------|--|--+
+ write_unlock_irqrestore(&adapter->erp_lock, flags);--+ | |
+.context-switch. | |
+zfcp_erp_thread() | |
+ zfcp_erp_strategy() | |
+ write_lock_irqsave(&adapter->erp_lock, flags);------+ | |
+ ... | | |
+ zfcp_erp_strategy_check_target() | | |
+ zfcp_erp_strategy_check_adapter() | | |
+ zfcp_erp_adapter_unblock() | | |
+ * set UNBLOCK -----------------------------------|--+ |
+ zfcp_erp_action_dequeue() | |
+ * clear ERP_INUSE ---------------------------------|-----+
+ ... |
+ write_unlock_irqrestore(&adapter->erp_lock, flags);-+
+
+Hence, we should check for both UNBLOCK and ERP_INUSE because they are
+interleaved. Also we need to explicitly check ERP_FAILED for the link
+down case which currently does not clear the UNBLOCK flag in
+zfcp_fsf_link_down_info_eval().
+
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Fixes: 8830271c4819 ("[SCSI] zfcp: Dont fail SCSI commands when transitioning to blocked fc_rport")
+Fixes: a2fa0aede07c ("[SCSI] zfcp: Block FC transport rports early on errors")
+Fixes: 5f852be9e11d ("[SCSI] zfcp: Fix deadlock between zfcp ERP and SCSI")
+Fixes: 338151e06608 ("[SCSI] zfcp: make use of fc_remote_port_delete when target port is unavailable")
+Fixes: 3859f6a248cb ("[PATCH] zfcp: add rports to enable scsi_add_device to work again")
+Reviewed-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_dbf.c | 17 +++++++++--
+ drivers/s390/scsi/zfcp_erp.c | 61 ++++++++++++++++++++++++++++++++++++++++--
+ drivers/s390/scsi/zfcp_ext.h | 4 ++
+ drivers/s390/scsi/zfcp_scsi.c | 4 --
+ 4 files changed, 77 insertions(+), 9 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.c
++++ b/drivers/s390/scsi/zfcp_dbf.c
+@@ -289,11 +289,12 @@ void zfcp_dbf_rec_trig(char *tag, struct
+
+
+ /**
+- * zfcp_dbf_rec_run - trace event related to running recovery
++ * zfcp_dbf_rec_run_lvl - trace event related to running recovery
++ * @level: trace level to be used for event
+ * @tag: identifier for event
+ * @erp: erp_action running
+ */
+-void zfcp_dbf_rec_run(char *tag, struct zfcp_erp_action *erp)
++void zfcp_dbf_rec_run_lvl(int level, char *tag, struct zfcp_erp_action *erp)
+ {
+ struct zfcp_dbf *dbf = erp->adapter->dbf;
+ struct zfcp_dbf_rec *rec = &dbf->rec_buf;
+@@ -319,11 +320,21 @@ void zfcp_dbf_rec_run(char *tag, struct
+ else
+ rec->u.run.rec_count = atomic_read(&erp->adapter->erp_counter);
+
+- debug_event(dbf->rec, 1, rec, sizeof(*rec));
++ debug_event(dbf->rec, level, rec, sizeof(*rec));
+ spin_unlock_irqrestore(&dbf->rec_lock, flags);
+ }
+
+ /**
++ * zfcp_dbf_rec_run - trace event related to running recovery
++ * @tag: identifier for event
++ * @erp: erp_action running
++ */
++void zfcp_dbf_rec_run(char *tag, struct zfcp_erp_action *erp)
++{
++ zfcp_dbf_rec_run_lvl(1, tag, erp);
++}
++
++/**
+ * zfcp_dbf_rec_run_wka - trace wka port event with info like running recovery
+ * @tag: identifier for event
+ * @wka_port: well known address port
+--- a/drivers/s390/scsi/zfcp_erp.c
++++ b/drivers/s390/scsi/zfcp_erp.c
+@@ -3,7 +3,7 @@
+ *
+ * Error Recovery Procedures (ERP).
+ *
+- * Copyright IBM Corp. 2002, 2015
++ * Copyright IBM Corp. 2002, 2016
+ */
+
+ #define KMSG_COMPONENT "zfcp"
+@@ -1204,6 +1204,62 @@ static void zfcp_erp_action_dequeue(stru
+ }
+ }
+
++/**
++ * zfcp_erp_try_rport_unblock - unblock rport if no more/new recovery
++ * @port: zfcp_port whose fc_rport we should try to unblock
++ */
++static void zfcp_erp_try_rport_unblock(struct zfcp_port *port)
++{
++ unsigned long flags;
++ struct zfcp_adapter *adapter = port->adapter;
++ int port_status;
++ struct Scsi_Host *shost = adapter->scsi_host;
++ struct scsi_device *sdev;
++
++ write_lock_irqsave(&adapter->erp_lock, flags);
++ port_status = atomic_read(&port->status);
++ if ((port_status & ZFCP_STATUS_COMMON_UNBLOCKED) == 0 ||
++ (port_status & (ZFCP_STATUS_COMMON_ERP_INUSE |
++ ZFCP_STATUS_COMMON_ERP_FAILED)) != 0) {
++ /* new ERP of severity >= port triggered elsewhere meanwhile or
++ * local link down (adapter erp_failed but not clear unblock)
++ */
++ zfcp_dbf_rec_run_lvl(4, "ertru_p", &port->erp_action);
++ write_unlock_irqrestore(&adapter->erp_lock, flags);
++ return;
++ }
++ spin_lock(shost->host_lock);
++ __shost_for_each_device(sdev, shost) {
++ struct zfcp_scsi_dev *zsdev = sdev_to_zfcp(sdev);
++ int lun_status;
++
++ if (zsdev->port != port)
++ continue;
++ /* LUN under port of interest */
++ lun_status = atomic_read(&zsdev->status);
++ if ((lun_status & ZFCP_STATUS_COMMON_ERP_FAILED) != 0)
++ continue; /* unblock rport despite failed LUNs */
++ /* LUN recovery not given up yet [maybe follow-up pending] */
++ if ((lun_status & ZFCP_STATUS_COMMON_UNBLOCKED) == 0 ||
++ (lun_status & ZFCP_STATUS_COMMON_ERP_INUSE) != 0) {
++ /* LUN blocked:
++ * not yet unblocked [LUN recovery pending]
++ * or meanwhile blocked [new LUN recovery triggered]
++ */
++ zfcp_dbf_rec_run_lvl(4, "ertru_l", &zsdev->erp_action);
++ spin_unlock(shost->host_lock);
++ write_unlock_irqrestore(&adapter->erp_lock, flags);
++ return;
++ }
++ }
++ /* now port has no child or all children have completed recovery,
++ * and no ERP of severity >= port was meanwhile triggered elsewhere
++ */
++ zfcp_scsi_schedule_rport_register(port);
++ spin_unlock(shost->host_lock);
++ write_unlock_irqrestore(&adapter->erp_lock, flags);
++}
++
+ static void zfcp_erp_action_cleanup(struct zfcp_erp_action *act, int result)
+ {
+ struct zfcp_adapter *adapter = act->adapter;
+@@ -1214,6 +1270,7 @@ static void zfcp_erp_action_cleanup(stru
+ case ZFCP_ERP_ACTION_REOPEN_LUN:
+ if (!(act->status & ZFCP_STATUS_ERP_NO_REF))
+ scsi_device_put(sdev);
++ zfcp_erp_try_rport_unblock(port);
+ break;
+
+ case ZFCP_ERP_ACTION_REOPEN_PORT:
+@@ -1224,7 +1281,7 @@ static void zfcp_erp_action_cleanup(stru
+ */
+ if (act->step != ZFCP_ERP_STEP_UNINITIALIZED)
+ if (result == ZFCP_ERP_SUCCEEDED)
+- zfcp_scsi_schedule_rport_register(port);
++ zfcp_erp_try_rport_unblock(port);
+ /* fall through */
+ case ZFCP_ERP_ACTION_REOPEN_PORT_FORCED:
+ put_device(&port->dev);
+--- a/drivers/s390/scsi/zfcp_ext.h
++++ b/drivers/s390/scsi/zfcp_ext.h
+@@ -3,7 +3,7 @@
+ *
+ * External function declarations.
+ *
+- * Copyright IBM Corp. 2002, 2015
++ * Copyright IBM Corp. 2002, 2016
+ */
+
+ #ifndef ZFCP_EXT_H
+@@ -35,6 +35,8 @@ extern void zfcp_dbf_adapter_unregister(
+ extern void zfcp_dbf_rec_trig(char *, struct zfcp_adapter *,
+ struct zfcp_port *, struct scsi_device *, u8, u8);
+ extern void zfcp_dbf_rec_run(char *, struct zfcp_erp_action *);
++extern void zfcp_dbf_rec_run_lvl(int level, char *tag,
++ struct zfcp_erp_action *erp);
+ extern void zfcp_dbf_rec_run_wka(char *, struct zfcp_fc_wka_port *, u64);
+ extern void zfcp_dbf_hba_fsf_uss(char *, struct zfcp_fsf_req *);
+ extern void zfcp_dbf_hba_fsf_res(char *, int, struct zfcp_fsf_req *);
+--- a/drivers/s390/scsi/zfcp_scsi.c
++++ b/drivers/s390/scsi/zfcp_scsi.c
+@@ -88,9 +88,7 @@ int zfcp_scsi_queuecommand(struct Scsi_H
+ }
+
+ if (unlikely(!(status & ZFCP_STATUS_COMMON_UNBLOCKED))) {
+- /* This could be either
+- * open LUN pending: this is temporary, will result in
+- * open LUN or ERP_FAILED, so retry command
++ /* This could be
+ * call to rport_delete pending: mimic retry from
+ * fc_remote_port_chkready until rport is BLOCKED
+ */
--- /dev/null
+From dac37e15b7d511e026a9313c8c46794c144103cd Mon Sep 17 00:00:00 2001
+From: Benjamin Block <bblock@linux.vnet.ibm.com>
+Date: Fri, 9 Dec 2016 17:16:31 +0100
+Subject: scsi: zfcp: fix use-after-"free" in FC ingress path after TMF
+
+From: Benjamin Block <bblock@linux.vnet.ibm.com>
+
+commit dac37e15b7d511e026a9313c8c46794c144103cd upstream.
+
+When SCSI EH invokes zFCP's callbacks for eh_device_reset_handler() and
+eh_target_reset_handler(), it expects us to relent the ownership over
+the given scsi_cmnd and all other scsi_cmnds within the same scope - LUN
+or target - when returning with SUCCESS from the callback ('release'
+them). SCSI EH can then reuse those commands.
+
+We did not follow this rule to release commands upon SUCCESS; and if
+later a reply arrived for one of those supposed to be released commands,
+we would still make use of the scsi_cmnd in our ingress tasklet. This
+will at least result in undefined behavior or a kernel panic because of
+a wrong kernel pointer dereference.
+
+To fix this, we NULLify all pointers to scsi_cmnds (struct zfcp_fsf_req
+*)->data in the matching scope if a TMF was successful. This is done
+under the locks (struct zfcp_adapter *)->abort_lock and (struct
+zfcp_reqlist *)->lock to prevent the requests from being removed from
+the request-hashtable, and the ingress tasklet from making use of the
+scsi_cmnd-pointer in zfcp_fsf_fcp_cmnd_handler().
+
+For cases where a reply arrives during SCSI EH, but before we get a
+chance to NULLify the pointer - but before we return from the callback
+-, we assume that the code is protected from races via the CAS operation
+in blk_complete_request() that is called in scsi_done().
+
+The following stacktrace shows an example for a crash resulting from the
+previous behavior:
+
+Unable to handle kernel pointer dereference at virtual kernel address fffffee17a672000
+Oops: 0038 [#1] SMP
+CPU: 2 PID: 0 Comm: swapper/2 Not tainted
+task: 00000003f7ff5be0 ti: 00000003f3d38000 task.ti: 00000003f3d38000
+Krnl PSW : 0404d00180000000 00000000001156b0 (smp_vcpu_scheduled+0x18/0x40)
+ R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 EA:3
+Krnl GPRS: 000000200000007e 0000000000000000 fffffee17a671fd8 0000000300000015
+ ffffffff80000000 00000000005dfde8 07000003f7f80e00 000000004fa4e800
+ 000000036ce8d8f8 000000036ce8d9c0 00000003ece8fe00 ffffffff969c9e93
+ 00000003fffffffd 000000036ce8da10 00000000003bf134 00000003f3b07918
+Krnl Code: 00000000001156a2: a7190000 lghi %r1,0
+ 00000000001156a6: a7380015 lhi %r3,21
+ #00000000001156aa: e32050000008 ag %r2,0(%r5)
+ >00000000001156b0: 482022b0 lh %r2,688(%r2)
+ 00000000001156b4: ae123000 sigp %r1,%r2,0(%r3)
+ 00000000001156b8: b2220020 ipm %r2
+ 00000000001156bc: 8820001c srl %r2,28
+ 00000000001156c0: c02700000001 xilf %r2,1
+Call Trace:
+([<0000000000000000>] 0x0)
+ [<000003ff807bdb8e>] zfcp_fsf_fcp_cmnd_handler+0x3de/0x490 [zfcp]
+ [<000003ff807be30a>] zfcp_fsf_req_complete+0x252/0x800 [zfcp]
+ [<000003ff807c0a48>] zfcp_fsf_reqid_check+0xe8/0x190 [zfcp]
+ [<000003ff807c194e>] zfcp_qdio_int_resp+0x66/0x188 [zfcp]
+ [<000003ff80440c64>] qdio_kick_handler+0xdc/0x310 [qdio]
+ [<000003ff804463d0>] __tiqdio_inbound_processing+0xf8/0xcd8 [qdio]
+ [<0000000000141fd4>] tasklet_action+0x9c/0x170
+ [<0000000000141550>] __do_softirq+0xe8/0x258
+ [<000000000010ce0a>] do_softirq+0xba/0xc0
+ [<000000000014187c>] irq_exit+0xc4/0xe8
+ [<000000000046b526>] do_IRQ+0x146/0x1d8
+ [<00000000005d6a3c>] io_return+0x0/0x8
+ [<00000000005d6422>] vtime_stop_cpu+0x4a/0xa0
+([<0000000000000000>] 0x0)
+ [<0000000000103d8a>] arch_cpu_idle+0xa2/0xb0
+ [<0000000000197f94>] cpu_startup_entry+0x13c/0x1f8
+ [<0000000000114782>] smp_start_secondary+0xda/0xe8
+ [<00000000005d6efe>] restart_int_handler+0x56/0x6c
+ [<0000000000000000>] 0x0
+Last Breaking-Event-Address:
+ [<00000000003bf12e>] arch_spin_lock_wait+0x56/0xb0
+
+Suggested-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Signed-off-by: Benjamin Block <bblock@linux.vnet.ibm.com>
+Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git)
+Signed-off-by: Steffen Maier <maier@linux.vnet.ibm.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/s390/scsi/zfcp_dbf.h | 11 +++++++
+ drivers/s390/scsi/zfcp_reqlist.h | 30 +++++++++++++++++++-
+ drivers/s390/scsi/zfcp_scsi.c | 57 +++++++++++++++++++++++++++++++++++++--
+ 3 files changed, 95 insertions(+), 3 deletions(-)
+
+--- a/drivers/s390/scsi/zfcp_dbf.h
++++ b/drivers/s390/scsi/zfcp_dbf.h
+@@ -388,4 +388,15 @@ void zfcp_dbf_scsi_devreset(char *tag, s
+ _zfcp_dbf_scsi(tmp_tag, 1, scmnd, NULL);
+ }
+
++/**
++ * zfcp_dbf_scsi_nullcmnd() - trace NULLify of SCSI command in dev/tgt-reset.
++ * @scmnd: SCSI command that was NULLified.
++ * @fsf_req: request that owned @scmnd.
++ */
++static inline void zfcp_dbf_scsi_nullcmnd(struct scsi_cmnd *scmnd,
++ struct zfcp_fsf_req *fsf_req)
++{
++ _zfcp_dbf_scsi("scfc__1", 3, scmnd, fsf_req);
++}
++
+ #endif /* ZFCP_DBF_H */
+--- a/drivers/s390/scsi/zfcp_reqlist.h
++++ b/drivers/s390/scsi/zfcp_reqlist.h
+@@ -4,7 +4,7 @@
+ * Data structure and helper functions for tracking pending FSF
+ * requests.
+ *
+- * Copyright IBM Corp. 2009
++ * Copyright IBM Corp. 2009, 2016
+ */
+
+ #ifndef ZFCP_REQLIST_H
+@@ -180,4 +180,32 @@ static inline void zfcp_reqlist_move(str
+ spin_unlock_irqrestore(&rl->lock, flags);
+ }
+
++/**
++ * zfcp_reqlist_apply_for_all() - apply a function to every request.
++ * @rl: the requestlist that contains the target requests.
++ * @f: the function to apply to each request; the first parameter of the
++ * function will be the target-request; the second parameter is the same
++ * pointer as given with the argument @data.
++ * @data: freely chosen argument; passed through to @f as second parameter.
++ *
++ * Uses :c:macro:`list_for_each_entry` to iterate over the lists in the hash-
++ * table (not a 'safe' variant, so don't modify the list).
++ *
++ * Holds @rl->lock over the entire request-iteration.
++ */
++static inline void
++zfcp_reqlist_apply_for_all(struct zfcp_reqlist *rl,
++ void (*f)(struct zfcp_fsf_req *, void *), void *data)
++{
++ struct zfcp_fsf_req *req;
++ unsigned long flags;
++ unsigned int i;
++
++ spin_lock_irqsave(&rl->lock, flags);
++ for (i = 0; i < ZFCP_REQ_LIST_BUCKETS; i++)
++ list_for_each_entry(req, &rl->buckets[i], list)
++ f(req, data);
++ spin_unlock_irqrestore(&rl->lock, flags);
++}
++
+ #endif /* ZFCP_REQLIST_H */
+--- a/drivers/s390/scsi/zfcp_scsi.c
++++ b/drivers/s390/scsi/zfcp_scsi.c
+@@ -3,7 +3,7 @@
+ *
+ * Interface to Linux SCSI midlayer.
+ *
+- * Copyright IBM Corp. 2002, 2015
++ * Copyright IBM Corp. 2002, 2016
+ */
+
+ #define KMSG_COMPONENT "zfcp"
+@@ -209,6 +209,57 @@ static int zfcp_scsi_eh_abort_handler(st
+ return retval;
+ }
+
++struct zfcp_scsi_req_filter {
++ u8 tmf_scope;
++ u32 lun_handle;
++ u32 port_handle;
++};
++
++static void zfcp_scsi_forget_cmnd(struct zfcp_fsf_req *old_req, void *data)
++{
++ struct zfcp_scsi_req_filter *filter =
++ (struct zfcp_scsi_req_filter *)data;
++
++ /* already aborted - prevent side-effects - or not a SCSI command */
++ if (old_req->data == NULL || old_req->fsf_command != FSF_QTCB_FCP_CMND)
++ return;
++
++ /* (tmf_scope == FCP_TMF_TGT_RESET || tmf_scope == FCP_TMF_LUN_RESET) */
++ if (old_req->qtcb->header.port_handle != filter->port_handle)
++ return;
++
++ if (filter->tmf_scope == FCP_TMF_LUN_RESET &&
++ old_req->qtcb->header.lun_handle != filter->lun_handle)
++ return;
++
++ zfcp_dbf_scsi_nullcmnd((struct scsi_cmnd *)old_req->data, old_req);
++ old_req->data = NULL;
++}
++
++static void zfcp_scsi_forget_cmnds(struct zfcp_scsi_dev *zsdev, u8 tm_flags)
++{
++ struct zfcp_adapter *adapter = zsdev->port->adapter;
++ struct zfcp_scsi_req_filter filter = {
++ .tmf_scope = FCP_TMF_TGT_RESET,
++ .port_handle = zsdev->port->handle,
++ };
++ unsigned long flags;
++
++ if (tm_flags == FCP_TMF_LUN_RESET) {
++ filter.tmf_scope = FCP_TMF_LUN_RESET;
++ filter.lun_handle = zsdev->lun_handle;
++ }
++
++ /*
++ * abort_lock secures against other processings - in the abort-function
++ * and normal cmnd-handler - of (struct zfcp_fsf_req *)->data
++ */
++ write_lock_irqsave(&adapter->abort_lock, flags);
++ zfcp_reqlist_apply_for_all(adapter->req_list, zfcp_scsi_forget_cmnd,
++ &filter);
++ write_unlock_irqrestore(&adapter->abort_lock, flags);
++}
++
+ static int zfcp_task_mgmt_function(struct scsi_cmnd *scpnt, u8 tm_flags)
+ {
+ struct zfcp_scsi_dev *zfcp_sdev = sdev_to_zfcp(scpnt->device);
+@@ -241,8 +292,10 @@ static int zfcp_task_mgmt_function(struc
+ if (fsf_req->status & ZFCP_STATUS_FSFREQ_TMFUNCFAILED) {
+ zfcp_dbf_scsi_devreset("fail", scpnt, tm_flags);
+ retval = FAILED;
+- } else
++ } else {
+ zfcp_dbf_scsi_devreset("okay", scpnt, tm_flags);
++ zfcp_scsi_forget_cmnds(zfcp_sdev, tm_flags);
++ }
+
+ zfcp_fsf_req_free(fsf_req);
+ return retval;
drm-radeon-add-additional-pci-revision-to-dpm-workaround.patch
drm-gma500-add-compat-ioctl.patch
drivers-gpu-drm-ast-fix-infinite-loop-if-read-fails.patch
+mei-request-async-autosuspend-at-the-end-of-enumeration.patch
+block-protect-iterate_bdevs-against-concurrent-close.patch
+vt-fix-scroll-lock-led-trigger-name.patch
+scsi-megaraid_sas-for-sriov-enabled-firmware-ensure-vf-driver-waits-for-30secs-before-reset.patch
+scsi-megaraid_sas-do-not-set-mpi2_type_cuda-for-jbod-fp-path-for-fw-which-does-not-support-jbod-sequence-map.patch
+scsi-zfcp-fix-use-after-free-in-fc-ingress-path-after-tmf.patch
+scsi-zfcp-do-not-trace-pure-benign-residual-hba-responses-at-default-level.patch
+scsi-zfcp-fix-rport-unblock-race-with-lun-recovery.patch
+scsi-avoid-a-permanent-stop-of-the-scsi-device-s-request-queue.patch
+arc-mm-arc700-don-t-assume-2-colours-for-aliasing-vipt-dcache.patch
+firmware-fix-usermode-helper-fallback-loading.patch
+s390-vmlogrdr-fix-iucv-buffer-allocation.patch
+sc16is7xx-drop-bogus-use-of-irqf_oneshot.patch
+md-raid5-limit-request-size-according-to-implementation-limits.patch
+kvm-ppc-book3s-hv-save-restore-xer-in-checkpointed-register-state.patch
+kvm-ppc-book3s-hv-don-t-lose-hardware-r-c-bit-updates-in-h_protect.patch
+kvm-nvmx-allow-l1-to-intercept-software-exceptions-bp-and-of.patch
+ftrace-x86_32-set-ftrace_stub-to-weak-to-prevent-gcc-from-using-short-jumps-to-it.patch
+platform-x86-asus-nb-wmi.c-add-x45u-quirk.patch
+fgraph-handle-a-case-where-a-tracer-ignores-set_graph_notrace.patch
+ib-mad-fix-an-array-index-check.patch
+ipoib-avoid-reading-an-uninitialized-member-variable.patch
+ib-multicast-check-ib_find_pkey-return-value.patch
+ib-cma-fix-a-race-condition-in-iboe_addr_get_sgid.patch
+media-solo6x10-fix-lockup-by-avoiding-delayed-register-write.patch
+input-drv260x-fix-input-device-s-parent-assignment.patch
--- /dev/null
+From 31b5929d533f5183972cf57a7844b456ed996f3c Mon Sep 17 00:00:00 2001
+From: "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>
+Date: Wed, 16 Nov 2016 00:55:57 +0100
+Subject: vt: fix Scroll Lock LED trigger name
+
+From: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+
+commit 31b5929d533f5183972cf57a7844b456ed996f3c upstream.
+
+There is a disagreement between drivers/tty/vt/keyboard.c and
+drivers/input/input-leds.c with regard to what is a Scroll Lock LED
+trigger name: input calls it "kbd-scrolllock", but vt calls it
+"kbd-scrollock" (two l's).
+This prevents Scroll Lock LED trigger from binding to this LED by default.
+
+Since it is a scroLL Lock LED, this interface was introduced only about a
+year ago and in an Internet search people seem to reference this trigger
+only to set it to this LED let's simply rename it to "kbd-scrolllock".
+
+Also, it looks like this was supposed to be changed before this code was
+merged: https://lkml.org/lkml/2015/6/9/697 but it was done only on
+the input side.
+
+Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name>
+Acked-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/tty/vt/keyboard.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/tty/vt/keyboard.c
++++ b/drivers/tty/vt/keyboard.c
+@@ -982,7 +982,7 @@ static void kbd_led_trigger_activate(str
+ KBD_LED_TRIGGER((_led_bit) + 8, _name)
+
+ static struct kbd_led_trigger kbd_led_triggers[] = {
+- KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrollock"),
++ KBD_LED_TRIGGER(VC_SCROLLOCK, "kbd-scrolllock"),
+ KBD_LED_TRIGGER(VC_NUMLOCK, "kbd-numlock"),
+ KBD_LED_TRIGGER(VC_CAPSLOCK, "kbd-capslock"),
+ KBD_LED_TRIGGER(VC_KANALOCK, "kbd-kanalock"),
projects / thirdparty / kernel / stable-queue.git / commitdiff
