From: Greg Kroah-Hartman Date: Tue, 23 Jul 2019 12:11:12 +0000 (+0200) Subject: 4.4-stable patches X-Git-Tag: v5.2.3~31 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=538df282b327c76315e2f68930d81a0349556531;p=thirdparty%2Fkernel%2Fstable-queue.git 4.4-stable patches added patches: 9p-virtio-add-cleanup-path-in-p9_virtio_init.patch btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch --- diff --git a/queue-4.4/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch b/queue-4.4/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch new file mode 100644 index 00000000000..32207fada0b --- /dev/null +++ b/queue-4.4/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch @@ -0,0 +1,89 @@ +From d4548543fc4ece56c6f04b8586f435fb4fd84c20 Mon Sep 17 00:00:00 2001 +From: YueHaibing +Date: Tue, 30 Apr 2019 19:59:42 +0800 +Subject: 9p/virtio: Add cleanup path in p9_virtio_init + +From: YueHaibing + +commit d4548543fc4ece56c6f04b8586f435fb4fd84c20 upstream. + +KASAN report this: + +BUG: unable to handle kernel paging request at ffffffffa0097000 +PGD 3870067 P4D 3870067 PUD 3871063 PMD 2326e2067 PTE 0 +Oops: 0000 [#1 +CPU: 0 PID: 5340 Comm: modprobe Not tainted 5.1.0-rc7+ #25 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 +RIP: 0010:__list_add_valid+0x10/0x70 +Code: c3 48 8b 06 55 48 89 e5 5d 48 39 07 0f 94 c0 0f b6 c0 c3 90 90 90 90 90 90 90 55 48 89 d0 48 8b 52 08 48 89 e5 48 39 f2 75 19 <48> 8b 32 48 39 f0 75 3a + +RSP: 0018:ffffc90000e23c68 EFLAGS: 00010246 +RAX: ffffffffa00ad000 RBX: ffffffffa009d000 RCX: 0000000000000000 +RDX: ffffffffa0097000 RSI: ffffffffa0097000 RDI: ffffffffa009d000 +RBP: ffffc90000e23c68 R08: 0000000000000001 R09: 0000000000000000 +R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0097000 +R13: ffff888231797180 R14: 0000000000000000 R15: ffffc90000e23e78 +FS: 00007fb215285540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: ffffffffa0097000 CR3: 000000022f144000 CR4: 00000000000006f0 +Call Trace: + v9fs_register_trans+0x2f/0x60 [9pnet + ? 0xffffffffa0087000 + p9_virtio_init+0x25/0x1000 [9pnet_virtio + do_one_initcall+0x6c/0x3cc + ? kmem_cache_alloc_trace+0x248/0x3b0 + do_init_module+0x5b/0x1f1 + load_module+0x1db1/0x2690 + ? m_show+0x1d0/0x1d0 + __do_sys_finit_module+0xc5/0xd0 + __x64_sys_finit_module+0x15/0x20 + do_syscall_64+0x6b/0x1d0 + entry_SYSCALL_64_after_hwframe+0x49/0xbe +RIP: 0033:0x7fb214d8e839 +Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 + +RSP: 002b:00007ffc96554278 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 +RAX: ffffffffffffffda RBX: 000055e67eed2aa0 RCX: 00007fb214d8e839 +RDX: 0000000000000000 RSI: 000055e67ce95c2e RDI: 0000000000000003 +RBP: 000055e67ce95c2e R08: 0000000000000000 R09: 000055e67eed2aa0 +R10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000000 +R13: 000055e67eeda500 R14: 0000000000040000 R15: 000055e67eed2aa0 +Modules linked in: 9pnet_virtio(+) 9pnet gre rfkill vmw_vsock_virtio_transport_common vsock [last unloaded: 9pnet_virtio +CR2: ffffffffa0097000 +---[ end trace 4a52bb13ff07b761 + +If register_virtio_driver() fails in p9_virtio_init, +we should call v9fs_unregister_trans() to do cleanup. + +Link: http://lkml.kernel.org/r/20190430115942.41840-1-yuehaibing@huawei.com +Cc: stable@vger.kernel.org +Reported-by: Hulk Robot +Fixes: b530cc794024 ("9p: add virtio transport") +Signed-off-by: YueHaibing +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman + +--- + net/9p/trans_virtio.c | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/net/9p/trans_virtio.c ++++ b/net/9p/trans_virtio.c +@@ -767,10 +767,16 @@ static struct p9_trans_module p9_virtio_ + /* The standard init function */ + static int __init p9_virtio_init(void) + { ++ int rc; ++ + INIT_LIST_HEAD(&virtio_chan_list); + + v9fs_register_trans(&p9_virtio_trans); +- return register_virtio_driver(&p9_virtio_drv); ++ rc = register_virtio_driver(&p9_virtio_drv); ++ if (rc) ++ v9fs_unregister_trans(&p9_virtio_trans); ++ ++ return rc; + } + + static void __exit p9_virtio_cleanup(void) diff --git a/queue-4.4/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch b/queue-4.4/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch new file mode 100644 index 00000000000..8b92a29414a --- /dev/null +++ b/queue-4.4/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch @@ -0,0 +1,42 @@ +From 179006688a7e888cbff39577189f2e034786d06a Mon Sep 17 00:00:00 2001 +From: Filipe Manana +Date: Wed, 19 Jun 2019 13:05:50 +0100 +Subject: Btrfs: add missing inode version, ctime and mtime updates when punching hole + +From: Filipe Manana + +commit 179006688a7e888cbff39577189f2e034786d06a upstream. + +If the range for which we are punching a hole covers only part of a page, +we end up updating the inode item but we skip the update of the inode's +iversion, mtime and ctime. Fix that by ensuring we update those properties +of the inode. + +A patch for fstests test case generic/059 that tests this as been sent +along with this fix. + +Fixes: 2aaa66558172b0 ("Btrfs: add hole punching") +Fixes: e8c1c76e804b18 ("Btrfs: add missing inode update when punching hole") +CC: stable@vger.kernel.org # 4.4+ +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman + +--- + fs/btrfs/file.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/fs/btrfs/file.c ++++ b/fs/btrfs/file.c +@@ -2586,6 +2586,11 @@ out_only_mutex: + * for detecting, at fsync time, if the inode isn't yet in the + * log tree or it's there but not up to date. + */ ++ struct timespec64 now = current_time(inode); ++ ++ inode_inc_iversion(inode); ++ inode->i_mtime = now; ++ inode->i_ctime = now; + trans = btrfs_start_transaction(root, 1); + if (IS_ERR(trans)) { + err = PTR_ERR(trans); diff --git a/queue-4.4/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch b/queue-4.4/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch new file mode 100644 index 00000000000..4539b61dd0c --- /dev/null +++ b/queue-4.4/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch @@ -0,0 +1,78 @@ +From 7cb95eeea6706c790571042a06782e378b2561ea Mon Sep 17 00:00:00 2001 +From: Lyude Paul +Date: Wed, 26 Jun 2019 14:10:27 -0400 +Subject: drm/nouveau/i2c: Enable i2c pads & busses during preinit + +From: Lyude Paul + +commit 7cb95eeea6706c790571042a06782e378b2561ea upstream. + +It turns out that while disabling i2c bus access from software when the +GPU is suspended was a step in the right direction with: + +commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after +->fini()") + +We also ended up accidentally breaking the vbios init scripts on some +older Tesla GPUs, as apparently said scripts can actually use the i2c +bus. Since these scripts are executed before initializing any +subdevices, we end up failing to acquire access to the i2c bus which has +left a number of cards with their fan controllers uninitialized. Luckily +this doesn't break hardware - it just means the fan gets stuck at 100%. + +This also means that we've always been using our i2c busses before +initializing them during the init scripts for older GPUs, we just didn't +notice it until we started preventing them from being used until init. +It's pretty impressive this never caused us any issues before! + +So, fix this by initializing our i2c pad and busses during subdev +pre-init. We skip initializing aux busses during pre-init, as those are +guaranteed to only ever be used by nouveau for DP aux transactions. + +Signed-off-by: Lyude Paul +Tested-by: Marc Meledandri +Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()") +Cc: stable@vger.kernel.org +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c ++++ b/drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c +@@ -185,6 +185,25 @@ nvkm_i2c_fini(struct nvkm_subdev *subdev + } + + static int ++nvkm_i2c_preinit(struct nvkm_subdev *subdev) ++{ ++ struct nvkm_i2c *i2c = nvkm_i2c(subdev); ++ struct nvkm_i2c_bus *bus; ++ struct nvkm_i2c_pad *pad; ++ ++ /* ++ * We init our i2c busses as early as possible, since they may be ++ * needed by the vbios init scripts on some cards ++ */ ++ list_for_each_entry(pad, &i2c->pad, head) ++ nvkm_i2c_pad_init(pad); ++ list_for_each_entry(bus, &i2c->bus, head) ++ nvkm_i2c_bus_init(bus); ++ ++ return 0; ++} ++ ++static int + nvkm_i2c_init(struct nvkm_subdev *subdev) + { + struct nvkm_i2c *i2c = nvkm_i2c(subdev); +@@ -238,6 +257,7 @@ nvkm_i2c_dtor(struct nvkm_subdev *subdev + static const struct nvkm_subdev_func + nvkm_i2c = { + .dtor = nvkm_i2c_dtor, ++ .preinit = nvkm_i2c_preinit, + .init = nvkm_i2c_init, + .fini = nvkm_i2c_fini, + .intr = nvkm_i2c_intr, diff --git a/queue-4.4/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch b/queue-4.4/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch new file mode 100644 index 00000000000..f05d6f01888 --- /dev/null +++ b/queue-4.4/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch @@ -0,0 +1,117 @@ +From cf144f81a99d1a3928f90b0936accfd3f45c9a0a Mon Sep 17 00:00:00 2001 +From: Daniel Jordan +Date: Tue, 16 Jul 2019 12:32:53 -0400 +Subject: padata: use smp_mb in padata_reorder to avoid orphaned padata jobs + +From: Daniel Jordan + +commit cf144f81a99d1a3928f90b0936accfd3f45c9a0a upstream. + +Testing padata with the tcrypt module on a 5.2 kernel... + + # modprobe tcrypt alg="pcrypt(rfc4106(gcm(aes)))" type=3 + # modprobe tcrypt mode=211 sec=1 + +...produces this splat: + + INFO: task modprobe:10075 blocked for more than 120 seconds. + Not tainted 5.2.0-base+ #16 + modprobe D 0 10075 10064 0x80004080 + Call Trace: + ? __schedule+0x4dd/0x610 + ? ring_buffer_unlock_commit+0x23/0x100 + schedule+0x6c/0x90 + schedule_timeout+0x3b/0x320 + ? trace_buffer_unlock_commit_regs+0x4f/0x1f0 + wait_for_common+0x160/0x1a0 + ? wake_up_q+0x80/0x80 + { crypto_wait_req } # entries in braces added by hand + { do_one_aead_op } + { test_aead_jiffies } + test_aead_speed.constprop.17+0x681/0xf30 [tcrypt] + do_test+0x4053/0x6a2b [tcrypt] + ? 0xffffffffa00f4000 + tcrypt_mod_init+0x50/0x1000 [tcrypt] + ... + +The second modprobe command never finishes because in padata_reorder, +CPU0's load of reorder_objects is executed before the unlocking store in +spin_unlock_bh(pd->lock), causing CPU0 to miss CPU1's increment: + +CPU0 CPU1 + +padata_reorder padata_do_serial + LOAD reorder_objects // 0 + INC reorder_objects // 1 + padata_reorder + TRYLOCK pd->lock // failed + UNLOCK pd->lock + +CPU0 deletes the timer before returning from padata_reorder and since no +other job is submitted to padata, modprobe waits indefinitely. + +Add a pair of full barriers to guarantee proper ordering: + +CPU0 CPU1 + +padata_reorder padata_do_serial + UNLOCK pd->lock + smp_mb() + LOAD reorder_objects + INC reorder_objects + smp_mb__after_atomic() + padata_reorder + TRYLOCK pd->lock + +smp_mb__after_atomic is needed so the read part of the trylock operation +comes after the INC, as Andrea points out. Thanks also to Andrea for +help with writing a litmus test. + +Fixes: 16295bec6398 ("padata: Generic parallelization/serialization interface") +Signed-off-by: Daniel Jordan +Cc: +Cc: Andrea Parri +Cc: Boqun Feng +Cc: Herbert Xu +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Steffen Klassert +Cc: linux-arch@vger.kernel.org +Cc: linux-crypto@vger.kernel.org +Cc: linux-kernel@vger.kernel.org +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/padata.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/kernel/padata.c ++++ b/kernel/padata.c +@@ -273,7 +273,12 @@ static void padata_reorder(struct parall + * The next object that needs serialization might have arrived to + * the reorder queues in the meantime, we will be called again + * from the timer function if no one else cares for it. ++ * ++ * Ensure reorder_objects is read after pd->lock is dropped so we see ++ * an increment from another task in padata_do_serial. Pairs with ++ * smp_mb__after_atomic in padata_do_serial. + */ ++ smp_mb(); + if (atomic_read(&pd->reorder_objects) + && !(pinst->flags & PADATA_RESET)) + mod_timer(&pd->timer, jiffies + HZ); +@@ -342,6 +347,13 @@ void padata_do_serial(struct padata_priv + list_add_tail(&padata->list, &pqueue->reorder.list); + spin_unlock(&pqueue->reorder.lock); + ++ /* ++ * Ensure the atomic_inc of reorder_objects above is ordered correctly ++ * with the trylock of pd->lock in padata_reorder. Pairs with smp_mb ++ * in padata_reorder. ++ */ ++ smp_mb__after_atomic(); ++ + put_cpu(); + + padata_reorder(pd); diff --git a/queue-4.4/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch b/queue-4.4/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch new file mode 100644 index 00000000000..d63d5ca1ee9 --- /dev/null +++ b/queue-4.4/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch @@ -0,0 +1,56 @@ +From 000dd5316e1c756a1c028f22e01d06a38249dd4d Mon Sep 17 00:00:00 2001 +From: Mika Westerberg +Date: Wed, 12 Jun 2019 13:57:39 +0300 +Subject: PCI: Do not poll for PME if the device is in D3cold + +From: Mika Westerberg + +commit 000dd5316e1c756a1c028f22e01d06a38249dd4d upstream. + +PME polling does not take into account that a device that is directly +connected to the host bridge may go into D3cold as well. This leads to a +situation where the PME poll thread reads from a config space of a +device that is in D3cold and gets incorrect information because the +config space is not accessible. + +Here is an example from Intel Ice Lake system where two PCIe root ports +are in D3cold (I've instrumented the kernel to log the PMCSR register +contents): + + [ 62.971442] pcieport 0000:00:07.1: Check PME status, PMCSR=0xffff + [ 62.971504] pcieport 0000:00:07.0: Check PME status, PMCSR=0xffff + +Since 0xffff is interpreted so that PME is pending, the root ports will +be runtime resumed. This repeats over and over again essentially +blocking all runtime power management. + +Prevent this from happening by checking whether the device is in D3cold +before its PME status is read. + +Fixes: 71a83bd727cc ("PCI/PM: add runtime PM support to PCIe port") +Signed-off-by: Mika Westerberg +Reviewed-by: Lukas Wunner +Cc: 3.6+ # v3.6+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/pci/pci.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/pci/pci.c ++++ b/drivers/pci/pci.c +@@ -1736,6 +1736,13 @@ static void pci_pme_list_scan(struct wor + */ + if (bridge && bridge->current_state != PCI_D0) + continue; ++ /* ++ * If the device is in D3cold it should not be ++ * polled either. ++ */ ++ if (pme_dev->dev->current_state == PCI_D3cold) ++ continue; ++ + pci_pme_wakeup(pme_dev->dev, NULL); + } else { + list_del(&pme_dev->list); diff --git a/queue-4.4/series b/queue-4.4/series index b94c5aaecad..07f9434b2f0 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -69,3 +69,8 @@ alsa-seq-break-too-long-mutex-context-in-the-write-loop.patch media-v4l2-test-type-instead-of-cfg-type-in-v4l2_ctrl_new_custom.patch media-coda-remove-unbalanced-and-unneeded-mutex-unlock.patch kvm-x86-vpmu-refine-kvm_pmu-err-msg-when-event-creation-failed.patch +drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch +padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch +9p-virtio-add-cleanup-path-in-p9_virtio_init.patch +pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch +btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch