]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.4-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 23 Jul 2019 12:11:12 +0000 (14:11 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Tue, 23 Jul 2019 12:11:12 +0000 (14:11 +0200)
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

queue-4.4/9p-virtio-add-cleanup-path-in-p9_virtio_init.patch [new file with mode: 0644]
queue-4.4/btrfs-add-missing-inode-version-ctime-and-mtime-updates-when-punching-hole.patch [new file with mode: 0644]
queue-4.4/drm-nouveau-i2c-enable-i2c-pads-busses-during-preinit.patch [new file with mode: 0644]
queue-4.4/padata-use-smp_mb-in-padata_reorder-to-avoid-orphaned-padata-jobs.patch [new file with mode: 0644]
queue-4.4/pci-do-not-poll-for-pme-if-the-device-is-in-d3cold.patch [new file with mode: 0644]
queue-4.4/series

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 (file)
index 0000000..32207fa
--- /dev/null
@@ -0,0 +1,89 @@
+From d4548543fc4ece56c6f04b8586f435fb4fd84c20 Mon Sep 17 00:00:00 2001
+From: YueHaibing <yuehaibing@huawei.com>
+Date: Tue, 30 Apr 2019 19:59:42 +0800
+Subject: 9p/virtio: Add cleanup path in p9_virtio_init
+
+From: YueHaibing <yuehaibing@huawei.com>
+
+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 <hulkci@huawei.com>
+Fixes: b530cc794024 ("9p: add virtio transport")
+Signed-off-by: YueHaibing <yuehaibing@huawei.com>
+Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..8b92a29
--- /dev/null
@@ -0,0 +1,42 @@
+From 179006688a7e888cbff39577189f2e034786d06a Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+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 <fdmanana@suse.com>
+
+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 <fdmanana@suse.com>
+Signed-off-by: David Sterba <dsterba@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..4539b61
--- /dev/null
@@ -0,0 +1,78 @@
+From 7cb95eeea6706c790571042a06782e378b2561ea Mon Sep 17 00:00:00 2001
+From: Lyude Paul <lyude@redhat.com>
+Date: Wed, 26 Jun 2019 14:10:27 -0400
+Subject: drm/nouveau/i2c: Enable i2c pads & busses during preinit
+
+From: Lyude Paul <lyude@redhat.com>
+
+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 <lyude@redhat.com>
+Tested-by: Marc Meledandri <m.meledandri@gmail.com>
+Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..f05d6f0
--- /dev/null
@@ -0,0 +1,117 @@
+From cf144f81a99d1a3928f90b0936accfd3f45c9a0a Mon Sep 17 00:00:00 2001
+From: Daniel Jordan <daniel.m.jordan@oracle.com>
+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 <daniel.m.jordan@oracle.com>
+
+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 <daniel.m.jordan@oracle.com>
+Cc: <stable@vger.kernel.org>
+Cc: Andrea Parri <andrea.parri@amarulasolutions.com>
+Cc: Boqun Feng <boqun.feng@gmail.com>
+Cc: Herbert Xu <herbert@gondor.apana.org.au>
+Cc: Paul E. McKenney <paulmck@linux.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Steffen Klassert <steffen.klassert@secunet.com>
+Cc: linux-arch@vger.kernel.org
+Cc: linux-crypto@vger.kernel.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 (file)
index 0000000..d63d5ca
--- /dev/null
@@ -0,0 +1,56 @@
+From 000dd5316e1c756a1c028f22e01d06a38249dd4d Mon Sep 17 00:00:00 2001
+From: Mika Westerberg <mika.westerberg@linux.intel.com>
+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 <mika.westerberg@linux.intel.com>
+
+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 <mika.westerberg@linux.intel.com>
+Reviewed-by: Lukas Wunner <lukas@wunner.de>
+Cc: 3.6+ <stable@vger.kernel.org> # v3.6+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
index b94c5aaecad9804b6d20f54a522629aa722a6d5a..07f9434b2f09770df8b59bc204e56eaccd7e8ed6 100644 (file)
@@ -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