From e31bf8bb220f46871bb309973ff03c3adc87762f Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Fri, 6 Jan 2017 15:55:40 +0100 Subject: [PATCH] 4.4-stable patches added patches: arc-mm-arc700-don-t-assume-2-colours-for-aliasing-vipt-dcache.patch block-protect-iterate_bdevs-against-concurrent-close.patch fgraph-handle-a-case-where-a-tracer-ignores-set_graph_notrace.patch firmware-fix-usermode-helper-fallback-loading.patch ftrace-x86_32-set-ftrace_stub-to-weak-to-prevent-gcc-from-using-short-jumps-to-it.patch ib-cma-fix-a-race-condition-in-iboe_addr_get_sgid.patch ib-mad-fix-an-array-index-check.patch ib-multicast-check-ib_find_pkey-return-value.patch input-drv260x-fix-input-device-s-parent-assignment.patch ipoib-avoid-reading-an-uninitialized-member-variable.patch kvm-nvmx-allow-l1-to-intercept-software-exceptions-bp-and-of.patch kvm-ppc-book3s-hv-don-t-lose-hardware-r-c-bit-updates-in-h_protect.patch kvm-ppc-book3s-hv-save-restore-xer-in-checkpointed-register-state.patch md-raid5-limit-request-size-according-to-implementation-limits.patch media-solo6x10-fix-lockup-by-avoiding-delayed-register-write.patch mei-request-async-autosuspend-at-the-end-of-enumeration.patch platform-x86-asus-nb-wmi.c-add-x45u-quirk.patch s390-vmlogrdr-fix-iucv-buffer-allocation.patch sc16is7xx-drop-bogus-use-of-irqf_oneshot.patch scsi-avoid-a-permanent-stop-of-the-scsi-device-s-request-queue.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-megaraid_sas-for-sriov-enabled-firmware-ensure-vf-driver-waits-for-30secs-before-reset.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-zfcp-fix-use-after-free-in-fc-ingress-path-after-tmf.patch vt-fix-scroll-lock-led-trigger-name.patch --- ...e-2-colours-for-aliasing-vipt-dcache.patch | 67 ++++ ...erate_bdevs-against-concurrent-close.patch | 94 ++++++ ...e-a-tracer-ignores-set_graph_notrace.patch | 108 ++++++ ...fix-usermode-helper-fallback-loading.patch | 115 +++++++ ...ent-gcc-from-using-short-jumps-to-it.patch | 43 +++ ...race-condition-in-iboe_addr_get_sgid.patch | 42 +++ .../ib-mad-fix-an-array-index-check.patch | 38 +++ ...cast-check-ib_find_pkey-return-value.patch | 38 +++ ...fix-input-device-s-parent-assignment.patch | 37 +++ ...ing-an-uninitialized-member-variable.patch | 40 +++ ...ercept-software-exceptions-bp-and-of.patch | 65 ++++ ...ardware-r-c-bit-updates-in-h_protect.patch | 45 +++ ...e-xer-in-checkpointed-register-state.patch | 129 +++++++ ...e-according-to-implementation-limits.patch | 51 +++ ...p-by-avoiding-delayed-register-write.patch | 46 +++ ...utosuspend-at-the-end-of-enumeration.patch | 37 +++ ...orm-x86-asus-nb-wmi.c-add-x45u-quirk.patch | 43 +++ ...-vmlogrdr-fix-iucv-buffer-allocation.patch | 35 ++ ...is7xx-drop-bogus-use-of-irqf_oneshot.patch | 62 ++++ ...p-of-the-scsi-device-s-request-queue.patch | 46 +++ ...h-does-not-support-jbod-sequence-map.patch | 45 +++ ...driver-waits-for-30secs-before-reset.patch | 38 +++ ...idual-hba-responses-at-default-level.patch | 105 ++++++ ...rport-unblock-race-with-lun-recovery.patch | 314 ++++++++++++++++++ ...er-free-in-fc-ingress-path-after-tmf.patch | 234 +++++++++++++ queue-4.4/series | 26 ++ .../vt-fix-scroll-lock-led-trigger-name.patch | 42 +++ 27 files changed, 1985 insertions(+) create mode 100644 queue-4.4/arc-mm-arc700-don-t-assume-2-colours-for-aliasing-vipt-dcache.patch create mode 100644 queue-4.4/block-protect-iterate_bdevs-against-concurrent-close.patch create mode 100644 queue-4.4/fgraph-handle-a-case-where-a-tracer-ignores-set_graph_notrace.patch create mode 100644 queue-4.4/firmware-fix-usermode-helper-fallback-loading.patch create mode 100644 queue-4.4/ftrace-x86_32-set-ftrace_stub-to-weak-to-prevent-gcc-from-using-short-jumps-to-it.patch create mode 100644 queue-4.4/ib-cma-fix-a-race-condition-in-iboe_addr_get_sgid.patch create mode 100644 queue-4.4/ib-mad-fix-an-array-index-check.patch create mode 100644 queue-4.4/ib-multicast-check-ib_find_pkey-return-value.patch create mode 100644 queue-4.4/input-drv260x-fix-input-device-s-parent-assignment.patch create mode 100644 queue-4.4/ipoib-avoid-reading-an-uninitialized-member-variable.patch create mode 100644 queue-4.4/kvm-nvmx-allow-l1-to-intercept-software-exceptions-bp-and-of.patch create mode 100644 queue-4.4/kvm-ppc-book3s-hv-don-t-lose-hardware-r-c-bit-updates-in-h_protect.patch create mode 100644 queue-4.4/kvm-ppc-book3s-hv-save-restore-xer-in-checkpointed-register-state.patch create mode 100644 queue-4.4/md-raid5-limit-request-size-according-to-implementation-limits.patch create mode 100644 queue-4.4/media-solo6x10-fix-lockup-by-avoiding-delayed-register-write.patch create mode 100644 queue-4.4/mei-request-async-autosuspend-at-the-end-of-enumeration.patch create mode 100644 queue-4.4/platform-x86-asus-nb-wmi.c-add-x45u-quirk.patch create mode 100644 queue-4.4/s390-vmlogrdr-fix-iucv-buffer-allocation.patch create mode 100644 queue-4.4/sc16is7xx-drop-bogus-use-of-irqf_oneshot.patch create mode 100644 queue-4.4/scsi-avoid-a-permanent-stop-of-the-scsi-device-s-request-queue.patch create mode 100644 queue-4.4/scsi-megaraid_sas-do-not-set-mpi2_type_cuda-for-jbod-fp-path-for-fw-which-does-not-support-jbod-sequence-map.patch create mode 100644 queue-4.4/scsi-megaraid_sas-for-sriov-enabled-firmware-ensure-vf-driver-waits-for-30secs-before-reset.patch create mode 100644 queue-4.4/scsi-zfcp-do-not-trace-pure-benign-residual-hba-responses-at-default-level.patch create mode 100644 queue-4.4/scsi-zfcp-fix-rport-unblock-race-with-lun-recovery.patch create mode 100644 queue-4.4/scsi-zfcp-fix-use-after-free-in-fc-ingress-path-after-tmf.patch create mode 100644 queue-4.4/vt-fix-scroll-lock-led-trigger-name.patch diff --git a/queue-4.4/arc-mm-arc700-don-t-assume-2-colours-for-aliasing-vipt-dcache.patch b/queue-4.4/arc-mm-arc700-don-t-assume-2-colours-for-aliasing-vipt-dcache.patch new file mode 100644 index 00000000000..70cfc694f90 --- /dev/null +++ b/queue-4.4/arc-mm-arc700-don-t-assume-2-colours-for-aliasing-vipt-dcache.patch @@ -0,0 +1,67 @@ +From 08fe007968b2b45e831daf74899f79a54d73f773 Mon Sep 17 00:00:00 2001 +From: Vineet Gupta +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 + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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"); ++ } + } + } + diff --git a/queue-4.4/block-protect-iterate_bdevs-against-concurrent-close.patch b/queue-4.4/block-protect-iterate_bdevs-against-concurrent-close.patch new file mode 100644 index 00000000000..65889c9f4ab --- /dev/null +++ b/queue-4.4/block-protect-iterate_bdevs-against-concurrent-close.patch @@ -0,0 +1,94 @@ +From af309226db916e2c6e08d3eba3fa5c34225200c4 Mon Sep 17 00:00:00 2001 +From: Rabin Vincent +Date: Thu, 1 Dec 2016 09:18:28 +0100 +Subject: block: protect iterate_bdevs() against concurrent close + +From: Rabin Vincent + +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: [] 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:[] [] 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: + [] __filemap_fdatawrite_range+0x85/0x90 + [] filemap_fdatawrite+0x1f/0x30 + [] fdatawrite_one_bdev+0x16/0x20 + [] iterate_bdevs+0xf2/0x130 + [] sys_sync+0x63/0x90 + [] 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 [] blk_get_backing_dev_info+0x10/0x20 + RSP + 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 +Signed-off-by: Rabin Vincent +Signed-off-by: Jan Kara +Reviewed-by: Christoph Hellwig +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } diff --git a/queue-4.4/fgraph-handle-a-case-where-a-tracer-ignores-set_graph_notrace.patch b/queue-4.4/fgraph-handle-a-case-where-a-tracer-ignores-set_graph_notrace.patch new file mode 100644 index 00000000000..40408ee2fe6 --- /dev/null +++ b/queue-4.4/fgraph-handle-a-case-where-a-tracer-ignores-set_graph_notrace.patch @@ -0,0 +1,108 @@ +From 794de08a16cf1fc1bf785dc48f66d36218cf6d88 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +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) + +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 +Fixes: 29ad23b00474 ("ftrace: Add set_graph_notrace filter") +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/firmware-fix-usermode-helper-fallback-loading.patch b/queue-4.4/firmware-fix-usermode-helper-fallback-loading.patch new file mode 100644 index 00000000000..9dd8777a3d6 --- /dev/null +++ b/queue-4.4/firmware-fix-usermode-helper-fallback-loading.patch @@ -0,0 +1,115 @@ +From 2e700f8d85975f516ccaad821278c1fe66b2cc98 Mon Sep 17 00:00:00 2001 +From: Yves-Alexis Perez +Date: Fri, 11 Nov 2016 11:28:40 -0800 +Subject: firmware: fix usermode helper fallback loading + +From: Yves-Alexis Perez + +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 +Fixes: 68ff2a00dbf5 "firmware_loader: handle timeout via wait_for_completion_interruptible_timeout()" +Cc: Luis R. Rodriguez +Cc: Ming Lei +Cc: Bjorn Andersson +Cc: Greg Kroah-Hartman +Acked-by: Luis R. Rodriguez +Reviewed-by: Bjorn Andersson +[mcgrof@kernel.org: gave commit log a whole lot of love] +Signed-off-by: Luis R. Rodriguez +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.4/ftrace-x86_32-set-ftrace_stub-to-weak-to-prevent-gcc-from-using-short-jumps-to-it.patch b/queue-4.4/ftrace-x86_32-set-ftrace_stub-to-weak-to-prevent-gcc-from-using-short-jumps-to-it.patch new file mode 100644 index 00000000000..f910f0b725f --- /dev/null +++ b/queue-4.4/ftrace-x86_32-set-ftrace_stub-to-weak-to-prevent-gcc-from-using-short-jumps-to-it.patch @@ -0,0 +1,43 @@ +From 847fa1a6d3d00f3bdf68ef5fa4a786f644a0dd67 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Red Hat)" +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) + +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 +Tested-by: Colin Ian King +Signed-off-by: Steven Rostedt +Signed-off-by: Greg Kroah-Hartman + +--- + 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) + diff --git a/queue-4.4/ib-cma-fix-a-race-condition-in-iboe_addr_get_sgid.patch b/queue-4.4/ib-cma-fix-a-race-condition-in-iboe_addr_get_sgid.patch new file mode 100644 index 00000000000..ee5669505a2 --- /dev/null +++ b/queue-4.4/ib-cma-fix-a-race-condition-in-iboe_addr_get_sgid.patch @@ -0,0 +1,42 @@ +From fba332b079029c2f4f7e84c1c1cd8e3867310c90 Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +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 + +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 +Reviewed-by: Moni Shoua +Cc: Or Gerlitz +Cc: Roland Dreier +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + } diff --git a/queue-4.4/ib-mad-fix-an-array-index-check.patch b/queue-4.4/ib-mad-fix-an-array-index-check.patch new file mode 100644 index 00000000000..5b94a36271d --- /dev/null +++ b/queue-4.4/ib-mad-fix-an-array-index-check.patch @@ -0,0 +1,38 @@ +From 2fe2f378dd45847d2643638c07a7658822087836 Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Mon, 21 Nov 2016 10:21:17 -0800 +Subject: IB/mad: Fix an array index check + +From: Bart Van Assche + +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 +Cc: Sean Hefty +Reviewed-by: Hal Rosenstock +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + 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)]; diff --git a/queue-4.4/ib-multicast-check-ib_find_pkey-return-value.patch b/queue-4.4/ib-multicast-check-ib_find_pkey-return-value.patch new file mode 100644 index 00000000000..09b2ac4ce18 --- /dev/null +++ b/queue-4.4/ib-multicast-check-ib_find_pkey-return-value.patch @@ -0,0 +1,38 @@ +From d3a2418ee36a59bc02e9d454723f3175dcf4bfd9 Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Mon, 21 Nov 2016 10:22:17 -0800 +Subject: IB/multicast: Check ib_find_pkey() return value + +From: Bart Van Assche + +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 +Cc: Sean Hefty +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + 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 && diff --git a/queue-4.4/input-drv260x-fix-input-device-s-parent-assignment.patch b/queue-4.4/input-drv260x-fix-input-device-s-parent-assignment.patch new file mode 100644 index 00000000000..2985e035f93 --- /dev/null +++ b/queue-4.4/input-drv260x-fix-input-device-s-parent-assignment.patch @@ -0,0 +1,37 @@ +From 5a8a6b89c15766446d845671d574a9243b6d8786 Mon Sep 17 00:00:00 2001 +From: Jingkui Wang +Date: Mon, 12 Dec 2016 13:51:46 -0800 +Subject: Input: drv260x - fix input device's parent assignment + +From: Jingkui Wang + +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 +Fixes: 7132fe4f5687 ("Input: drv260x - add TI drv260x haptics driver") +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/ipoib-avoid-reading-an-uninitialized-member-variable.patch b/queue-4.4/ipoib-avoid-reading-an-uninitialized-member-variable.patch new file mode 100644 index 00000000000..5c19228a8e6 --- /dev/null +++ b/queue-4.4/ipoib-avoid-reading-an-uninitialized-member-variable.patch @@ -0,0 +1,40 @@ +From 11b642b84e8c43e8597de031678d15c08dd057bc Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Mon, 21 Nov 2016 10:21:41 -0800 +Subject: IPoIB: Avoid reading an uninitialized member variable + +From: Bart Van Assche + +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 +Cc: Erez Shitrit +Reviewed-by: Leon Romanovsky +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/kvm-nvmx-allow-l1-to-intercept-software-exceptions-bp-and-of.patch b/queue-4.4/kvm-nvmx-allow-l1-to-intercept-software-exceptions-bp-and-of.patch new file mode 100644 index 00000000000..0b834a80520 --- /dev/null +++ b/queue-4.4/kvm-nvmx-allow-l1-to-intercept-software-exceptions-bp-and-of.patch @@ -0,0 +1,65 @@ +From ef85b67385436ddc1998f45f1d6a210f935b3388 Mon Sep 17 00:00:00 2001 +From: Jim Mattson +Date: Mon, 12 Dec 2016 11:01:37 -0800 +Subject: kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF) + +From: Jim Mattson + +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 +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/kvm-ppc-book3s-hv-don-t-lose-hardware-r-c-bit-updates-in-h_protect.patch b/queue-4.4/kvm-ppc-book3s-hv-don-t-lose-hardware-r-c-bit-updates-in-h_protect.patch new file mode 100644 index 00000000000..e9fcb8377c4 --- /dev/null +++ b/queue-4.4/kvm-ppc-book3s-hv-don-t-lose-hardware-r-c-bit-updates-in-h_protect.patch @@ -0,0 +1,45 @@ +From f064a0de1579fabded8990bed93971e30deb9ecb Mon Sep 17 00:00:00 2001 +From: Paul Mackerras +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 + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + } diff --git a/queue-4.4/kvm-ppc-book3s-hv-save-restore-xer-in-checkpointed-register-state.patch b/queue-4.4/kvm-ppc-book3s-hv-save-restore-xer-in-checkpointed-register-state.patch new file mode 100644 index 00000000000..f08de80dfa9 --- /dev/null +++ b/queue-4.4/kvm-ppc-book3s-hv-save-restore-xer-in-checkpointed-register-state.patch @@ -0,0 +1,129 @@ +From 0d808df06a44200f52262b6eb72bcb6042f5a7c5 Mon Sep 17 00:00:00 2001 +From: Paul Mackerras +Date: Mon, 7 Nov 2016 15:09:58 +1100 +Subject: KVM: PPC: Book3S HV: Save/restore XER in checkpointed register state + +From: Paul Mackerras + +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 +Reviewed-by: Thomas Huth +Signed-off-by: Paul Mackerras +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.4/md-raid5-limit-request-size-according-to-implementation-limits.patch b/queue-4.4/md-raid5-limit-request-size-according-to-implementation-limits.patch new file mode 100644 index 00000000000..c07e752196d --- /dev/null +++ b/queue-4.4/md-raid5-limit-request-size-according-to-implementation-limits.patch @@ -0,0 +1,51 @@ +From e8d7c33232e5fdfa761c3416539bc5b4acd12db5 Mon Sep 17 00:00:00 2001 +From: Konstantin Khlebnikov +Date: Sun, 27 Nov 2016 19:32:32 +0300 +Subject: md/raid5: limit request size according to implementation limits + +From: Konstantin Khlebnikov + +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 +Cc: Shaohua Li +Cc: Neil Brown +Signed-off-by: Shaohua Li +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.4/media-solo6x10-fix-lockup-by-avoiding-delayed-register-write.patch b/queue-4.4/media-solo6x10-fix-lockup-by-avoiding-delayed-register-write.patch new file mode 100644 index 00000000000..a983008853e --- /dev/null +++ b/queue-4.4/media-solo6x10-fix-lockup-by-avoiding-delayed-register-write.patch @@ -0,0 +1,46 @@ +From 5fc4b067ec082c3127e0156f800769b7e0dce078 Mon Sep 17 00:00:00 2001 +From: Andrey Utkin +Date: Sat, 22 Oct 2016 13:34:36 -0200 +Subject: [media] media: solo6x10: fix lockup by avoiding delayed register write + +From: Andrey Utkin + +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 +Signed-off-by: Hans Verkuil +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.4/mei-request-async-autosuspend-at-the-end-of-enumeration.patch b/queue-4.4/mei-request-async-autosuspend-at-the-end-of-enumeration.patch new file mode 100644 index 00000000000..c31391cc59f --- /dev/null +++ b/queue-4.4/mei-request-async-autosuspend-at-the-end-of-enumeration.patch @@ -0,0 +1,37 @@ +From d5f8e166c25750adc147b0adf64a62a91653438a Mon Sep 17 00:00:00 2001 +From: Alexander Usyskin +Date: Thu, 24 Nov 2016 13:34:02 +0200 +Subject: mei: request async autosuspend at the end of enumeration + +From: Alexander Usyskin + +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 +Signed-off-by: Tomas Winkler +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + + /** diff --git a/queue-4.4/platform-x86-asus-nb-wmi.c-add-x45u-quirk.patch b/queue-4.4/platform-x86-asus-nb-wmi.c-add-x45u-quirk.patch new file mode 100644 index 00000000000..c7e65363722 --- /dev/null +++ b/queue-4.4/platform-x86-asus-nb-wmi.c-add-x45u-quirk.patch @@ -0,0 +1,43 @@ +From e74e259939275a5dd4e0d02845c694f421e249ad Mon Sep 17 00:00:00 2001 +From: Marcos Paulo de Souza +Date: Tue, 29 Nov 2016 23:23:06 -0200 +Subject: platform/x86: asus-nb-wmi.c: Add X45U quirk + +From: Marcos Paulo de Souza + +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 +Signed-off-by: Andy Shevchenko +Signed-off-by: Greg Kroah-Hartman + +--- + 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."), diff --git a/queue-4.4/s390-vmlogrdr-fix-iucv-buffer-allocation.patch b/queue-4.4/s390-vmlogrdr-fix-iucv-buffer-allocation.patch new file mode 100644 index 00000000000..553c3aa0014 --- /dev/null +++ b/queue-4.4/s390-vmlogrdr-fix-iucv-buffer-allocation.patch @@ -0,0 +1,35 @@ +From 5457e03de918f7a3e294eb9d26a608ab8a579976 Mon Sep 17 00:00:00 2001 +From: Gerald Schaefer +Date: Mon, 21 Nov 2016 12:13:58 +0100 +Subject: s390/vmlogrdr: fix IUCV buffer allocation + +From: Gerald Schaefer + +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 +Signed-off-by: Martin Schwidefsky +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/sc16is7xx-drop-bogus-use-of-irqf_oneshot.patch b/queue-4.4/sc16is7xx-drop-bogus-use-of-irqf_oneshot.patch new file mode 100644 index 00000000000..79fa36c5ab4 --- /dev/null +++ b/queue-4.4/sc16is7xx-drop-bogus-use-of-irqf_oneshot.patch @@ -0,0 +1,62 @@ +From 04da73803c05dc1150ccc31cbf93e8cd56679c09 Mon Sep 17 00:00:00 2001 +From: Josh Cartwright +Date: Thu, 13 Oct 2016 10:44:33 -0500 +Subject: sc16is7xx: Drop bogus use of IRQF_ONESHOT + +From: Josh Cartwright + +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 +Signed-off-by: Josh Cartwright +Cc: linux-rt-users@vger.kernel.org +Cc: Jakub Kicinski +Cc: linux-serial@vger.kernel.org +Cc: Sebastian Andrzej Siewior +Signed-off-by: Julia Cartwright +Acked-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-4.4/scsi-avoid-a-permanent-stop-of-the-scsi-device-s-request-queue.patch b/queue-4.4/scsi-avoid-a-permanent-stop-of-the-scsi-device-s-request-queue.patch new file mode 100644 index 00000000000..e84d7c85865 --- /dev/null +++ b/queue-4.4/scsi-avoid-a-permanent-stop-of-the-scsi-device-s-request-queue.patch @@ -0,0 +1,46 @@ +From d2a145252c52792bc59e4767b486b26c430af4bb Mon Sep 17 00:00:00 2001 +From: Wei Fang +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 + +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 +Signed-off-by: Wei Fang +Reviewed-by: Ewan D. Milne +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/scsi-megaraid_sas-do-not-set-mpi2_type_cuda-for-jbod-fp-path-for-fw-which-does-not-support-jbod-sequence-map.patch b/queue-4.4/scsi-megaraid_sas-do-not-set-mpi2_type_cuda-for-jbod-fp-path-for-fw-which-does-not-support-jbod-sequence-map.patch new file mode 100644 index 00000000000..ed05efc84ab --- /dev/null +++ b/queue-4.4/scsi-megaraid_sas-do-not-set-mpi2_type_cuda-for-jbod-fp-path-for-fw-which-does-not-support-jbod-sequence-map.patch @@ -0,0 +1,45 @@ +From d5573584429254a14708cf8375c47092b5edaf2c Mon Sep 17 00:00:00 2001 +From: Kashyap Desai +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 + +commit d5573584429254a14708cf8375c47092b5edaf2c upstream. + +Signed-off-by: Sumit Saxena +Reviewed-by: Hannes Reinecke +Reviewed-by: Tomas Henzl +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.4/scsi-megaraid_sas-for-sriov-enabled-firmware-ensure-vf-driver-waits-for-30secs-before-reset.patch b/queue-4.4/scsi-megaraid_sas-for-sriov-enabled-firmware-ensure-vf-driver-waits-for-30secs-before-reset.patch new file mode 100644 index 00000000000..60602e16b4b --- /dev/null +++ b/queue-4.4/scsi-megaraid_sas-for-sriov-enabled-firmware-ensure-vf-driver-waits-for-30secs-before-reset.patch @@ -0,0 +1,38 @@ +From 18e1c7f68a5814442abad849abe6eacbf02ffd7c Mon Sep 17 00:00:00 2001 +From: Kashyap Desai +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 + +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 +Signed-off-by: Sumit Saxena +Reviewed-by: Hannes Reinecke +Reviewed-by: Tomas Henzl +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-4.4/scsi-zfcp-do-not-trace-pure-benign-residual-hba-responses-at-default-level.patch b/queue-4.4/scsi-zfcp-do-not-trace-pure-benign-residual-hba-responses-at-default-level.patch new file mode 100644 index 00000000000..65b8fb78a01 --- /dev/null +++ b/queue-4.4/scsi-zfcp-do-not-trace-pure-benign-residual-hba-responses-at-default-level.patch @@ -0,0 +1,105 @@ +From 56d23ed7adf3974f10e91b643bd230e9c65b5f79 Mon Sep 17 00:00:00 2001 +From: Steffen Maier +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 + +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 +Fixes: a54ca0f62f95 ("[SCSI] zfcp: Redesign of the debug tracing for HBA records.") +Reviewed-by: Benjamin Block +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.4/scsi-zfcp-fix-rport-unblock-race-with-lun-recovery.patch b/queue-4.4/scsi-zfcp-fix-rport-unblock-race-with-lun-recovery.patch new file mode 100644 index 00000000000..e176b8f648e --- /dev/null +++ b/queue-4.4/scsi-zfcp-fix-rport-unblock-race-with-lun-recovery.patch @@ -0,0 +1,314 @@ +From 6f2ce1c6af37191640ee3ff6e8fc39ea10352f4c Mon Sep 17 00:00:00 2001 +From: Steffen Maier +Date: Fri, 9 Dec 2016 17:16:33 +0100 +Subject: scsi: zfcp: fix rport unblock race with LUN recovery + +From: Steffen Maier + +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 +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 +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + */ diff --git a/queue-4.4/scsi-zfcp-fix-use-after-free-in-fc-ingress-path-after-tmf.patch b/queue-4.4/scsi-zfcp-fix-use-after-free-in-fc-ingress-path-after-tmf.patch new file mode 100644 index 00000000000..e51d4ff58bd --- /dev/null +++ b/queue-4.4/scsi-zfcp-fix-use-after-free-in-fc-ingress-path-after-tmf.patch @@ -0,0 +1,234 @@ +From dac37e15b7d511e026a9313c8c46794c144103cd Mon Sep 17 00:00:00 2001 +From: Benjamin Block +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 + +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 +Signed-off-by: Benjamin Block +Fixes: ea127f9754 ("[PATCH] s390 (7/7): zfcp host adapter.") (tglx/history.git) +Signed-off-by: Steffen Maier +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.4/series b/queue-4.4/series index 0feb909752d..023c642974d 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -21,3 +21,29 @@ drm-radeon-hide-the-hw-cursor-while-it-s-out-of-bounds.patch 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 diff --git a/queue-4.4/vt-fix-scroll-lock-led-trigger-name.patch b/queue-4.4/vt-fix-scroll-lock-led-trigger-name.patch new file mode 100644 index 00000000000..19bdfc04513 --- /dev/null +++ b/queue-4.4/vt-fix-scroll-lock-led-trigger-name.patch @@ -0,0 +1,42 @@ +From 31b5929d533f5183972cf57a7844b456ed996f3c Mon Sep 17 00:00:00 2001 +From: "Maciej S. Szmigiero" +Date: Wed, 16 Nov 2016 00:55:57 +0100 +Subject: vt: fix Scroll Lock LED trigger name + +From: Maciej S. Szmigiero + +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 +Acked-by: Samuel Thibault +Signed-off-by: Greg Kroah-Hartman + +--- + 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"), -- 2.47.3