From: Greg Kroah-Hartman Date: Mon, 20 Feb 2017 05:13:12 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.4.51~11 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=2e3c29fd3e0fb2128447520c372de47950cca51d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-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-uninitialized-flags-in-pipe_buffer.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 mmc-core-fix-multi-bit-bus-width-without-high-speed-mode.patch pci-pme-restore-pcie_pme_driver.remove.patch powerpc-64-disable-use-of-radix-under-a-hypervisor.patch printk-use-rcuidle-console-tracepoint.patch revert-i2c-designware-detect-when-dynamic-tar-update-is-possible.patch scsi-don-t-bug_on-empty-dma-transfers.patch siano-make-it-work-again-with-config_vmap_stack.patch timekeeping-use-deferred-printk-in-debug-code.patch vfs-fix-uninitialized-flags-in-splice_to_pipe.patch --- diff --git a/queue-4.9/arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch b/queue-4.9/arm-8658-1-uaccess-fix-zeroing-of-64-bit-get_user.patch new file mode 100644 index 00000000000..acb097fccad --- /dev/null +++ b/queue-4.9/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.9/drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch b/queue-4.9/drm-dp-mst-fix-kernel-oops-when-turning-off-secondary-monitor.patch new file mode 100644 index 00000000000..0b673043877 --- /dev/null +++ b/queue-4.9/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 +@@ -1817,7 +1817,7 @@ int drm_dp_update_payload_part1(struct d + mgr->payloads[i].vcpi = req_payload.vcpi; + } 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.9/drm-radeon-use-mode-h-vdisplay-fields-to-hide-out-of-bounds-hw-cursor.patch b/queue-4.9/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.9/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.9/fix-missing-sanity-check-in-dev-sg.patch b/queue-4.9/fix-missing-sanity-check-in-dev-sg.patch new file mode 100644 index 00000000000..7b9f346989e --- /dev/null +++ b/queue-4.9/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 +@@ -1753,6 +1753,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.9/fuse-fix-uninitialized-flags-in-pipe_buffer.patch b/queue-4.9/fuse-fix-uninitialized-flags-in-pipe_buffer.patch new file mode 100644 index 00000000000..de9fdc5f175 --- /dev/null +++ b/queue-4.9/fuse-fix-uninitialized-flags-in-pipe_buffer.patch @@ -0,0 +1,27 @@ +From 84588a93d097bace24b9233930f82511d4f34210 Mon Sep 17 00:00:00 2001 +From: Miklos Szeredi +Date: Thu, 16 Feb 2017 15:08:20 +0100 +Subject: fuse: fix uninitialized flags in pipe_buffer + +From: Miklos Szeredi + +commit 84588a93d097bace24b9233930f82511d4f34210 upstream. + +Signed-off-by: Miklos Szeredi +Fixes: d82718e348fe ("fuse_dev_splice_read(): switch to add_to_pipe()") +Signed-off-by: Greg Kroah-Hartman + +--- + fs/fuse/dev.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/fs/fuse/dev.c ++++ b/fs/fuse/dev.c +@@ -1376,6 +1376,7 @@ static ssize_t fuse_dev_splice_read(stru + * code can Oops if the buffer persists after module unload. + */ + bufs[page_nr].ops = &nosteal_pipe_buf_ops; ++ bufs[page_nr].flags = 0; + ret = add_to_pipe(pipe, &bufs[page_nr++]); + if (unlikely(ret < 0)) + break; diff --git a/queue-4.9/fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch b/queue-4.9/fuse-fix-use-after-free-issue-in-fuse_dev_do_read.patch new file mode 100644 index 00000000000..0f486b299bf --- /dev/null +++ b/queue-4.9/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 +@@ -399,6 +399,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.9/futex-move-futex_init-to-core_initcall.patch b/queue-4.9/futex-move-futex_init-to-core_initcall.patch new file mode 100644 index 00000000000..af9f5a6c077 --- /dev/null +++ b/queue-4.9/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 +@@ -3323,4 +3323,4 @@ static int __init futex_init(void) + + return 0; + } +-__initcall(futex_init); ++core_initcall(futex_init); diff --git a/queue-4.9/input-elan_i2c-add-elan0605-to-the-acpi-table.patch b/queue-4.9/input-elan_i2c-add-elan0605-to-the-acpi-table.patch new file mode 100644 index 00000000000..d684fcf15d8 --- /dev/null +++ b/queue-4.9/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.9/mmc-core-fix-multi-bit-bus-width-without-high-speed-mode.patch b/queue-4.9/mmc-core-fix-multi-bit-bus-width-without-high-speed-mode.patch new file mode 100644 index 00000000000..269298ebcf4 --- /dev/null +++ b/queue-4.9/mmc-core-fix-multi-bit-bus-width-without-high-speed-mode.patch @@ -0,0 +1,50 @@ +From 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 Mon Sep 17 00:00:00 2001 +From: Anssi Hannula +Date: Mon, 13 Feb 2017 13:46:41 +0200 +Subject: mmc: core: fix multi-bit bus width without high-speed mode + +From: Anssi Hannula + +commit 3d4ef329757cfd5e0b23cce97cdeca7e2df89c99 upstream. + +Commit 577fb13199b1 ("mmc: rework selection of bus speed mode") +refactored bus width selection code to mmc_select_bus_width(). + +However, it also altered the behavior to not call the selection code in +non-high-speed modes anymore. + +This causes 1-bit mode to always be used when the high-speed mode is not +enabled, even though 4-bit and 8-bit bus are valid bus widths in the +backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed +Modes in JEDEC 84-B50). This results in a significant regression in +transfer speeds. + +Fix the code to allow 4-bit and 8-bit widths even without high-speed +mode, as before. + +Tested with a Zynq-7000 PicoZed 7020 board. + +Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode") +Signed-off-by: Anssi Hannula +Signed-off-by: Ulf Hansson +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mmc/core/mmc.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/mmc/core/mmc.c ++++ b/drivers/mmc/core/mmc.c +@@ -1690,10 +1690,10 @@ static int mmc_init_card(struct mmc_host + err = mmc_select_hs400(card); + if (err) + goto free_card; +- } else if (mmc_card_hs(card)) { ++ } else { + /* Select the desired bus width optionally */ + err = mmc_select_bus_width(card); +- if (err > 0) { ++ if (err > 0 && mmc_card_hs(card)) { + err = mmc_select_hs_ddr(card); + if (err) + goto free_card; diff --git a/queue-4.9/pci-pme-restore-pcie_pme_driver.remove.patch b/queue-4.9/pci-pme-restore-pcie_pme_driver.remove.patch new file mode 100644 index 00000000000..6b3bb19f14d --- /dev/null +++ b/queue-4.9/pci-pme-restore-pcie_pme_driver.remove.patch @@ -0,0 +1,93 @@ +From afe3e4d11bdf50a4c3965eb6465ba6bebbcf5dcf Mon Sep 17 00:00:00 2001 +From: Yinghai Lu +Date: Tue, 14 Feb 2017 21:17:48 -0800 +Subject: PCI/PME: Restore pcie_pme_driver.remove + +From: Yinghai Lu + +commit afe3e4d11bdf50a4c3965eb6465ba6bebbcf5dcf upstream. + +In addition to making PME non-modular, d7def2040077 ("PCI/PME: Make +explicitly non-modular") removed the pcie_pme_driver .remove() method, +pcie_pme_remove(). + +pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe(). +The fact that we don't free the IRQ after d7def2040077 causes the following +crash when removing a PCIe port device via /sys: + + ------------[ cut here ]------------ + kernel BUG at drivers/pci/msi.c:370! + invalid opcode: 0000 [#1] SMP + Modules linked in: + CPU: 1 PID: 14509 Comm: sh Tainted: G W 4.8.0-rc1-yh-00012-gd29438d + RIP: 0010:[] free_msi_irqs+0x65/0x190 + ... + Call Trace: + [] pci_disable_msi+0x34/0x40 + [] cleanup_service_irqs+0x27/0x30 + [] pcie_port_device_remove+0x2a/0x40 + [] pcie_portdrv_remove+0x40/0x50 + [] pci_device_remove+0x4b/0xc0 + [] __device_release_driver+0xb6/0x150 + [] device_release_driver+0x25/0x40 + [] pci_stop_bus_device+0x74/0xa0 + [] pci_stop_and_remove_bus_device_locked+0x1a/0x30 + [] remove_store+0x50/0x70 + [] dev_attr_store+0x18/0x30 + [] sysfs_kf_write+0x44/0x60 + [] kernfs_fop_write+0x10e/0x190 + [] __vfs_write+0x28/0x110 + [] ? percpu_down_read+0x44/0x80 + [] ? __sb_start_write+0xa7/0xe0 + [] ? __sb_start_write+0xa7/0xe0 + [] vfs_write+0xc4/0x180 + [] SyS_write+0x49/0xa0 + [] do_syscall_64+0xa6/0x1b0 + [] entry_SYSCALL64_slow_path+0x25/0x25 + ... + RIP [] free_msi_irqs+0x65/0x190 + RSP + ---[ end trace f4505e1dac5b95d3 ]--- + Segmentation fault + +Restore pcie_pme_remove(). + +[bhelgaas: changelog] +Fixes: d7def2040077 ("PCI/PME: Make explicitly non-modular") +Signed-off-by: Yinghai Lu +Signed-off-by: Bjorn Helgaas +Acked-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/pcie/pme.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/drivers/pci/pcie/pme.c ++++ b/drivers/pci/pcie/pme.c +@@ -448,6 +448,17 @@ static int pcie_pme_resume(struct pcie_d + return 0; + } + ++/** ++ * pcie_pme_remove - Prepare PCIe PME service device for removal. ++ * @srv - PCIe service device to remove. ++ */ ++static void pcie_pme_remove(struct pcie_device *srv) ++{ ++ pcie_pme_suspend(srv); ++ free_irq(srv->irq, srv); ++ kfree(get_service_data(srv)); ++} ++ + static struct pcie_port_service_driver pcie_pme_driver = { + .name = "pcie_pme", + .port_type = PCI_EXP_TYPE_ROOT_PORT, +@@ -456,6 +467,7 @@ static struct pcie_port_service_driver p + .probe = pcie_pme_probe, + .suspend = pcie_pme_suspend, + .resume = pcie_pme_resume, ++ .remove = pcie_pme_remove, + }; + + /** diff --git a/queue-4.9/powerpc-64-disable-use-of-radix-under-a-hypervisor.patch b/queue-4.9/powerpc-64-disable-use-of-radix-under-a-hypervisor.patch new file mode 100644 index 00000000000..8b25b3cfb5e --- /dev/null +++ b/queue-4.9/powerpc-64-disable-use-of-radix-under-a-hypervisor.patch @@ -0,0 +1,44 @@ +From 3f91a89d424a79f8082525db5a375e438887bb3e Mon Sep 17 00:00:00 2001 +From: Paul Mackerras +Date: Thu, 16 Feb 2017 13:49:21 +1100 +Subject: powerpc/64: Disable use of radix under a hypervisor + +From: Paul Mackerras + +commit 3f91a89d424a79f8082525db5a375e438887bb3e upstream. + +Currently, if the kernel is running on a POWER9 processor under a +hypervisor, it may try to use the radix MMU even though it doesn't have +the necessary code to do so (it doesn't negotiate use of radix, and it +doesn't do the H_REGISTER_PROC_TBL hcall). If the hypervisor supports +both radix and HPT, then it will set up the guest to use HPT (since the +guest doesn't request radix in the CAS call), but if the radix feature +bit is set in the ibm,pa-features property (which is valid, since +ibm,pa-features is defined to represent the capabilities of the +processor) the guest will try to use radix, resulting in a crash when +it turns the MMU on. + +This makes the minimal fix for the current code, which is to disable +radix unless we are running in hypervisor mode. + +Fixes: 2bfd65e45e87 ("powerpc/mm/radix: Add radix callbacks for early init routines") +Signed-off-by: Paul Mackerras +Signed-off-by: Michael Ellerman +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/mm/init_64.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/mm/init_64.c ++++ b/arch/powerpc/mm/init_64.c +@@ -424,7 +424,8 @@ early_param("disable_radix", parse_disab + void __init mmu_early_init_devtree(void) + { + /* Disable radix mode based on kernel command line. */ +- if (disable_radix) ++ /* We don't yet have the machinery to do radix as a guest. */ ++ if (disable_radix || !(mfmsr() & MSR_HV)) + cur_cpu_spec->mmu_features &= ~MMU_FTR_TYPE_RADIX; + + if (early_radix_enabled()) diff --git a/queue-4.9/printk-use-rcuidle-console-tracepoint.patch b/queue-4.9/printk-use-rcuidle-console-tracepoint.patch new file mode 100644 index 00000000000..744583a19e0 --- /dev/null +++ b/queue-4.9/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 +@@ -1564,7 +1564,7 @@ static void call_console_drivers(int lev + { + struct console *con; + +- trace_console(text, len); ++ trace_console_rcuidle(text, len); + + if (!console_drivers) + return; diff --git a/queue-4.9/revert-i2c-designware-detect-when-dynamic-tar-update-is-possible.patch b/queue-4.9/revert-i2c-designware-detect-when-dynamic-tar-update-is-possible.patch new file mode 100644 index 00000000000..d8155a952c9 --- /dev/null +++ b/queue-4.9/revert-i2c-designware-detect-when-dynamic-tar-update-is-possible.patch @@ -0,0 +1,122 @@ +From 12688dc21f71f4dcc9e2b8b5556b0c6cc8df1491 Mon Sep 17 00:00:00 2001 +From: Jarkko Nikula +Date: Mon, 13 Feb 2017 11:18:19 +0200 +Subject: Revert "i2c: designware: detect when dynamic tar update is possible" + +From: Jarkko Nikula + +commit 12688dc21f71f4dcc9e2b8b5556b0c6cc8df1491 upstream. + +This reverts commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3. + +It caused a regression on platforms where I2C controller is synthesized +with dynamic TAR update disabled. Detection code is testing is bit +DW_IC_CON_10BITADDR_MASTER in register DW_IC_CON read-only but fails to +restore original value in case bit is read-write. + +Instead of fixing this we revert the commit since it was preparation for +the commit 0317e6c0f1dc ("i2c: designware: do not disable adapter after +transfer") which was also reverted. + +Reported-by: Shah Nehal-Bakulchandra +Reported-by: Suravee Suthikulpanit +Acked-By: Lucas De Marchi +Fixes: 63d0f0a6952a ("i2c: designware: detect when dynamic tar update is possible") +Signed-off-by: Jarkko Nikula +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-designware-core.c | 45 +++++++------------------------ + drivers/i2c/busses/i2c-designware-core.h | 1 + 2 files changed, 11 insertions(+), 35 deletions(-) + +--- a/drivers/i2c/busses/i2c-designware-core.c ++++ b/drivers/i2c/busses/i2c-designware-core.c +@@ -475,30 +475,28 @@ static int i2c_dw_wait_bus_not_busy(stru + static void i2c_dw_xfer_init(struct dw_i2c_dev *dev) + { + struct i2c_msg *msgs = dev->msgs; +- u32 ic_tar = 0; ++ u32 ic_con, ic_tar = 0; + + /* Disable the adapter */ + __i2c_dw_enable_and_wait(dev, false); + + /* if the slave address is ten bit address, enable 10BITADDR */ +- if (dev->dynamic_tar_update_enabled) { ++ ic_con = dw_readl(dev, DW_IC_CON); ++ if (msgs[dev->msg_write_idx].flags & I2C_M_TEN) { ++ ic_con |= DW_IC_CON_10BITADDR_MASTER; + /* + * If I2C_DYNAMIC_TAR_UPDATE is set, the 10-bit addressing +- * mode has to be enabled via bit 12 of IC_TAR register, +- * otherwise bit 4 of IC_CON is used. ++ * mode has to be enabled via bit 12 of IC_TAR register. ++ * We set it always as I2C_DYNAMIC_TAR_UPDATE can't be ++ * detected from registers. + */ +- if (msgs[dev->msg_write_idx].flags & I2C_M_TEN) +- ic_tar = DW_IC_TAR_10BITADDR_MASTER; ++ ic_tar = DW_IC_TAR_10BITADDR_MASTER; + } else { +- u32 ic_con = dw_readl(dev, DW_IC_CON); +- +- if (msgs[dev->msg_write_idx].flags & I2C_M_TEN) +- ic_con |= DW_IC_CON_10BITADDR_MASTER; +- else +- ic_con &= ~DW_IC_CON_10BITADDR_MASTER; +- dw_writel(dev, ic_con, DW_IC_CON); ++ ic_con &= ~DW_IC_CON_10BITADDR_MASTER; + } + ++ dw_writel(dev, ic_con, DW_IC_CON); ++ + /* + * Set the slave (target) address and enable 10-bit addressing mode + * if applicable. +@@ -923,7 +921,6 @@ int i2c_dw_probe(struct dw_i2c_dev *dev) + { + struct i2c_adapter *adap = &dev->adapter; + int r; +- u32 reg; + + init_completion(&dev->cmd_complete); + +@@ -931,26 +928,6 @@ int i2c_dw_probe(struct dw_i2c_dev *dev) + if (r) + return r; + +- r = i2c_dw_acquire_lock(dev); +- if (r) +- return r; +- +- /* +- * Test if dynamic TAR update is enabled in this controller by writing +- * to IC_10BITADDR_MASTER field in IC_CON: when it is enabled this +- * field is read-only so it should not succeed +- */ +- reg = dw_readl(dev, DW_IC_CON); +- dw_writel(dev, reg ^ DW_IC_CON_10BITADDR_MASTER, DW_IC_CON); +- +- if ((dw_readl(dev, DW_IC_CON) & DW_IC_CON_10BITADDR_MASTER) == +- (reg & DW_IC_CON_10BITADDR_MASTER)) { +- dev->dynamic_tar_update_enabled = true; +- dev_dbg(dev->dev, "Dynamic TAR update enabled"); +- } +- +- i2c_dw_release_lock(dev); +- + snprintf(adap->name, sizeof(adap->name), + "Synopsys DesignWare I2C adapter"); + adap->retries = 3; +--- a/drivers/i2c/busses/i2c-designware-core.h ++++ b/drivers/i2c/busses/i2c-designware-core.h +@@ -117,7 +117,6 @@ struct dw_i2c_dev { + int (*acquire_lock)(struct dw_i2c_dev *dev); + void (*release_lock)(struct dw_i2c_dev *dev); + bool pm_runtime_disabled; +- bool dynamic_tar_update_enabled; + }; + + #define ACCESS_SWAP 0x00000001 diff --git a/queue-4.9/scsi-don-t-bug_on-empty-dma-transfers.patch b/queue-4.9/scsi-don-t-bug_on-empty-dma-transfers.patch new file mode 100644 index 00000000000..bbf9ec9ae17 --- /dev/null +++ b/queue-4.9/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 +@@ -1031,7 +1031,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.9/series b/queue-4.9/series new file mode 100644 index 00000000000..d53ca27b995 --- /dev/null +++ b/queue-4.9/series @@ -0,0 +1,17 @@ +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 +fuse-fix-uninitialized-flags-in-pipe_buffer.patch +mmc-core-fix-multi-bit-bus-width-without-high-speed-mode.patch +powerpc-64-disable-use-of-radix-under-a-hypervisor.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 +revert-i2c-designware-detect-when-dynamic-tar-update-is-possible.patch +pci-pme-restore-pcie_pme_driver.remove.patch +printk-use-rcuidle-console-tracepoint.patch +timekeeping-use-deferred-printk-in-debug-code.patch diff --git a/queue-4.9/siano-make-it-work-again-with-config_vmap_stack.patch b/queue-4.9/siano-make-it-work-again-with-config_vmap_stack.patch new file mode 100644 index 00000000000..a5994cc0f71 --- /dev/null +++ b/queue-4.9/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 +@@ -218,22 +218,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.9/timekeeping-use-deferred-printk-in-debug-code.patch b/queue-4.9/timekeeping-use-deferred-printk-in-debug-code.patch new file mode 100644 index 00000000000..86fa59b8892 --- /dev/null +++ b/queue-4.9/timekeeping-use-deferred-printk-in-debug-code.patch @@ -0,0 +1,196 @@ +From f222449c9dfad7c9bb8cb53e64c5c407b172ebbc Mon Sep 17 00:00:00 2001 +From: Sergey Senozhatsky +Date: Wed, 15 Feb 2017 13:43:32 +0900 +Subject: timekeeping: Use deferred printk() in debug code + +From: Sergey Senozhatsky + +commit f222449c9dfad7c9bb8cb53e64c5c407b172ebbc upstream. + +We cannot do printk() from tk_debug_account_sleep_time(), because +tk_debug_account_sleep_time() is called under tk_core seq lock. +The reason why printk() is unsafe there is that console_sem may +invoke scheduler (up()->wake_up_process()->activate_task()), which, +in turn, can return back to timekeeping code, for instance, via +get_time()->ktime_get(), deadlocking the system on tk_core seq lock. + +[ 48.950592] ====================================================== +[ 48.950622] [ INFO: possible circular locking dependency detected ] +[ 48.950622] 4.10.0-rc7-next-20170213+ #101 Not tainted +[ 48.950622] ------------------------------------------------------- +[ 48.950622] kworker/0:0/3 is trying to acquire lock: +[ 48.950653] (tk_core){----..}, at: [] retrigger_next_event+0x4c/0x90 +[ 48.950683] + but task is already holding lock: +[ 48.950683] (hrtimer_bases.lock){-.-...}, at: [] retrigger_next_event+0x38/0x90 +[ 48.950714] + which lock already depends on the new lock. + +[ 48.950714] + the existing dependency chain (in reverse order) is: +[ 48.950714] + -> #5 (hrtimer_bases.lock){-.-...}: +[ 48.950744] _raw_spin_lock_irqsave+0x50/0x64 +[ 48.950775] lock_hrtimer_base+0x28/0x58 +[ 48.950775] hrtimer_start_range_ns+0x20/0x5c8 +[ 48.950775] __enqueue_rt_entity+0x320/0x360 +[ 48.950805] enqueue_rt_entity+0x2c/0x44 +[ 48.950805] enqueue_task_rt+0x24/0x94 +[ 48.950836] ttwu_do_activate+0x54/0xc0 +[ 48.950836] try_to_wake_up+0x248/0x5c8 +[ 48.950836] __setup_irq+0x420/0x5f0 +[ 48.950836] request_threaded_irq+0xdc/0x184 +[ 48.950866] devm_request_threaded_irq+0x58/0xa4 +[ 48.950866] omap_i2c_probe+0x530/0x6a0 +[ 48.950897] platform_drv_probe+0x50/0xb0 +[ 48.950897] driver_probe_device+0x1f8/0x2cc +[ 48.950897] __driver_attach+0xc0/0xc4 +[ 48.950927] bus_for_each_dev+0x6c/0xa0 +[ 48.950927] bus_add_driver+0x100/0x210 +[ 48.950927] driver_register+0x78/0xf4 +[ 48.950958] do_one_initcall+0x3c/0x16c +[ 48.950958] kernel_init_freeable+0x20c/0x2d8 +[ 48.950958] kernel_init+0x8/0x110 +[ 48.950988] ret_from_fork+0x14/0x24 +[ 48.950988] + -> #4 (&rt_b->rt_runtime_lock){-.-...}: +[ 48.951019] _raw_spin_lock+0x40/0x50 +[ 48.951019] rq_offline_rt+0x9c/0x2bc +[ 48.951019] set_rq_offline.part.2+0x2c/0x58 +[ 48.951049] rq_attach_root+0x134/0x144 +[ 48.951049] cpu_attach_domain+0x18c/0x6f4 +[ 48.951049] build_sched_domains+0xba4/0xd80 +[ 48.951080] sched_init_smp+0x68/0x10c +[ 48.951080] kernel_init_freeable+0x160/0x2d8 +[ 48.951080] kernel_init+0x8/0x110 +[ 48.951080] ret_from_fork+0x14/0x24 +[ 48.951110] + -> #3 (&rq->lock){-.-.-.}: +[ 48.951110] _raw_spin_lock+0x40/0x50 +[ 48.951141] task_fork_fair+0x30/0x124 +[ 48.951141] sched_fork+0x194/0x2e0 +[ 48.951141] copy_process.part.5+0x448/0x1a20 +[ 48.951171] _do_fork+0x98/0x7e8 +[ 48.951171] kernel_thread+0x2c/0x34 +[ 48.951171] rest_init+0x1c/0x18c +[ 48.951202] start_kernel+0x35c/0x3d4 +[ 48.951202] 0x8000807c +[ 48.951202] + -> #2 (&p->pi_lock){-.-.-.}: +[ 48.951232] _raw_spin_lock_irqsave+0x50/0x64 +[ 48.951232] try_to_wake_up+0x30/0x5c8 +[ 48.951232] up+0x4c/0x60 +[ 48.951263] __up_console_sem+0x2c/0x58 +[ 48.951263] console_unlock+0x3b4/0x650 +[ 48.951263] vprintk_emit+0x270/0x474 +[ 48.951293] vprintk_default+0x20/0x28 +[ 48.951293] printk+0x20/0x30 +[ 48.951324] kauditd_hold_skb+0x94/0xb8 +[ 48.951324] kauditd_thread+0x1a4/0x56c +[ 48.951324] kthread+0x104/0x148 +[ 48.951354] ret_from_fork+0x14/0x24 +[ 48.951354] + -> #1 ((console_sem).lock){-.....}: +[ 48.951385] _raw_spin_lock_irqsave+0x50/0x64 +[ 48.951385] down_trylock+0xc/0x2c +[ 48.951385] __down_trylock_console_sem+0x24/0x80 +[ 48.951385] console_trylock+0x10/0x8c +[ 48.951416] vprintk_emit+0x264/0x474 +[ 48.951416] vprintk_default+0x20/0x28 +[ 48.951416] printk+0x20/0x30 +[ 48.951446] tk_debug_account_sleep_time+0x5c/0x70 +[ 48.951446] __timekeeping_inject_sleeptime.constprop.3+0x170/0x1a0 +[ 48.951446] timekeeping_resume+0x218/0x23c +[ 48.951477] syscore_resume+0x94/0x42c +[ 48.951477] suspend_enter+0x554/0x9b4 +[ 48.951477] suspend_devices_and_enter+0xd8/0x4b4 +[ 48.951507] enter_state+0x934/0xbd4 +[ 48.951507] pm_suspend+0x14/0x70 +[ 48.951507] state_store+0x68/0xc8 +[ 48.951538] kernfs_fop_write+0xf4/0x1f8 +[ 48.951538] __vfs_write+0x1c/0x114 +[ 48.951538] vfs_write+0xa0/0x168 +[ 48.951568] SyS_write+0x3c/0x90 +[ 48.951568] __sys_trace_return+0x0/0x10 +[ 48.951568] + -> #0 (tk_core){----..}: +[ 48.951599] lock_acquire+0xe0/0x294 +[ 48.951599] ktime_get_update_offsets_now+0x5c/0x1d4 +[ 48.951629] retrigger_next_event+0x4c/0x90 +[ 48.951629] on_each_cpu+0x40/0x7c +[ 48.951629] clock_was_set_work+0x14/0x20 +[ 48.951660] process_one_work+0x2b4/0x808 +[ 48.951660] worker_thread+0x3c/0x550 +[ 48.951660] kthread+0x104/0x148 +[ 48.951690] ret_from_fork+0x14/0x24 +[ 48.951690] + other info that might help us debug this: + +[ 48.951690] Chain exists of: + tk_core --> &rt_b->rt_runtime_lock --> hrtimer_bases.lock + +[ 48.951721] Possible unsafe locking scenario: + +[ 48.951721] CPU0 CPU1 +[ 48.951721] ---- ---- +[ 48.951721] lock(hrtimer_bases.lock); +[ 48.951751] lock(&rt_b->rt_runtime_lock); +[ 48.951751] lock(hrtimer_bases.lock); +[ 48.951751] lock(tk_core); +[ 48.951782] + *** DEADLOCK *** + +[ 48.951782] 3 locks held by kworker/0:0/3: +[ 48.951782] #0: ("events"){.+.+.+}, at: [] process_one_work+0x1f8/0x808 +[ 48.951812] #1: (hrtimer_work){+.+...}, at: [] process_one_work+0x1f8/0x808 +[ 48.951843] #2: (hrtimer_bases.lock){-.-...}, at: [] retrigger_next_event+0x38/0x90 +[ 48.951843] stack backtrace: +[ 48.951873] CPU: 0 PID: 3 Comm: kworker/0:0 Not tainted 4.10.0-rc7-next-20170213+ +[ 48.951904] Workqueue: events clock_was_set_work +[ 48.951904] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) +[ 48.951934] [] (show_stack) from [] (dump_stack+0xac/0xe0) +[ 48.951934] [] (dump_stack) from [] (print_circular_bug+0x1d0/0x308) +[ 48.951965] [] (print_circular_bug) from [] (validate_chain+0xf50/0x1324) +[ 48.951965] [] (validate_chain) from [] (__lock_acquire+0x468/0x7e8) +[ 48.951995] [] (__lock_acquire) from [] (lock_acquire+0xe0/0x294) +[ 48.951995] [] (lock_acquire) from [] (ktime_get_update_offsets_now+0x5c/0x1d4) +[ 48.952026] [] (ktime_get_update_offsets_now) from [] (retrigger_next_event+0x4c/0x90) +[ 48.952026] [] (retrigger_next_event) from [] (on_each_cpu+0x40/0x7c) +[ 48.952056] [] (on_each_cpu) from [] (clock_was_set_work+0x14/0x20) +[ 48.952056] [] (clock_was_set_work) from [] (process_one_work+0x2b4/0x808) +[ 48.952087] [] (process_one_work) from [] (worker_thread+0x3c/0x550) +[ 48.952087] [] (worker_thread) from [] (kthread+0x104/0x148) +[ 48.952087] [] (kthread) from [] (ret_from_fork+0x14/0x24) + +Replace printk() with printk_deferred(), which does not call into +the scheduler. + +Fixes: 0bf43f15db85 ("timekeeping: Prints the amounts of time spent during suspend") +Reported-and-tested-by: Tony Lindgren +Signed-off-by: Sergey Senozhatsky +Cc: Petr Mladek +Cc: Sergey Senozhatsky +Cc: Peter Zijlstra +Cc: "Rafael J . Wysocki" +Cc: Steven Rostedt +Cc: John Stultz +Link: http://lkml.kernel.org/r/20170215044332.30449-1-sergey.senozhatsky@gmail.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/time/timekeeping_debug.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/time/timekeeping_debug.c ++++ b/kernel/time/timekeeping_debug.c +@@ -75,7 +75,7 @@ void tk_debug_account_sleep_time(struct + int bin = min(fls(t->tv_sec), NUM_BINS-1); + + sleep_time_bin[bin]++; +- pr_info("Suspended for %lld.%03lu seconds\n", (s64)t->tv_sec, +- t->tv_nsec / NSEC_PER_MSEC); ++ printk_deferred(KERN_INFO "Suspended for %lld.%03lu seconds\n", ++ (s64)t->tv_sec, t->tv_nsec / NSEC_PER_MSEC); + } + diff --git a/queue-4.9/vfs-fix-uninitialized-flags-in-splice_to_pipe.patch b/queue-4.9/vfs-fix-uninitialized-flags-in-splice_to_pipe.patch new file mode 100644 index 00000000000..b34dcd55365 --- /dev/null +++ b/queue-4.9/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 +@@ -203,6 +203,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; + + pipe->nrbufs++; + page_nr++;