--- /dev/null
+From 167beb1756791e0806365a3f86a0da10d7a327ee Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Sat, 9 Nov 2019 19:16:58 +0100
+Subject: ALSA: usb-audio: Fix missing error check at mixer resolution test
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 167beb1756791e0806365a3f86a0da10d7a327ee upstream.
+
+A check of the return value from get_cur_mix_raw() is missing at the
+resolution test code in get_min_max_with_quirks(), which may leave the
+variable untouched, leading to a random uninitialized value, as
+detected by syzkaller fuzzer.
+
+Add the missing return error check for fixing that.
+
+Reported-and-tested-by: syzbot+abe1ab7afc62c6bb6377@syzkaller.appspotmail.com
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191109181658.30368-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/mixer.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/sound/usb/mixer.c
++++ b/sound/usb/mixer.c
+@@ -1046,7 +1046,8 @@ static int get_min_max_with_quirks(struc
+ if (cval->min + cval->res < cval->max) {
+ int last_valid_res = cval->res;
+ int saved, test, check;
+- get_cur_mix_raw(cval, minchn, &saved);
++ if (get_cur_mix_raw(cval, minchn, &saved) < 0)
++ goto no_res_check;
+ for (;;) {
+ test = saved;
+ if (test < cval->max)
+@@ -1066,6 +1067,7 @@ static int get_min_max_with_quirks(struc
+ snd_usb_set_cur_mix_value(cval, minchn, 0, saved);
+ }
+
++no_res_check:
+ cval->initialized = 1;
+ }
+
--- /dev/null
+From 528699317dd6dc722dccc11b68800cf945109390 Mon Sep 17 00:00:00 2001
+From: Henry Lin <henryl@nvidia.com>
+Date: Wed, 13 Nov 2019 10:14:19 +0800
+Subject: ALSA: usb-audio: not submit urb for stopped endpoint
+
+From: Henry Lin <henryl@nvidia.com>
+
+commit 528699317dd6dc722dccc11b68800cf945109390 upstream.
+
+While output urb's snd_complete_urb() is executing, calling
+prepare_outbound_urb() may cause endpoint stopped before
+prepare_outbound_urb() returns and result in next urb submitted
+to stopped endpoint. usb-audio driver cannot re-use it afterwards as
+the urb is still hold by usb stack.
+
+This change checks EP_FLAG_RUNNING flag after prepare_outbound_urb() again
+to let snd_complete_urb() know the endpoint already stopped and does not
+submit next urb. Below kind of error will be fixed:
+
+[ 213.153103] usb 1-2: timeout: still 1 active urbs on EP #1
+[ 213.164121] usb 1-2: cannot submit urb 0, error -16: unknown error
+
+Signed-off-by: Henry Lin <henryl@nvidia.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191113021420.13377-1-henryl@nvidia.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/endpoint.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/sound/usb/endpoint.c
++++ b/sound/usb/endpoint.c
+@@ -403,6 +403,9 @@ static void snd_complete_urb(struct urb
+ }
+
+ prepare_outbound_urb(ep, ctx);
++ /* can be stopped during prepare callback */
++ if (unlikely(!test_bit(EP_FLAG_RUNNING, &ep->flags)))
++ goto exit_clear;
+ } else {
+ retire_inbound_urb(ep, ctx);
+ /* can be stopped during retire callback */
--- /dev/null
+From e72b9dd6a5f17d0fb51f16f8685f3004361e83d0 Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Sun, 3 Nov 2019 13:45:04 -0500
+Subject: ecryptfs_lookup_interpose(): lower_dentry->d_inode is not stable
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit e72b9dd6a5f17d0fb51f16f8685f3004361e83d0 upstream.
+
+lower_dentry can't go from positive to negative (we have it pinned),
+but it *can* go from negative to positive. So fetching ->d_inode
+into a local variable, doing a blocking allocation, checking that
+now ->d_inode is non-NULL and feeding the value we'd fetched
+earlier to a function that won't accept NULL is not a good idea.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ecryptfs/inode.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/fs/ecryptfs/inode.c
++++ b/fs/ecryptfs/inode.c
+@@ -326,7 +326,7 @@ static int ecryptfs_i_size_read(struct d
+ static struct dentry *ecryptfs_lookup_interpose(struct dentry *dentry,
+ struct dentry *lower_dentry)
+ {
+- struct inode *inode, *lower_inode = d_inode(lower_dentry);
++ struct inode *inode, *lower_inode;
+ struct ecryptfs_dentry_info *dentry_info;
+ struct vfsmount *lower_mnt;
+ int rc = 0;
+@@ -349,7 +349,15 @@ static struct dentry *ecryptfs_lookup_in
+ dentry_info->lower_path.mnt = lower_mnt;
+ dentry_info->lower_path.dentry = lower_dentry;
+
+- if (d_really_is_negative(lower_dentry)) {
++ /*
++ * negative dentry can go positive under us here - its parent is not
++ * locked. That's OK and that could happen just as we return from
++ * ecryptfs_lookup() anyway. Just need to be careful and fetch
++ * ->d_inode only once - it's not stable here.
++ */
++ lower_inode = READ_ONCE(lower_dentry->d_inode);
++
++ if (!lower_inode) {
+ /* We want to add because we couldn't find in lower */
+ d_add(dentry, NULL);
+ return NULL;
--- /dev/null
+From 762c69685ff7ad5ad7fee0656671e20a0c9c864d Mon Sep 17 00:00:00 2001
+From: Al Viro <viro@zeniv.linux.org.uk>
+Date: Sun, 3 Nov 2019 13:55:43 -0500
+Subject: ecryptfs_lookup_interpose(): lower_dentry->d_parent is not stable either
+
+From: Al Viro <viro@zeniv.linux.org.uk>
+
+commit 762c69685ff7ad5ad7fee0656671e20a0c9c864d upstream.
+
+We need to get the underlying dentry of parent; sure, absent the races
+it is the parent of underlying dentry, but there's nothing to prevent
+losing a timeslice to preemtion in the middle of evaluation of
+lower_dentry->d_parent->d_inode, having another process move lower_dentry
+around and have its (ex)parent not pinned anymore and freed on memory
+pressure. Then we regain CPU and try to fetch ->d_inode from memory
+that is freed by that point.
+
+dentry->d_parent *is* stable here - it's an argument of ->lookup() and
+we are guaranteed that it won't be moved anywhere until we feed it
+to d_add/d_splice_alias. So we safely go that way to get to its
+underlying dentry.
+
+Cc: stable@vger.kernel.org # since 2009 or so
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ecryptfs/inode.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+--- a/fs/ecryptfs/inode.c
++++ b/fs/ecryptfs/inode.c
+@@ -326,9 +326,9 @@ static int ecryptfs_i_size_read(struct d
+ static struct dentry *ecryptfs_lookup_interpose(struct dentry *dentry,
+ struct dentry *lower_dentry)
+ {
++ struct path *path = ecryptfs_dentry_to_lower_path(dentry->d_parent);
+ struct inode *inode, *lower_inode;
+ struct ecryptfs_dentry_info *dentry_info;
+- struct vfsmount *lower_mnt;
+ int rc = 0;
+
+ dentry_info = kmem_cache_alloc(ecryptfs_dentry_info_cache, GFP_KERNEL);
+@@ -340,13 +340,12 @@ static struct dentry *ecryptfs_lookup_in
+ return ERR_PTR(-ENOMEM);
+ }
+
+- lower_mnt = mntget(ecryptfs_dentry_to_lower_mnt(dentry->d_parent));
+ fsstack_copy_attr_atime(d_inode(dentry->d_parent),
+- d_inode(lower_dentry->d_parent));
++ d_inode(path->dentry));
+ BUG_ON(!d_count(lower_dentry));
+
+ ecryptfs_set_dentry_private(dentry, dentry_info);
+- dentry_info->lower_path.mnt = lower_mnt;
++ dentry_info->lower_path.mnt = mntget(path->mnt);
+ dentry_info->lower_path.dentry = lower_dentry;
+
+ /*
--- /dev/null
+From a9c3c4c597704b3a1a2b9bef990e7d8a881f6533 Mon Sep 17 00:00:00 2001
+From: James Erwin <james.erwin@intel.com>
+Date: Fri, 1 Nov 2019 15:20:59 -0400
+Subject: IB/hfi1: Ensure full Gen3 speed in a Gen4 system
+
+From: James Erwin <james.erwin@intel.com>
+
+commit a9c3c4c597704b3a1a2b9bef990e7d8a881f6533 upstream.
+
+If an hfi1 card is inserted in a Gen4 systems, the driver will avoid the
+gen3 speed bump and the card will operate at half speed.
+
+This is because the driver avoids the gen3 speed bump when the parent bus
+speed isn't identical to gen3, 8.0GT/s. This is not compatible with gen4
+and newer speeds.
+
+Fix by relaxing the test to explicitly look for the lower capability
+speeds which inherently allows for gen4 and all future speeds.
+
+Fixes: 7724105686e7 ("IB/hfi1: add driver files")
+Link: https://lore.kernel.org/r/20191101192059.106248.1699.stgit@awfm-01.aw.intel.com
+Cc: <stable@vger.kernel.org>
+Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Reviewed-by: Kaike Wan <kaike.wan@intel.com>
+Signed-off-by: James Erwin <james.erwin@intel.com>
+Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/hfi1/pcie.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/infiniband/hw/hfi1/pcie.c
++++ b/drivers/infiniband/hw/hfi1/pcie.c
+@@ -377,7 +377,9 @@ int pcie_speeds(struct hfi1_devdata *dd)
+ /*
+ * bus->max_bus_speed is set from the bridge's linkcap Max Link Speed
+ */
+- if (parent && dd->pcidev->bus->max_bus_speed != PCIE_SPEED_8_0GT) {
++ if (parent &&
++ (dd->pcidev->bus->max_bus_speed == PCIE_SPEED_2_5GT ||
++ dd->pcidev->bus->max_bus_speed == PCIE_SPEED_5_0GT)) {
+ dd_dev_info(dd, "Parent PCIe bridge does not support Gen3\n");
+ dd->link_gen3_capable = 0;
+ }
--- /dev/null
+From fa3a5a1880c91bb92594ad42dfe9eedad7996b86 Mon Sep 17 00:00:00 2001
+From: Oliver Neukum <oneukum@suse.com>
+Date: Fri, 15 Nov 2019 11:35:05 -0800
+Subject: Input: ff-memless - kill timer in destroy()
+
+From: Oliver Neukum <oneukum@suse.com>
+
+commit fa3a5a1880c91bb92594ad42dfe9eedad7996b86 upstream.
+
+No timer must be left running when the device goes away.
+
+Signed-off-by: Oliver Neukum <oneukum@suse.com>
+Reported-and-tested-by: syzbot+b6c55daa701fc389e286@syzkaller.appspotmail.com
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/1573726121.17351.3.camel@suse.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/ff-memless.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/drivers/input/ff-memless.c
++++ b/drivers/input/ff-memless.c
+@@ -501,6 +501,15 @@ static void ml_ff_destroy(struct ff_devi
+ {
+ struct ml_device *ml = ff->private;
+
++ /*
++ * Even though we stop all playing effects when tearing down
++ * an input device (via input_device_flush() that calls into
++ * input_ff_flush() that stops and erases all effects), we
++ * do not actually stop the timer, and therefore we should
++ * do it here.
++ */
++ del_timer_sync(&ml->timer);
++
+ kfree(ml->private);
+ }
+
--- /dev/null
+From 549766ac2ac1f6c8bb85906bbcea759541bb19a2 Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Tue, 12 Nov 2019 16:47:08 -0800
+Subject: Input: synaptics-rmi4 - clear IRQ enables for F54
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+commit 549766ac2ac1f6c8bb85906bbcea759541bb19a2 upstream.
+
+The driver for F54 just polls the status and doesn't even have a IRQ
+handler registered. Make sure to disable all F54 IRQs, so we don't crash
+the kernel on a nonexistent handler.
+
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Link: https://lore.kernel.org/r/20191105114402.6009-1-l.stach@pengutronix.de
+Cc: stable@vger.kernel.org
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/rmi4/rmi_f54.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/input/rmi4/rmi_f54.c
++++ b/drivers/input/rmi4/rmi_f54.c
+@@ -617,7 +617,7 @@ static int rmi_f54_config(struct rmi_fun
+ {
+ struct rmi_driver *drv = fn->rmi_dev->driver;
+
+- drv->set_irq_bits(fn->rmi_dev, fn->irq_mask);
++ drv->clear_irq_bits(fn->rmi_dev, fn->irq_mask);
+
+ return 0;
+ }
--- /dev/null
+From ba60cf9f78f0d7c8e73c7390608f7f818ee68aa0 Mon Sep 17 00:00:00 2001
+From: Chuhong Yuan <hslester96@gmail.com>
+Date: Fri, 15 Nov 2019 11:32:36 -0800
+Subject: Input: synaptics-rmi4 - destroy F54 poller workqueue when removing
+
+From: Chuhong Yuan <hslester96@gmail.com>
+
+commit ba60cf9f78f0d7c8e73c7390608f7f818ee68aa0 upstream.
+
+The driver forgets to destroy workqueue in remove() similarly to what is
+done when probe() fails. Add a call to destroy_workqueue() to fix it.
+
+Since unregistration will wait for the work to finish, we do not need to
+cancel/flush the work instance in remove().
+
+Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191114023405.31477-1-hslester96@gmail.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/rmi4/rmi_f54.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/input/rmi4/rmi_f54.c
++++ b/drivers/input/rmi4/rmi_f54.c
+@@ -744,6 +744,7 @@ static void rmi_f54_remove(struct rmi_fu
+
+ video_unregister_device(&f54->vdev);
+ v4l2_device_unregister(&f54->v4l2);
++ destroy_workqueue(f54->workqueue);
+ }
+
+ struct rmi_function_handler rmi_f54_handler = {
--- /dev/null
+From 003f01c780020daa9a06dea1db495b553a868c29 Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Mon, 4 Nov 2019 15:58:34 -0800
+Subject: Input: synaptics-rmi4 - fix video buffer size
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+commit 003f01c780020daa9a06dea1db495b553a868c29 upstream.
+
+The video buffer used by the queue is a vb2_v4l2_buffer, not a plain
+vb2_buffer. Using the wrong type causes the allocation of the buffer
+storage to be too small, causing a out of bounds write when
+__init_vb2_v4l2_buffer initializes the buffer.
+
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Fixes: 3a762dbd5347 ("[media] Input: synaptics-rmi4 - add support for F54 diagnostics")
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191104114454.10500-1-l.stach@pengutronix.de
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/rmi4/rmi_f54.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/input/rmi4/rmi_f54.c
++++ b/drivers/input/rmi4/rmi_f54.c
+@@ -364,7 +364,7 @@ static const struct vb2_ops rmi_f54_queu
+ static const struct vb2_queue rmi_f54_queue = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .io_modes = VB2_MMAP | VB2_USERPTR | VB2_DMABUF | VB2_READ,
+- .buf_struct_size = sizeof(struct vb2_buffer),
++ .buf_struct_size = sizeof(struct vb2_v4l2_buffer),
+ .ops = &rmi_f54_queue_ops,
+ .mem_ops = &vb2_vmalloc_memops,
+ .timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
--- /dev/null
+From 4e7120d79edb31e4ee68e6f8421448e4603be1e9 Mon Sep 17 00:00:00 2001
+From: Eric Auger <eric.auger@redhat.com>
+Date: Fri, 8 Nov 2019 16:58:03 +0100
+Subject: iommu/vt-d: Fix QI_DEV_IOTLB_PFSID and QI_DEV_EIOTLB_PFSID macros
+
+From: Eric Auger <eric.auger@redhat.com>
+
+commit 4e7120d79edb31e4ee68e6f8421448e4603be1e9 upstream.
+
+For both PASID-based-Device-TLB Invalidate Descriptor and
+Device-TLB Invalidate Descriptor, the Physical Function Source-ID
+value is split according to this layout:
+
+PFSID[3:0] is set at offset 12 and PFSID[15:4] is put at offset 52.
+Fix the part laid out at offset 52.
+
+Fixes: 0f725561e1684 ("iommu/vt-d: Add definitions for PFSID")
+Signed-off-by: Eric Auger <eric.auger@redhat.com>
+Acked-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Cc: stable@vger.kernel.org # v4.19+
+Acked-by: Lu Baolu <baolu.lu@linux.intel.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/intel-iommu.h | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/include/linux/intel-iommu.h
++++ b/include/linux/intel-iommu.h
+@@ -295,7 +295,8 @@ enum {
+ #define QI_DEV_IOTLB_SID(sid) ((u64)((sid) & 0xffff) << 32)
+ #define QI_DEV_IOTLB_QDEP(qdep) (((qdep) & 0x1f) << 16)
+ #define QI_DEV_IOTLB_ADDR(addr) ((u64)(addr) & VTD_PAGE_MASK)
+-#define QI_DEV_IOTLB_PFSID(pfsid) (((u64)(pfsid & 0xf) << 12) | ((u64)(pfsid & 0xfff) << 52))
++#define QI_DEV_IOTLB_PFSID(pfsid) (((u64)(pfsid & 0xf) << 12) | \
++ ((u64)((pfsid >> 4) & 0xfff) << 52))
+ #define QI_DEV_IOTLB_SIZE 1
+ #define QI_DEV_IOTLB_MAX_INVS 32
+
+@@ -320,7 +321,8 @@ enum {
+ #define QI_DEV_EIOTLB_PASID(p) (((u64)p) << 32)
+ #define QI_DEV_EIOTLB_SID(sid) ((u64)((sid) & 0xffff) << 16)
+ #define QI_DEV_EIOTLB_QDEP(qd) ((u64)((qd) & 0x1f) << 4)
+-#define QI_DEV_EIOTLB_PFSID(pfsid) (((u64)(pfsid & 0xf) << 12) | ((u64)(pfsid & 0xfff) << 52))
++#define QI_DEV_EIOTLB_PFSID(pfsid) (((u64)(pfsid & 0xf) << 12) | \
++ ((u64)((pfsid >> 4) & 0xfff) << 52))
+ #define QI_DEV_EIOTLB_MAX_INVS 32
+
+ #define QI_PGRP_IDX(idx) (((u64)(idx)) << 55)
--- /dev/null
+From 0362f326d86c645b5e96b7dbc3ee515986ed019d Mon Sep 17 00:00:00 2001
+From: Roman Gushchin <guro@fb.com>
+Date: Fri, 15 Nov 2019 17:34:46 -0800
+Subject: mm: hugetlb: switch to css_tryget() in hugetlb_cgroup_charge_cgroup()
+
+From: Roman Gushchin <guro@fb.com>
+
+commit 0362f326d86c645b5e96b7dbc3ee515986ed019d upstream.
+
+An exiting task might belong to an offline cgroup. In this case an
+attempt to grab a cgroup reference from the task can end up with an
+infinite loop in hugetlb_cgroup_charge_cgroup(), because neither the
+cgroup will become online, neither the task will be migrated to a live
+cgroup.
+
+Fix this by switching over to css_tryget(). As css_tryget_online()
+can't guarantee that the cgroup won't go offline, in most cases the
+check doesn't make sense. In this particular case users of
+hugetlb_cgroup_charge_cgroup() are not affected by this change.
+
+A similar problem is described by commit 18fa84a2db0e ("cgroup: Use
+css_tryget() instead of css_tryget_online() in task_get_css()").
+
+Link: http://lkml.kernel.org/r/20191106225131.3543616-2-guro@fb.com
+Signed-off-by: Roman Gushchin <guro@fb.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Tejun Heo <tj@kernel.org>
+Reviewed-by: Shakeel Butt <shakeelb@google.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/hugetlb_cgroup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/hugetlb_cgroup.c
++++ b/mm/hugetlb_cgroup.c
+@@ -196,7 +196,7 @@ int hugetlb_cgroup_charge_cgroup(int idx
+ again:
+ rcu_read_lock();
+ h_cg = hugetlb_cgroup_from_task(current);
+- if (!css_tryget_online(&h_cg->css)) {
++ if (!css_tryget(&h_cg->css)) {
+ rcu_read_unlock();
+ goto again;
+ }
--- /dev/null
+From 00d484f354d85845991b40141d40ba9e5eb60faf Mon Sep 17 00:00:00 2001
+From: Roman Gushchin <guro@fb.com>
+Date: Fri, 15 Nov 2019 17:34:43 -0800
+Subject: mm: memcg: switch to css_tryget() in get_mem_cgroup_from_mm()
+
+From: Roman Gushchin <guro@fb.com>
+
+commit 00d484f354d85845991b40141d40ba9e5eb60faf upstream.
+
+We've encountered a rcu stall in get_mem_cgroup_from_mm():
+
+ rcu: INFO: rcu_sched self-detected stall on CPU
+ rcu: 33-....: (21000 ticks this GP) idle=6c6/1/0x4000000000000002 softirq=35441/35441 fqs=5017
+ (t=21031 jiffies g=324821 q=95837) NMI backtrace for cpu 33
+ <...>
+ RIP: 0010:get_mem_cgroup_from_mm+0x2f/0x90
+ <...>
+ __memcg_kmem_charge+0x55/0x140
+ __alloc_pages_nodemask+0x267/0x320
+ pipe_write+0x1ad/0x400
+ new_sync_write+0x127/0x1c0
+ __kernel_write+0x4f/0xf0
+ dump_emit+0x91/0xc0
+ writenote+0xa0/0xc0
+ elf_core_dump+0x11af/0x1430
+ do_coredump+0xc65/0xee0
+ get_signal+0x132/0x7c0
+ do_signal+0x36/0x640
+ exit_to_usermode_loop+0x61/0xd0
+ do_syscall_64+0xd4/0x100
+ entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+The problem is caused by an exiting task which is associated with an
+offline memcg. We're iterating over and over in the do {} while
+(!css_tryget_online()) loop, but obviously the memcg won't become online
+and the exiting task won't be migrated to a live memcg.
+
+Let's fix it by switching from css_tryget_online() to css_tryget().
+
+As css_tryget_online() cannot guarantee that the memcg won't go offline,
+the check is usually useless, except some rare cases when for example it
+determines if something should be presented to a user.
+
+A similar problem is described by commit 18fa84a2db0e ("cgroup: Use
+css_tryget() instead of css_tryget_online() in task_get_css()").
+
+Johannes:
+
+: The bug aside, it doesn't matter whether the cgroup is online for the
+: callers. It used to matter when offlining needed to evacuate all charges
+: from the memcg, and so needed to prevent new ones from showing up, but we
+: don't care now.
+
+Link: http://lkml.kernel.org/r/20191106225131.3543616-1-guro@fb.com
+Signed-off-by: Roman Gushchin <guro@fb.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Tejun Heo <tj@kernel.org>
+Reviewed-by: Shakeel Butt <shakeeb@google.com>
+Cc: Michal Hocko <mhocko@kernel.org>
+Cc: Michal Koutn <mkoutny@suse.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/memcontrol.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -741,7 +741,7 @@ static struct mem_cgroup *get_mem_cgroup
+ if (unlikely(!memcg))
+ memcg = root_mem_cgroup;
+ }
+- } while (!css_tryget_online(&memcg->css));
++ } while (!css_tryget(&memcg->css));
+ rcu_read_unlock();
+ return memcg;
+ }
--- /dev/null
+From fed23c5829ecab4ddc712d7b0046e59610ca3ba4 Mon Sep 17 00:00:00 2001
+From: Eugen Hristev <eugen.hristev@microchip.com>
+Date: Thu, 14 Nov 2019 12:59:26 +0000
+Subject: mmc: sdhci-of-at91: fix quirk2 overwrite
+
+From: Eugen Hristev <eugen.hristev@microchip.com>
+
+commit fed23c5829ecab4ddc712d7b0046e59610ca3ba4 upstream.
+
+The quirks2 are parsed and set (e.g. from DT) before the quirk for broken
+HS200 is set in the driver.
+The driver needs to enable just this flag, not rewrite the whole quirk set.
+
+Fixes: 7871aa60ae00 ("mmc: sdhci-of-at91: add quirk for broken HS200")
+Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
+Acked-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-of-at91.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-of-at91.c
++++ b/drivers/mmc/host/sdhci-of-at91.c
+@@ -318,7 +318,7 @@ static int sdhci_at91_probe(struct platf
+ pm_runtime_use_autosuspend(&pdev->dev);
+
+ /* HS200 is broken at this moment */
+- host->quirks2 = SDHCI_QUIRK2_BROKEN_HS200;
++ host->quirks2 |= SDHCI_QUIRK2_BROKEN_HS200;
+
+ ret = sdhci_add_host(host);
+ if (ret)
ax88172a-fix-information-leak-on-short-answers.patch
slip-fix-memory-leak-in-slip_open-error-path.patch
+alsa-usb-audio-fix-missing-error-check-at-mixer-resolution-test.patch
+alsa-usb-audio-not-submit-urb-for-stopped-endpoint.patch
+input-ff-memless-kill-timer-in-destroy.patch
+input-synaptics-rmi4-fix-video-buffer-size.patch
+input-synaptics-rmi4-clear-irq-enables-for-f54.patch
+input-synaptics-rmi4-destroy-f54-poller-workqueue-when-removing.patch
+ib-hfi1-ensure-full-gen3-speed-in-a-gen4-system.patch
+x86-quirks-disable-hpet-on-intel-coffe-lake-platforms.patch
+ecryptfs_lookup_interpose-lower_dentry-d_inode-is-not-stable.patch
+ecryptfs_lookup_interpose-lower_dentry-d_parent-is-not-stable-either.patch
+iommu-vt-d-fix-qi_dev_iotlb_pfsid-and-qi_dev_eiotlb_pfsid-macros.patch
+mm-memcg-switch-to-css_tryget-in-get_mem_cgroup_from_mm.patch
+mm-hugetlb-switch-to-css_tryget-in-hugetlb_cgroup_charge_cgroup.patch
+mmc-sdhci-of-at91-fix-quirk2-overwrite.patch
--- /dev/null
+From fc5db58539b49351e76f19817ed1102bf7c712d0 Mon Sep 17 00:00:00 2001
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Date: Wed, 16 Oct 2019 18:38:16 +0800
+Subject: x86/quirks: Disable HPET on Intel Coffe Lake platforms
+
+From: Kai-Heng Feng <kai.heng.feng@canonical.com>
+
+commit fc5db58539b49351e76f19817ed1102bf7c712d0 upstream.
+
+Some Coffee Lake platforms have a skewed HPET timer once the SoCs entered
+PC10, which in consequence marks TSC as unstable because HPET is used as
+watchdog clocksource for TSC.
+
+Harry Pan tried to work around it in the clocksource watchdog code [1]
+thereby creating a circular dependency between HPET and TSC. This also
+ignores the fact, that HPET is not only unsuitable as watchdog clocksource
+on these systems, it becomes unusable in general.
+
+Disable HPET on affected platforms.
+
+Suggested-by: Feng Tang <feng.tang@intel.com>
+Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203183
+Link: https://lore.kernel.org/lkml/20190516090651.1396-1-harry.pan@intel.com/ [1]
+Link: https://lkml.kernel.org/r/20191016103816.30650-1-kai.heng.feng@canonical.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/early-quirks.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/early-quirks.c
++++ b/arch/x86/kernel/early-quirks.c
+@@ -677,6 +677,8 @@ static struct chipset early_qrk[] __init
+ */
+ { PCI_VENDOR_ID_INTEL, 0x0f00,
+ PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
++ { PCI_VENDOR_ID_INTEL, 0x3ec4,
++ PCI_CLASS_BRIDGE_HOST, PCI_ANY_ID, 0, force_disable_hpet},
+ { PCI_VENDOR_ID_BROADCOM, 0x4331,
+ PCI_CLASS_NETWORK_OTHER, PCI_ANY_ID, 0, apple_airport_reset},
+ {}
projects / thirdparty / kernel / stable-queue.git / commitdiff
