From: Greg Kroah-Hartman Date: Mon, 20 Feb 2017 05:12:34 +0000 (+0100) Subject: 4.4-stable patches X-Git-Tag: v4.4.51~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=75b56c1d23ec242a1832b1440bfb29e4be5c1846;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch fix-missing-sanity-check-in-dev-sg.patch fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch futex-move-futex_init-to-core_initcall.patch input-elan_i2c-add-elan0605-to-the-acpi-table.patch printk-use-rcuidle-console-tracepoint.patch scsi-don-t-bug_on-empty-dma-transfers.patch siano-make-it-work-again-with-config_vmap_stack.patch vfs-fix-uninitialized-flags-in-splice_to_pipe.patch --- diff --git a/queue-4.4/arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch b/queue-4.4/arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch new file mode 100644 index 00000000000..acb097fccad --- /dev/null +++ b/queue-4.4/arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch @@ -0,0 +1,32 @@ +From 9e3440481845b2ec22508f60837ee2cab2b6054f Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Thu, 16 Feb 2017 01:44:37 +0100 +Subject: ARM: 8658/1: uaccess: fix zeroing of 64-bit get_user() + +From: Kees Cook + +commit 9e3440481845b2ec22508f60837ee2cab2b6054f upstream. + +The 64-bit get_user() wasn't clearing the high word due to a typo in the +error handler. The exception handler entry was already correct, though. +Noticed during recent usercopy test additions in lib/test_user_copy.c. + +Signed-off-by: Kees Cook +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/lib/getuser.S | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/lib/getuser.S ++++ b/arch/arm/lib/getuser.S +@@ -67,7 +67,7 @@ ENTRY(__get_user_4) + ENDPROC(__get_user_4) + + ENTRY(__get_user_8) +- check_uaccess r0, 8, r1, r2, __get_user_bad ++ check_uaccess r0, 8, r1, r2, __get_user_bad8 + #ifdef CONFIG_THUMB2_KERNEL + 5: TUSER(ldr) r2, [r0] + 6: TUSER(ldr) r3, [r0, #4] diff --git a/queue-4.4/drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch b/queue-4.4/drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch new file mode 100644 index 00000000000..d8447a596bb --- /dev/null +++ b/queue-4.4/drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch @@ -0,0 +1,56 @@ +From bb08c04dc867b5f392caec635c097d5d5fcd8c9f Mon Sep 17 00:00:00 2001 +From: Pierre-Louis Bossart +Date: Tue, 14 Feb 2017 14:49:21 +0200 +Subject: drm/dp/mst: fix kernel oops when turning off secondary monitor + +From: Pierre-Louis Bossart + +commit bb08c04dc867b5f392caec635c097d5d5fcd8c9f upstream. + +100% reproducible issue found on SKL SkullCanyon NUC with two external +DP daisy-chained monitors in DP/MST mode. When turning off or changing +the input of the second monitor the machine stops with a kernel +oops. This issue happened with 4.8.8 as well as drm/drm-intel-nightly. + +This issue is traced to an inconsistent control flow in +drm_dp_update_payload_part1(): the 'port' pointer is set to NULL at the +same time as 'req_payload.num_slots' is set to zero, but the pointer is +dereferenced even when req_payload.num_slot is zero. + +The problematic dereference was introduced in commit dfda0df34 +("drm/mst: rework payload table allocation to conform better") and may +impact all versions since v3.18 + +The fix suggested by Chris Wilson removes the kernel oops and was found to +work well after 10mn of monkey-testing with the second monitor power and +input buttons + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98990 +Fixes: dfda0df34264 ("drm/mst: rework payload table allocation to conform better.") +Cc: Dave Airlie +Cc: Chris Wilson +Cc: Nathan D Ciobanu +Cc: Dhinakaran Pandiyan +Cc: Sean Paul +Tested-by: Nathan D Ciobanu +Reviewed-by: Dhinakaran Pandiyan +Signed-off-by: Pierre-Louis Bossart +Signed-off-by: Jani Nikula +Link: http://patchwork.freedesktop.org/patch/msgid/1487076561-2169-1-git-send-email-jani.nikula@intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_dp_mst_topology.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/drm_dp_mst_topology.c ++++ b/drivers/gpu/drm/drm_dp_mst_topology.c +@@ -1812,7 +1812,7 @@ int drm_dp_update_payload_part1(struct d + mgr->payloads[i].num_slots = req_payload.num_slots; + } else if (mgr->payloads[i].num_slots) { + mgr->payloads[i].num_slots = 0; +- drm_dp_destroy_payload_step1(mgr, port, port->vcpi.vcpi, &mgr->payloads[i]); ++ drm_dp_destroy_payload_step1(mgr, port, mgr->payloads[i].vcpi, &mgr->payloads[i]); + req_payload.payload_state = mgr->payloads[i].payload_state; + mgr->payloads[i].start_slot = 0; + } diff --git a/queue-4.4/drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch b/queue-4.4/drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch new file mode 100644 index 00000000000..f15fdebc8fa --- /dev/null +++ b/queue-4.4/drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch @@ -0,0 +1,43 @@ +From d74c67dd7800fc7aae381f272875c337f268806c Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Michel=20D=C3=A4nzer?= +Date: Wed, 15 Feb 2017 11:28:45 +0900 +Subject: drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Michel Dänzer + +commit d74c67dd7800fc7aae381f272875c337f268806c upstream. + +The crtc_h/vdisplay fields may not match the CRTC viewport dimensions +with special modes such as interlaced ones. + +Fixes the HW cursor disappearing in the bottom half of the screen with +interlaced modes. + +Fixes: 6b16cf7785a4 ("drm/radeon: Hide the HW cursor while it's out of bounds") +Reported-by: Ashutosh Kumar +Tested-by: Sonny Jiang +Reviewed-by: Alex Deucher +Signed-off-by: Michel Dänzer +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_cursor.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/radeon/radeon_cursor.c ++++ b/drivers/gpu/drm/radeon/radeon_cursor.c +@@ -205,8 +205,8 @@ static int radeon_cursor_move_locked(str + } + + if (x <= (crtc->x - w) || y <= (crtc->y - radeon_crtc->cursor_height) || +- x >= (crtc->x + crtc->mode.crtc_hdisplay) || +- y >= (crtc->y + crtc->mode.crtc_vdisplay)) ++ x >= (crtc->x + crtc->mode.hdisplay) || ++ y >= (crtc->y + crtc->mode.vdisplay)) + goto out_of_bounds; + + x += xorigin; diff --git a/queue-4.4/fix-missing-sanity-check-in-dev-sg.patch b/queue-4.4/fix-missing-sanity-check-in-dev-sg.patch new file mode 100644 index 00000000000..c12cc1983b8 --- /dev/null +++ b/queue-4.4/fix-missing-sanity-check-in-dev-sg.patch @@ -0,0 +1,44 @@ +From 137d01df511b3afe1f05499aea05f3bafc0fb221 Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Sun, 19 Feb 2017 07:15:27 +0000 +Subject: Fix missing sanity check in /dev/sg + +From: Al Viro + +commit 137d01df511b3afe1f05499aea05f3bafc0fb221 upstream. + +What happens is that a write to /dev/sg is given a request with non-zero +->iovec_count combined with zero ->dxfer_len. Or with ->dxferp pointing +to an array full of empty iovecs. + +Having write permission to /dev/sg shouldn't be equivalent to the +ability to trigger BUG_ON() while holding spinlocks... + +Found by Dmitry Vyukov and syzkaller. + +[ The BUG_ON() got changed to a WARN_ON_ONCE(), but this fixes the + underlying issue. - Linus ] + +Signed-off-by: Al Viro +Reported-by: Dmitry Vyukov +Reviewed-by: Christoph Hellwig +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/sg.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/scsi/sg.c ++++ b/drivers/scsi/sg.c +@@ -1763,6 +1763,10 @@ sg_start_req(Sg_request *srp, unsigned c + return res; + + iov_iter_truncate(&i, hp->dxfer_len); ++ if (!iov_iter_count(&i)) { ++ kfree(iov); ++ return -EINVAL; ++ } + + res = blk_rq_map_user_iov(q, rq, md, &i, GFP_ATOMIC); + kfree(iov); diff --git a/queue-4.4/fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch b/queue-4.4/fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch new file mode 100644 index 00000000000..fe29ef3040f --- /dev/null +++ b/queue-4.4/fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch @@ -0,0 +1,80 @@ +From 6ba4d2722d06960102c981322035239cd66f7316 Mon Sep 17 00:00:00 2001 +From: Sahitya Tummala +Date: Wed, 8 Feb 2017 20:30:56 +0530 +Subject: fuse: fix use after free issue in fuse_dev_do_read() + +From: Sahitya Tummala + +commit 6ba4d2722d06960102c981322035239cd66f7316 upstream. + +There is a potential race between fuse_dev_do_write() +and request_wait_answer() contexts as shown below: + +TASK 1: +__fuse_request_send(): + |--spin_lock(&fiq->waitq.lock); + |--queue_request(); + |--spin_unlock(&fiq->waitq.lock); + |--request_wait_answer(): + |--if (test_bit(FR_SENT, &req->flags)) + + TASK 2: + fuse_dev_do_write(): + |--clears bit FR_SENT, + |--request_end(): + |--sets bit FR_FINISHED + |--spin_lock(&fiq->waitq.lock); + |--list_del_init(&req->intr_entry); + |--spin_unlock(&fiq->waitq.lock); + |--fuse_put_request(); + |--queue_interrupt(); + + |--wake_up_locked(&fiq->waitq); + |--wait_event_freezable(); + + +Now, the next fuse_dev_do_read(), see interrupts list is not empty +and then calls fuse_read_interrupt() which tries to access the request +which is already free'd and gets the below crash: + +[11432.401266] Unable to handle kernel paging request at virtual address +6b6b6b6b6b6b6b6b +... +[11432.418518] Kernel BUG at ffffff80083720e0 +[11432.456168] PC is at __list_del_entry+0x6c/0xc4 +[11432.463573] LR is at fuse_dev_do_read+0x1ac/0x474 +... +[11432.679999] [] __list_del_entry+0x6c/0xc4 +[11432.687794] [] fuse_dev_do_read+0x1ac/0x474 +[11432.693180] [] fuse_dev_read+0x6c/0x78 +[11432.699082] [] __vfs_read+0xc0/0xe8 +[11432.704459] [] vfs_read+0x90/0x108 +[11432.709406] [] SyS_read+0x58/0x94 + +As FR_FINISHED bit is set before deleting the intr_entry with input +queue lock in request completion path, do the testing of this flag and +queueing atomically with the same lock in queue_interrupt(). + +Signed-off-by: Sahitya Tummala +Signed-off-by: Miklos Szeredi +Fixes: fd22d62ed0c3 ("fuse: no fc->lock for iqueue parts") +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dev.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -418,6 +418,10 @@ static void request_end(struct fuse_conn + static void queue_interrupt(struct fuse_iqueue *fiq, struct fuse_req *req) + { + spin_lock(&fiq->waitq.lock); ++ if (test_bit(FR_FINISHED, &req->flags)) { ++ spin_unlock(&fiq->waitq.lock); ++ return; ++ } + if (list_empty(&req->intr_entry)) { + list_add_tail(&req->intr_entry, &fiq->interrupts); + wake_up_locked(&fiq->waitq); diff --git a/queue-4.4/futex-move-futex_init-to-core_initcall.patch b/queue-4.4/futex-move-futex_init-to-core_initcall.patch new file mode 100644 index 00000000000..36358b4743d --- /dev/null +++ b/queue-4.4/futex-move-futex_init-to-core_initcall.patch @@ -0,0 +1,50 @@ +From 25f71d1c3e98ef0e52371746220d66458eac75bc Mon Sep 17 00:00:00 2001 +From: Yang Yang +Date: Fri, 30 Dec 2016 16:17:55 +0800 +Subject: futex: Move futex_init() to core_initcall + +From: Yang Yang + +commit 25f71d1c3e98ef0e52371746220d66458eac75bc upstream. + +The UEVENT user mode helper is enabled before the initcalls are executed +and is available when the root filesystem has been mounted. + +The user mode helper is triggered by device init calls and the executable +might use the futex syscall. + +futex_init() is marked __initcall which maps to device_initcall, but there +is no guarantee that futex_init() is invoked _before_ the first device init +call which triggers the UEVENT user mode helper. + +If the user mode helper uses the futex syscall before futex_init() then the +syscall crashes with a NULL pointer dereference because the futex subsystem +has not been initialized yet. + +Move futex_init() to core_initcall so futexes are initialized before the +root filesystem is mounted and the usermode helper becomes available. + +[ tglx: Rewrote changelog ] + +Signed-off-by: Yang Yang +Cc: jiang.biao2@zte.com.cn +Cc: jiang.zhengxiong@zte.com.cn +Cc: zhong.weidong@zte.com.cn +Cc: deng.huali@zte.com.cn +Cc: Peter Zijlstra +Link: http://lkml.kernel.org/r/1483085875-6130-1-git-send-email-yang.yang29@zte.com.cn +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -3199,4 +3199,4 @@ static int __init futex_init(void) + + return 0; + } +-__initcall(futex_init); ++core_initcall(futex_init); diff --git a/queue-4.4/input-elan_i2c-add-elan0605-to-the-acpi-table.patch b/queue-4.4/input-elan_i2c-add-elan0605-to-the-acpi-table.patch new file mode 100644 index 00000000000..d684fcf15d8 --- /dev/null +++ b/queue-4.4/input-elan_i2c-add-elan0605-to-the-acpi-table.patch @@ -0,0 +1,31 @@ +From 722c5ac708b4f5c1fcfad5fed4c95234c8b06590 Mon Sep 17 00:00:00 2001 +From: IHARA Hiroka +Date: Sun, 12 Feb 2017 18:34:53 -0800 +Subject: Input: elan_i2c - add ELAN0605 to the ACPI table + +From: IHARA Hiroka + +commit 722c5ac708b4f5c1fcfad5fed4c95234c8b06590 upstream. + +ELAN0605 has been confirmed to be a variant of ELAN0600, which is +blacklisted in the hid-core to be managed by elan_i2c. This device can be +found in Lenovo ideapad 310s (80U4000). + +Signed-off-by: Hiroka IHARA +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/elan_i2c_core.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/input/mouse/elan_i2c_core.c ++++ b/drivers/input/mouse/elan_i2c_core.c +@@ -1232,6 +1232,7 @@ static const struct acpi_device_id elan_ + { "ELAN0000", 0 }, + { "ELAN0100", 0 }, + { "ELAN0600", 0 }, ++ { "ELAN0605", 0 }, + { "ELAN1000", 0 }, + { } + }; diff --git a/queue-4.4/printk-use-rcuidle-console-tracepoint.patch b/queue-4.4/printk-use-rcuidle-console-tracepoint.patch new file mode 100644 index 00000000000..bb60c5ca85e --- /dev/null +++ b/queue-4.4/printk-use-rcuidle-console-tracepoint.patch @@ -0,0 +1,83 @@ +From fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c Mon Sep 17 00:00:00 2001 +From: Sergey Senozhatsky +Date: Sat, 18 Feb 2017 03:42:54 -0800 +Subject: printk: use rcuidle console tracepoint + +From: Sergey Senozhatsky + +commit fc98c3c8c9dcafd67adcce69e6ce3191d5306c9c upstream. + +Use rcuidle console tracepoint because, apparently, it may be issued +from an idle CPU: + + hw-breakpoint: Failed to enable monitor mode on CPU 0. + hw-breakpoint: CPU 0 failed to disable vector catch + + =============================== + [ ERR: suspicious RCU usage. ] + 4.10.0-rc8-next-20170215+ #119 Not tainted + ------------------------------- + ./include/trace/events/printk.h:32 suspicious rcu_dereference_check() usage! + + other info that might help us debug this: + + RCU used illegally from idle CPU! + rcu_scheduler_active = 2, debug_locks = 0 + RCU used illegally from extended quiescent state! + 2 locks held by swapper/0/0: + #0: (cpu_pm_notifier_lock){......}, at: [] cpu_pm_exit+0x10/0x54 + #1: (console_lock){+.+.+.}, at: [] vprintk_emit+0x264/0x474 + + stack backtrace: + CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.0-rc8-next-20170215+ #119 + Hardware name: Generic OMAP4 (Flattened Device Tree) + console_unlock + vprintk_emit + vprintk_default + printk + reset_ctrl_regs + dbg_cpu_pm_notify + notifier_call_chain + cpu_pm_exit + omap_enter_idle_coupled + cpuidle_enter_state + cpuidle_enter_state_coupled + do_idle + cpu_startup_entry + start_kernel + +This RCU warning, however, is suppressed by lockdep_off() in printk(). +lockdep_off() increments the ->lockdep_recursion counter and thus +disables RCU_LOCKDEP_WARN() and debug_lockdep_rcu_enabled(), which want +lockdep to be enabled "current->lockdep_recursion == 0". + +Link: http://lkml.kernel.org/r/20170217015932.11898-1-sergey.senozhatsky@gmail.com +Signed-off-by: Sergey Senozhatsky +Reported-by: Tony Lindgren +Tested-by: Tony Lindgren +Acked-by: Paul E. McKenney +Acked-by: Steven Rostedt (VMware) +Cc: Petr Mladek +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: Tony Lindgren +Cc: Russell King +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/printk/printk.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/kernel/printk/printk.c ++++ b/kernel/printk/printk.c +@@ -1436,7 +1436,7 @@ static void call_console_drivers(int lev + { + struct console *con; + +- trace_console(text, len); ++ trace_console_rcuidle(text, len); + + if (level >= console_loglevel && !ignore_loglevel) + return; diff --git a/queue-4.4/scsi-don-t-bug_on-empty-dma-transfers.patch b/queue-4.4/scsi-don-t-bug_on-empty-dma-transfers.patch new file mode 100644 index 00000000000..56854711b23 --- /dev/null +++ b/queue-4.4/scsi-don-t-bug_on-empty-dma-transfers.patch @@ -0,0 +1,49 @@ +From fd3fc0b4d7305fa7246622dcc0dec69c42443f45 Mon Sep 17 00:00:00 2001 +From: Johannes Thumshirn +Date: Tue, 31 Jan 2017 10:16:00 +0100 +Subject: scsi: don't BUG_ON() empty DMA transfers + +From: Johannes Thumshirn + +commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream. + +Don't crash the machine just because of an empty transfer. Use WARN_ON() +combined with returning an error. + +Found by Dmitry Vyukov and syzkaller. + +[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root + cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON() + might still be a cause of excessive log spamming. + + NOTE! If this warning ever triggers, we may end up leaking resources, + since this doesn't bother to try to clean the command up. So this + WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is + much worse. + + People really need to stop using BUG_ON() for "this shouldn't ever + happen". It makes pretty much any bug worse. - Linus ] + +Signed-off-by: Johannes Thumshirn +Reported-by: Dmitry Vyukov +Cc: James Bottomley +Cc: Al Viro +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/scsi_lib.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/scsi/scsi_lib.c ++++ b/drivers/scsi/scsi_lib.c +@@ -1120,7 +1120,8 @@ int scsi_init_io(struct scsi_cmnd *cmd) + bool is_mq = (rq->mq_ctx != NULL); + int error; + +- BUG_ON(!rq->nr_phys_segments); ++ if (WARN_ON_ONCE(!rq->nr_phys_segments)) ++ return -EINVAL; + + error = scsi_init_sgtable(rq, &cmd->sdb); + if (error) diff --git a/queue-4.4/series b/queue-4.4/series index 01030f4cab5..7458ba0e606 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -1 +1,12 @@ tcp-fix-mark-propagation-with-fwmark_reflect-enabled.patch +vfs-fix-uninitialized-flags-in-splice_to_pipe.patch +siano-make-it-work-again-with-config_vmap_stack.patch +fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch +scsi-don-t-bug_on-empty-dma-transfers.patch +fix-missing-sanity-check-in-dev-sg.patch +input-elan_i2c-add-elan0605-to-the-acpi-table.patch +drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch +drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch +futex-move-futex_init-to-core_initcall.patch +arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch +printk-use-rcuidle-console-tracepoint.patch diff --git a/queue-4.4/siano-make-it-work-again-with-config_vmap_stack.patch b/queue-4.4/siano-make-it-work-again-with-config_vmap_stack.patch new file mode 100644 index 00000000000..53429dff9b2 --- /dev/null +++ b/queue-4.4/siano-make-it-work-again-with-config_vmap_stack.patch @@ -0,0 +1,68 @@ +From f9c85ee67164b37f9296eab3b754e543e4e96a1c Mon Sep 17 00:00:00 2001 +From: Mauro Carvalho Chehab +Date: Tue, 14 Feb 2017 17:47:57 -0200 +Subject: [media] siano: make it work again with CONFIG_VMAP_STACK + +From: Mauro Carvalho Chehab + +commit f9c85ee67164b37f9296eab3b754e543e4e96a1c upstream. + +Reported as a Kaffeine bug: + https://bugs.kde.org/show_bug.cgi?id=375811 + +The USB control messages require DMA to work. We cannot pass +a stack-allocated buffer, as it is not warranted that the +stack would be into a DMA enabled area. + +On Kernel 4.9, the default is to not accept DMA on stack anymore +on x86 architecture. On other architectures, this has been a +requirement since Kernel 2.2. So, after this patch, this driver +should likely work fine on all archs. + +Tested with USB ID 2040:5510: Hauppauge Windham + +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/usb/siano/smsusb.c | 18 +++++++++++++----- + 1 file changed, 13 insertions(+), 5 deletions(-) + +--- a/drivers/media/usb/siano/smsusb.c ++++ b/drivers/media/usb/siano/smsusb.c +@@ -200,22 +200,30 @@ static int smsusb_start_streaming(struct + static int smsusb_sendrequest(void *context, void *buffer, size_t size) + { + struct smsusb_device_t *dev = (struct smsusb_device_t *) context; +- struct sms_msg_hdr *phdr = (struct sms_msg_hdr *) buffer; +- int dummy; ++ struct sms_msg_hdr *phdr; ++ int dummy, ret; + + if (dev->state != SMSUSB_ACTIVE) { + pr_debug("Device not active yet\n"); + return -ENOENT; + } + ++ phdr = kmalloc(size, GFP_KERNEL); ++ if (!phdr) ++ return -ENOMEM; ++ memcpy(phdr, buffer, size); ++ + pr_debug("sending %s(%d) size: %d\n", + smscore_translate_msg(phdr->msg_type), phdr->msg_type, + phdr->msg_length); + + smsendian_handle_tx_message((struct sms_msg_data *) phdr); +- smsendian_handle_message_header((struct sms_msg_hdr *)buffer); +- return usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2), +- buffer, size, &dummy, 1000); ++ smsendian_handle_message_header((struct sms_msg_hdr *)phdr); ++ ret = usb_bulk_msg(dev->udev, usb_sndbulkpipe(dev->udev, 2), ++ phdr, size, &dummy, 1000); ++ ++ kfree(phdr); ++ return ret; + } + + static char *smsusb1_fw_lkup[] = { diff --git a/queue-4.4/vfs-fix-uninitialized-flags-in-splice_to_pipe.patch b/queue-4.4/vfs-fix-uninitialized-flags-in-splice_to_pipe.patch new file mode 100644 index 00000000000..e5fc8ae7c91 --- /dev/null +++ b/queue-4.4/vfs-fix-uninitialized-flags-in-splice_to_pipe.patch @@ -0,0 +1,34 @@ +From 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Thu, 16 Feb 2017 17:49:02 +0100 +Subject: vfs: fix uninitialized flags in splice_to_pipe() + +From: Miklos Szeredi + +commit 5a81e6a171cdbd1fa8bc1fdd80c23d3d71816fac upstream. + +Flags (PIPE_BUF_FLAG_PACKET, PIPE_BUF_FLAG_GIFT) could remain on the +unused part of the pipe ring buffer. Previously splice_to_pipe() left +the flags value alone, which could result in incorrect behavior. + +Uninitialized flags appears to have been there from the introduction of +the splice syscall. + +Signed-off-by: Miklos Szeredi +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + fs/splice.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/splice.c ++++ b/fs/splice.c +@@ -211,6 +211,7 @@ ssize_t splice_to_pipe(struct pipe_inode + buf->len = spd->partial[page_nr].len; + buf->private = spd->partial[page_nr].private; + buf->ops = spd->ops; ++ buf->flags = 0; + if (spd->flags & SPLICE_F_GIFT) + buf->flags |= PIPE_BUF_FLAG_GIFT; +