]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.19-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 18 Nov 2019 15:56:14 +0000 (16:56 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Mon, 18 Nov 2019 15:56:14 +0000 (16:56 +0100)
added patches:
alsa-usb-audio-fix-incorrect-null-check-in-create_yamaha_midi_quirk.patch
alsa-usb-audio-fix-incorrect-size-check-for-processing-extension-units.patch
alsa-usb-audio-fix-missing-error-check-at-mixer-resolution-test.patch
alsa-usb-audio-not-submit-urb-for-stopped-endpoint.patch
btrfs-fix-log-context-list-corruption-after-rename-exchange-operation.patch
ecryptfs_lookup_interpose-lower_dentry-d_inode-is-not-stable.patch
ecryptfs_lookup_interpose-lower_dentry-d_parent-is-not-stable-either.patch
i2c-acpi-force-bus-speed-to-400khz-if-a-silead-touchscreen-is-present.patch
ib-hfi1-ensure-full-gen3-speed-in-a-gen4-system.patch
ib-hfi1-use-a-common-pad-buffer-for-9b-and-16b-packets.patch
input-ff-memless-kill-timer-in-destroy.patch
input-synaptics-rmi4-clear-irq-enables-for-f54.patch
input-synaptics-rmi4-destroy-f54-poller-workqueue-when-removing.patch
input-synaptics-rmi4-disable-the-relative-position-irq-in-the-f12-driver.patch
input-synaptics-rmi4-do-not-consume-more-data-than-we-have-f11-f12.patch
input-synaptics-rmi4-fix-video-buffer-size.patch
iommu-vt-d-fix-qi_dev_iotlb_pfsid-and-qi_dev_eiotlb_pfsid-macros.patch
mm-hugetlb-switch-to-css_tryget-in-hugetlb_cgroup_charge_cgroup.patch
mm-memcg-switch-to-css_tryget-in-get_mem_cgroup_from_mm.patch
mm-mempolicy-fix-the-wrong-return-value-and-potential-pages-leak-of-mbind.patch
mm-page_io.c-do-not-free-shared-swap-slots.patch
mmc-sdhci-of-at91-fix-quirk2-overwrite.patch
net-ethernet-dwmac-sun8i-use-the-correct-function-in-exit-path.patch
x86-quirks-disable-hpet-on-intel-coffe-lake-platforms.patch

25 files changed:
queue-4.19/alsa-usb-audio-fix-incorrect-null-check-in-create_yamaha_midi_quirk.patch [new file with mode: 0644]
queue-4.19/alsa-usb-audio-fix-incorrect-size-check-for-processing-extension-units.patch [new file with mode: 0644]
queue-4.19/alsa-usb-audio-fix-missing-error-check-at-mixer-resolution-test.patch [new file with mode: 0644]
queue-4.19/alsa-usb-audio-not-submit-urb-for-stopped-endpoint.patch [new file with mode: 0644]
queue-4.19/btrfs-fix-log-context-list-corruption-after-rename-exchange-operation.patch [new file with mode: 0644]
queue-4.19/ecryptfs_lookup_interpose-lower_dentry-d_inode-is-not-stable.patch [new file with mode: 0644]
queue-4.19/ecryptfs_lookup_interpose-lower_dentry-d_parent-is-not-stable-either.patch [new file with mode: 0644]
queue-4.19/i2c-acpi-force-bus-speed-to-400khz-if-a-silead-touchscreen-is-present.patch [new file with mode: 0644]
queue-4.19/ib-hfi1-ensure-full-gen3-speed-in-a-gen4-system.patch [new file with mode: 0644]
queue-4.19/ib-hfi1-use-a-common-pad-buffer-for-9b-and-16b-packets.patch [new file with mode: 0644]
queue-4.19/input-ff-memless-kill-timer-in-destroy.patch [new file with mode: 0644]
queue-4.19/input-synaptics-rmi4-clear-irq-enables-for-f54.patch [new file with mode: 0644]
queue-4.19/input-synaptics-rmi4-destroy-f54-poller-workqueue-when-removing.patch [new file with mode: 0644]
queue-4.19/input-synaptics-rmi4-disable-the-relative-position-irq-in-the-f12-driver.patch [new file with mode: 0644]
queue-4.19/input-synaptics-rmi4-do-not-consume-more-data-than-we-have-f11-f12.patch [new file with mode: 0644]
queue-4.19/input-synaptics-rmi4-fix-video-buffer-size.patch [new file with mode: 0644]
queue-4.19/iommu-vt-d-fix-qi_dev_iotlb_pfsid-and-qi_dev_eiotlb_pfsid-macros.patch [new file with mode: 0644]
queue-4.19/mm-hugetlb-switch-to-css_tryget-in-hugetlb_cgroup_charge_cgroup.patch [new file with mode: 0644]
queue-4.19/mm-memcg-switch-to-css_tryget-in-get_mem_cgroup_from_mm.patch [new file with mode: 0644]
queue-4.19/mm-mempolicy-fix-the-wrong-return-value-and-potential-pages-leak-of-mbind.patch [new file with mode: 0644]
queue-4.19/mm-page_io.c-do-not-free-shared-swap-slots.patch [new file with mode: 0644]
queue-4.19/mmc-sdhci-of-at91-fix-quirk2-overwrite.patch [new file with mode: 0644]
queue-4.19/net-ethernet-dwmac-sun8i-use-the-correct-function-in-exit-path.patch [new file with mode: 0644]
queue-4.19/series
queue-4.19/x86-quirks-disable-hpet-on-intel-coffe-lake-platforms.patch [new file with mode: 0644]

diff --git a/queue-4.19/alsa-usb-audio-fix-incorrect-null-check-in-create_yamaha_midi_quirk.patch b/queue-4.19/alsa-usb-audio-fix-incorrect-null-check-in-create_yamaha_midi_quirk.patch
new file mode 100644 (file)
index 0000000..2494cc0
--- /dev/null
@@ -0,0 +1,40 @@
+From cc9dbfa9707868fb0ca864c05e0c42d3f4d15cf2 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Wed, 13 Nov 2019 12:12:59 +0100
+Subject: ALSA: usb-audio: Fix incorrect NULL check in create_yamaha_midi_quirk()
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit cc9dbfa9707868fb0ca864c05e0c42d3f4d15cf2 upstream.
+
+The commit 60849562a5db ("ALSA: usb-audio: Fix possible NULL
+dereference at create_yamaha_midi_quirk()") added NULL checks in
+create_yamaha_midi_quirk(), but there was an overlook.  The code
+allows one of either injd or outjd is NULL, but the second if check
+made returning -ENODEV if any of them is NULL.  Fix it in a proper
+form.
+
+Fixes: 60849562a5db ("ALSA: usb-audio: Fix possible NULL dereference at create_yamaha_midi_quirk()")
+Reported-by: Pavel Machek <pavel@denx.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191113111259.24123-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/quirks.c |    4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -259,8 +259,8 @@ static int create_yamaha_midi_quirk(stru
+                                       NULL, USB_MS_MIDI_OUT_JACK);
+       if (!injd && !outjd)
+               return -ENODEV;
+-      if (!(injd && snd_usb_validate_midi_desc(injd)) ||
+-          !(outjd && snd_usb_validate_midi_desc(outjd)))
++      if ((injd && !snd_usb_validate_midi_desc(injd)) ||
++          (outjd && !snd_usb_validate_midi_desc(outjd)))
+               return -ENODEV;
+       if (injd && (injd->bLength < 5 ||
+                    (injd->bJackType != USB_MS_EMBEDDED &&
diff --git a/queue-4.19/alsa-usb-audio-fix-incorrect-size-check-for-processing-extension-units.patch b/queue-4.19/alsa-usb-audio-fix-incorrect-size-check-for-processing-extension-units.patch
new file mode 100644 (file)
index 0000000..8a6b38d
--- /dev/null
@@ -0,0 +1,41 @@
+From 976a68f06b2ea49e2ab67a5f84919a8b105db8be Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 14 Nov 2019 17:56:12 +0100
+Subject: ALSA: usb-audio: Fix incorrect size check for processing/extension units
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 976a68f06b2ea49e2ab67a5f84919a8b105db8be upstream.
+
+The recently introduced unit descriptor validation had some bug for
+processing and extension units, it counts a bControlSize byte twice so
+it expected a bigger size than it should have been.  This seems
+resulting in a probe error on a few devices.
+
+Fix the calculation for proper checks of PU and EU.
+
+Fixes: 57f8770620e9 ("ALSA: usb-audio: More validations of descriptor units")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20191114165613.7422-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ sound/usb/validate.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/sound/usb/validate.c
++++ b/sound/usb/validate.c
+@@ -81,9 +81,9 @@ static bool validate_processing_unit(con
+       switch (v->protocol) {
+       case UAC_VERSION_1:
+       default:
+-              /* bNrChannels, wChannelConfig, iChannelNames, bControlSize */
+-              len += 1 + 2 + 1 + 1;
+-              if (d->bLength < len) /* bControlSize */
++              /* bNrChannels, wChannelConfig, iChannelNames */
++              len += 1 + 2 + 1;
++              if (d->bLength < len + 1) /* bControlSize */
+                       return false;
+               m = hdr[len];
+               len += 1 + m + 1; /* bControlSize, bmControls, iProcessing */
diff --git a/queue-4.19/alsa-usb-audio-fix-missing-error-check-at-mixer-resolution-test.patch b/queue-4.19/alsa-usb-audio-fix-missing-error-check-at-mixer-resolution-test.patch
new file mode 100644 (file)
index 0000000..3f6e605
--- /dev/null
@@ -0,0 +1,46 @@
+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
+@@ -1244,7 +1244,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)
+@@ -1264,6 +1265,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;
+       }
diff --git a/queue-4.19/alsa-usb-audio-not-submit-urb-for-stopped-endpoint.patch b/queue-4.19/alsa-usb-audio-not-submit-urb-for-stopped-endpoint.patch
new file mode 100644 (file)
index 0000000..b6b91c2
--- /dev/null
@@ -0,0 +1,44 @@
+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
+@@ -401,6 +401,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 */
diff --git a/queue-4.19/btrfs-fix-log-context-list-corruption-after-rename-exchange-operation.patch b/queue-4.19/btrfs-fix-log-context-list-corruption-after-rename-exchange-operation.patch
new file mode 100644 (file)
index 0000000..86ec105
--- /dev/null
@@ -0,0 +1,119 @@
+From e6c617102c7e4ac1398cb0b98ff1f0727755b520 Mon Sep 17 00:00:00 2001
+From: Filipe Manana <fdmanana@suse.com>
+Date: Fri, 8 Nov 2019 16:11:56 +0000
+Subject: Btrfs: fix log context list corruption after rename exchange operation
+
+From: Filipe Manana <fdmanana@suse.com>
+
+commit e6c617102c7e4ac1398cb0b98ff1f0727755b520 upstream.
+
+During rename exchange we might have successfully log the new name in the
+source root's log tree, in which case we leave our log context (allocated
+on stack) in the root's list of log contextes. However we might fail to
+log the new name in the destination root, in which case we fallback to
+a transaction commit later and never sync the log of the source root,
+which causes the source root log context to remain in the list of log
+contextes. This later causes invalid memory accesses because the context
+was allocated on stack and after rename exchange finishes the stack gets
+reused and overwritten for other purposes.
+
+The kernel's linked list corruption detector (CONFIG_DEBUG_LIST=y) can
+detect this and report something like the following:
+
+  [  691.489929] ------------[ cut here ]------------
+  [  691.489947] list_add corruption. prev->next should be next (ffff88819c944530), but was ffff8881c23f7be4. (prev=ffff8881c23f7a38).
+  [  691.489967] WARNING: CPU: 2 PID: 28933 at lib/list_debug.c:28 __list_add_valid+0x95/0xe0
+  (...)
+  [  691.489998] CPU: 2 PID: 28933 Comm: fsstress Not tainted 5.4.0-rc6-btrfs-next-62 #1
+  [  691.490001] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014
+  [  691.490003] RIP: 0010:__list_add_valid+0x95/0xe0
+  (...)
+  [  691.490007] RSP: 0018:ffff8881f0b3faf8 EFLAGS: 00010282
+  [  691.490010] RAX: 0000000000000000 RBX: ffff88819c944530 RCX: 0000000000000000
+  [  691.490011] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffa2c497e0
+  [  691.490013] RBP: ffff8881f0b3fe68 R08: ffffed103eaa4115 R09: ffffed103eaa4114
+  [  691.490015] R10: ffff88819c944000 R11: ffffed103eaa4115 R12: 7fffffffffffffff
+  [  691.490016] R13: ffff8881b4035610 R14: ffff8881e7b84728 R15: 1ffff1103e167f7b
+  [  691.490019] FS:  00007f4b25ea2e80(0000) GS:ffff8881f5500000(0000) knlGS:0000000000000000
+  [  691.490021] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+  [  691.490022] CR2: 00007fffbb2d4eec CR3: 00000001f2a4a004 CR4: 00000000003606e0
+  [  691.490025] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+  [  691.490027] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+  [  691.490029] Call Trace:
+  [  691.490058]  btrfs_log_inode_parent+0x667/0x2730 [btrfs]
+  [  691.490083]  ? join_transaction+0x24a/0xce0 [btrfs]
+  [  691.490107]  ? btrfs_end_log_trans+0x80/0x80 [btrfs]
+  [  691.490111]  ? dget_parent+0xb8/0x460
+  [  691.490116]  ? lock_downgrade+0x6b0/0x6b0
+  [  691.490121]  ? rwlock_bug.part.0+0x90/0x90
+  [  691.490127]  ? do_raw_spin_unlock+0x142/0x220
+  [  691.490151]  btrfs_log_dentry_safe+0x65/0x90 [btrfs]
+  [  691.490172]  btrfs_sync_file+0x9f1/0xc00 [btrfs]
+  [  691.490195]  ? btrfs_file_write_iter+0x1800/0x1800 [btrfs]
+  [  691.490198]  ? rcu_read_lock_any_held.part.11+0x20/0x20
+  [  691.490204]  ? __do_sys_newstat+0x88/0xd0
+  [  691.490207]  ? cp_new_stat+0x5d0/0x5d0
+  [  691.490218]  ? do_fsync+0x38/0x60
+  [  691.490220]  do_fsync+0x38/0x60
+  [  691.490224]  __x64_sys_fdatasync+0x32/0x40
+  [  691.490228]  do_syscall_64+0x9f/0x540
+  [  691.490233]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
+  [  691.490235] RIP: 0033:0x7f4b253ad5f0
+  (...)
+  [  691.490239] RSP: 002b:00007fffbb2d6078 EFLAGS: 00000246 ORIG_RAX: 000000000000004b
+  [  691.490242] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f4b253ad5f0
+  [  691.490244] RDX: 00007fffbb2d5fe0 RSI: 00007fffbb2d5fe0 RDI: 0000000000000003
+  [  691.490245] RBP: 000000000000000d R08: 0000000000000001 R09: 00007fffbb2d608c
+  [  691.490247] R10: 00000000000002e8 R11: 0000000000000246 R12: 00000000000001f4
+  [  691.490248] R13: 0000000051eb851f R14: 00007fffbb2d6120 R15: 00005635a498bda0
+
+This started happening recently when running some test cases from fstests
+like btrfs/004 for example, because support for rename exchange was added
+last week to fsstress from fstests.
+
+So fix this by deleting the log context for the source root from the list
+if we have logged the new name in the source root.
+
+Reported-by: Su Yue <Damenly_Su@gmx.com>
+Fixes: d4682ba03ef618 ("Btrfs: sync log after logging new name")
+CC: stable@vger.kernel.org # 4.19+
+Tested-by: Su Yue <Damenly_Su@gmx.com>
+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/inode.c |   15 +++++++++++++++
+ 1 file changed, 15 insertions(+)
+
+--- a/fs/btrfs/inode.c
++++ b/fs/btrfs/inode.c
+@@ -9700,6 +9700,18 @@ out_fail:
+                       commit_transaction = true;
+       }
+       if (commit_transaction) {
++              /*
++               * We may have set commit_transaction when logging the new name
++               * in the destination root, in which case we left the source
++               * root context in the list of log contextes. So make sure we
++               * remove it to avoid invalid memory accesses, since the context
++               * was allocated in our stack frame.
++               */
++              if (sync_log_root) {
++                      mutex_lock(&root->log_mutex);
++                      list_del_init(&ctx_root.list);
++                      mutex_unlock(&root->log_mutex);
++              }
+               ret = btrfs_commit_transaction(trans);
+       } else {
+               int ret2;
+@@ -9713,6 +9725,9 @@ out_notrans:
+       if (old_ino == BTRFS_FIRST_FREE_OBJECTID)
+               up_read(&fs_info->subvol_sem);
++      ASSERT(list_empty(&ctx_root.list));
++      ASSERT(list_empty(&ctx_dest.list));
++
+       return ret;
+ }
diff --git a/queue-4.19/ecryptfs_lookup_interpose-lower_dentry-d_inode-is-not-stable.patch b/queue-4.19/ecryptfs_lookup_interpose-lower_dentry-d_inode-is-not-stable.patch
new file mode 100644 (file)
index 0000000..1fbb923
--- /dev/null
@@ -0,0 +1,51 @@
+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
+@@ -325,7 +325,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;
+@@ -345,7 +345,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;
diff --git a/queue-4.19/ecryptfs_lookup_interpose-lower_dentry-d_parent-is-not-stable-either.patch b/queue-4.19/ecryptfs_lookup_interpose-lower_dentry-d_parent-is-not-stable-either.patch
new file mode 100644 (file)
index 0000000..d4b4a9d
--- /dev/null
@@ -0,0 +1,59 @@
+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
+@@ -325,9 +325,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);
+@@ -336,13 +336,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;
+       /*
diff --git a/queue-4.19/i2c-acpi-force-bus-speed-to-400khz-if-a-silead-touchscreen-is-present.patch b/queue-4.19/i2c-acpi-force-bus-speed-to-400khz-if-a-silead-touchscreen-is-present.patch
new file mode 100644 (file)
index 0000000..d2af16a
--- /dev/null
@@ -0,0 +1,98 @@
+From 7574c0db2e68c4d0bae9d415a683bdd8b2a761e9 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Wed, 13 Nov 2019 19:29:38 +0100
+Subject: i2c: acpi: Force bus speed to 400KHz if a Silead touchscreen is present
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 7574c0db2e68c4d0bae9d415a683bdd8b2a761e9 upstream.
+
+Many cheap devices use Silead touchscreen controllers. Testing has shown
+repeatedly that these touchscreen controllers work fine at 400KHz, but for
+unknown reasons do not work properly at 100KHz. This has been seen on
+both ARM and x86 devices using totally different i2c controllers.
+
+On some devices the ACPI tables list another device at the same I2C-bus
+as only being capable of 100KHz, testing has shown that these other
+devices work fine at 400KHz (as can be expected of any recent I2C hw).
+
+This commit makes i2c_acpi_find_bus_speed() always return 400KHz if a
+Silead touchscreen controller is present, fixing the touchscreen not
+working on devices which ACPI tables' wrongly list another device on the
+same bus as only being capable of 100KHz.
+
+Specifically this fixes the touchscreen on the Jumper EZpad 6 m4 not
+working.
+
+Reported-by: youling 257 <youling257@gmail.com>
+Tested-by: youling 257 <youling257@gmail.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+[wsa: rewording warning a little]
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Cc: stable@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/i2c-core-acpi.c |   28 +++++++++++++++++++++++++++-
+ 1 file changed, 27 insertions(+), 1 deletion(-)
+
+--- a/drivers/i2c/i2c-core-acpi.c
++++ b/drivers/i2c/i2c-core-acpi.c
+@@ -43,6 +43,7 @@ struct i2c_acpi_lookup {
+       int index;
+       u32 speed;
+       u32 min_speed;
++      u32 force_speed;
+ };
+ static int i2c_acpi_fill_info(struct acpi_resource *ares, void *data)
+@@ -240,6 +241,19 @@ i2c_acpi_match_device(const struct acpi_
+       return acpi_match_device(matches, &client->dev);
+ }
++static const struct acpi_device_id i2c_acpi_force_400khz_device_ids[] = {
++      /*
++       * These Silead touchscreen controllers only work at 400KHz, for
++       * some reason they do not work at 100KHz. On some devices the ACPI
++       * tables list another device at their bus as only being capable
++       * of 100KHz, testing has shown that these other devices work fine
++       * at 400KHz (as can be expected of any recent i2c hw) so we force
++       * the speed of the bus to 400 KHz if a Silead device is present.
++       */
++      { "MSSL1680", 0 },
++      {}
++};
++
+ static acpi_status i2c_acpi_lookup_speed(acpi_handle handle, u32 level,
+                                          void *data, void **return_value)
+ {
+@@ -258,6 +272,9 @@ static acpi_status i2c_acpi_lookup_speed
+       if (lookup->speed <= lookup->min_speed)
+               lookup->min_speed = lookup->speed;
++      if (acpi_match_device_ids(adev, i2c_acpi_force_400khz_device_ids) == 0)
++              lookup->force_speed = 400000;
++
+       return AE_OK;
+ }
+@@ -295,7 +312,16 @@ u32 i2c_acpi_find_bus_speed(struct devic
+               return 0;
+       }
+-      return lookup.min_speed != UINT_MAX ? lookup.min_speed : 0;
++      if (lookup.force_speed) {
++              if (lookup.force_speed != lookup.min_speed)
++                      dev_warn(dev, FW_BUG "DSDT uses known not-working I2C bus speed %d, forcing it to %d\n",
++                               lookup.min_speed, lookup.force_speed);
++              return lookup.force_speed;
++      } else if (lookup.min_speed != UINT_MAX) {
++              return lookup.min_speed;
++      } else {
++              return 0;
++      }
+ }
+ EXPORT_SYMBOL_GPL(i2c_acpi_find_bus_speed);
diff --git a/queue-4.19/ib-hfi1-ensure-full-gen3-speed-in-a-gen4-system.patch b/queue-4.19/ib-hfi1-ensure-full-gen3-speed-in-a-gen4-system.patch
new file mode 100644 (file)
index 0000000..ebdae22
--- /dev/null
@@ -0,0 +1,47 @@
+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
+@@ -331,7 +331,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;
+       }
diff --git a/queue-4.19/ib-hfi1-use-a-common-pad-buffer-for-9b-and-16b-packets.patch b/queue-4.19/ib-hfi1-use-a-common-pad-buffer-for-9b-and-16b-packets.patch
new file mode 100644 (file)
index 0000000..de94420
--- /dev/null
@@ -0,0 +1,91 @@
+From 22bb13653410424d9fce8d447506a41f8292f22f Mon Sep 17 00:00:00 2001
+From: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Date: Fri, 4 Oct 2019 16:49:34 -0400
+Subject: IB/hfi1: Use a common pad buffer for 9B and 16B packets
+
+From: Mike Marciniszyn <mike.marciniszyn@intel.com>
+
+commit 22bb13653410424d9fce8d447506a41f8292f22f upstream.
+
+There is no reason for a different pad buffer for the two
+packet types.
+
+Expand the current buffer allocation to allow for both
+packet types.
+
+Fixes: f8195f3b14a0 ("IB/hfi1: Eliminate allocation while atomic")
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Kaike Wan <kaike.wan@intel.com>
+Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Link: https://lore.kernel.org/r/20191004204934.26838.13099.stgit@awfm-01.aw.intel.com
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/hfi1/sdma.c  |    5 +++--
+ drivers/infiniband/hw/hfi1/verbs.c |   10 ++++------
+ 2 files changed, 7 insertions(+), 8 deletions(-)
+
+--- a/drivers/infiniband/hw/hfi1/sdma.c
++++ b/drivers/infiniband/hw/hfi1/sdma.c
+@@ -65,6 +65,7 @@
+ #define SDMA_DESCQ_CNT 2048
+ #define SDMA_DESC_INTR 64
+ #define INVALID_TAIL 0xffff
++#define SDMA_PAD max_t(size_t, MAX_16B_PADDING, sizeof(u32))
+ static uint sdma_descq_cnt = SDMA_DESCQ_CNT;
+ module_param(sdma_descq_cnt, uint, S_IRUGO);
+@@ -1280,7 +1281,7 @@ void sdma_clean(struct hfi1_devdata *dd,
+       struct sdma_engine *sde;
+       if (dd->sdma_pad_dma) {
+-              dma_free_coherent(&dd->pcidev->dev, 4,
++              dma_free_coherent(&dd->pcidev->dev, SDMA_PAD,
+                                 (void *)dd->sdma_pad_dma,
+                                 dd->sdma_pad_phys);
+               dd->sdma_pad_dma = NULL;
+@@ -1481,7 +1482,7 @@ int sdma_init(struct hfi1_devdata *dd, u
+       /* Allocate memory for pad */
+       dd->sdma_pad_dma = dma_zalloc_coherent(
+               &dd->pcidev->dev,
+-              sizeof(u32),
++              SDMA_PAD,
+               &dd->sdma_pad_phys,
+               GFP_KERNEL
+       );
+--- a/drivers/infiniband/hw/hfi1/verbs.c
++++ b/drivers/infiniband/hw/hfi1/verbs.c
+@@ -149,9 +149,6 @@ static int pio_wait(struct rvt_qp *qp,
+ /* Length of buffer to create verbs txreq cache name */
+ #define TXREQ_NAME_LEN 24
+-/* 16B trailing buffer */
+-static const u8 trail_buf[MAX_16B_PADDING];
+-
+ static uint wss_threshold;
+ module_param(wss_threshold, uint, S_IRUGO);
+ MODULE_PARM_DESC(wss_threshold, "Percentage (1-100) of LLC to use as a threshold for a cacheless copy");
+@@ -893,8 +890,8 @@ static int build_verbs_tx_desc(
+       /* add icrc, lt byte, and padding to flit */
+       if (extra_bytes)
+-              ret = sdma_txadd_kvaddr(sde->dd, &tx->txreq,
+-                                      (void *)trail_buf, extra_bytes);
++              ret = sdma_txadd_daddr(sde->dd, &tx->txreq,
++                                     sde->dd->sdma_pad_phys, extra_bytes);
+ bail_txadd:
+       return ret;
+@@ -1151,7 +1148,8 @@ int hfi1_verbs_send_pio(struct rvt_qp *q
+               }
+               /* add icrc, lt byte, and padding to flit */
+               if (extra_bytes)
+-                      seg_pio_copy_mid(pbuf, trail_buf, extra_bytes);
++                      seg_pio_copy_mid(pbuf, ppd->dd->sdma_pad_dma,
++                                       extra_bytes);
+               seg_pio_copy_end(pbuf);
+       }
diff --git a/queue-4.19/input-ff-memless-kill-timer-in-destroy.patch b/queue-4.19/input-ff-memless-kill-timer-in-destroy.patch
new file mode 100644 (file)
index 0000000..f909816
--- /dev/null
@@ -0,0 +1,40 @@
+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);
+ }
diff --git a/queue-4.19/input-synaptics-rmi4-clear-irq-enables-for-f54.patch b/queue-4.19/input-synaptics-rmi4-clear-irq-enables-for-f54.patch
new file mode 100644 (file)
index 0000000..3ec5673
--- /dev/null
@@ -0,0 +1,34 @@
+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
+@@ -614,7 +614,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;
+ }
diff --git a/queue-4.19/input-synaptics-rmi4-destroy-f54-poller-workqueue-when-removing.patch b/queue-4.19/input-synaptics-rmi4-destroy-f54-poller-workqueue-when-removing.patch
new file mode 100644 (file)
index 0000000..02f8a1e
--- /dev/null
@@ -0,0 +1,35 @@
+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
+@@ -742,6 +742,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 = {
diff --git a/queue-4.19/input-synaptics-rmi4-disable-the-relative-position-irq-in-the-f12-driver.patch b/queue-4.19/input-synaptics-rmi4-disable-the-relative-position-irq-in-the-f12-driver.patch
new file mode 100644 (file)
index 0000000..a43d826
--- /dev/null
@@ -0,0 +1,106 @@
+From f6aabe1ff1d9d7bad0879253011216438bdb2530 Mon Sep 17 00:00:00 2001
+From: Andrew Duggan <aduggan@synaptics.com>
+Date: Mon, 4 Nov 2019 16:06:44 -0800
+Subject: Input: synaptics-rmi4 - disable the relative position IRQ in the F12 driver
+
+From: Andrew Duggan <aduggan@synaptics.com>
+
+commit f6aabe1ff1d9d7bad0879253011216438bdb2530 upstream.
+
+This patch fixes an issue seen on HID touchpads which report finger
+positions using RMI4 Function 12. The issue manifests itself as
+spurious button presses as described in:
+https://www.spinics.net/lists/linux-input/msg58618.html
+
+Commit 24d28e4f1271 ("Input: synaptics-rmi4 - convert irq distribution
+to irq_domain") switched the RMI4 driver to using an irq_domain to handle
+RMI4 function interrupts. Functions with more then one interrupt now have
+each interrupt mapped to their own IRQ and IRQ handler. The result of
+this change is that the F12 IRQ handler was now getting called twice. Once
+for the absolute data interrupt and once for the relative data interrupt.
+For HID devices, calling rmi_f12_attention() a second time causes the
+attn_data data pointer and size to be set incorrectly. When the touchpad
+button is pressed, F30 will generate an interrupt and attempt to read the
+F30 data from the invalid attn_data data pointer and report incorrect
+button events.
+
+This patch disables the F12 relative interrupt which prevents
+rmi_f12_attention() from being called twice.
+
+Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
+Reported-by: Simon Wood <simon@mungewell.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191025002527.3189-2-aduggan@synaptics.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/rmi4/rmi_f12.c |   28 ++++++++++++++++++++++++++--
+ 1 file changed, 26 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/rmi4/rmi_f12.c
++++ b/drivers/input/rmi4/rmi_f12.c
+@@ -58,6 +58,9 @@ struct f12_data {
+       const struct rmi_register_desc_item *data15;
+       u16 data15_offset;
++
++      unsigned long *abs_mask;
++      unsigned long *rel_mask;
+ };
+ static int rmi_f12_read_sensor_tuning(struct f12_data *f12)
+@@ -296,9 +299,18 @@ static int rmi_f12_write_control_regs(st
+ static int rmi_f12_config(struct rmi_function *fn)
+ {
+       struct rmi_driver *drv = fn->rmi_dev->driver;
++      struct f12_data *f12 = dev_get_drvdata(&fn->dev);
++      struct rmi_2d_sensor *sensor;
+       int ret;
+-      drv->set_irq_bits(fn->rmi_dev, fn->irq_mask);
++      sensor = &f12->sensor;
++
++      if (!sensor->report_abs)
++              drv->clear_irq_bits(fn->rmi_dev, f12->abs_mask);
++      else
++              drv->set_irq_bits(fn->rmi_dev, f12->abs_mask);
++
++      drv->clear_irq_bits(fn->rmi_dev, f12->rel_mask);
+       ret = rmi_f12_write_control_regs(fn);
+       if (ret)
+@@ -320,9 +332,12 @@ static int rmi_f12_probe(struct rmi_func
+       struct rmi_device_platform_data *pdata = rmi_get_platform_data(rmi_dev);
+       struct rmi_driver_data *drvdata = dev_get_drvdata(&rmi_dev->dev);
+       u16 data_offset = 0;
++      int mask_size;
+       rmi_dbg(RMI_DEBUG_FN, &fn->dev, "%s\n", __func__);
++      mask_size = BITS_TO_LONGS(drvdata->irq_count) * sizeof(unsigned long);
++
+       ret = rmi_read(fn->rmi_dev, query_addr, &buf);
+       if (ret < 0) {
+               dev_err(&fn->dev, "Failed to read general info register: %d\n",
+@@ -337,10 +352,19 @@ static int rmi_f12_probe(struct rmi_func
+               return -ENODEV;
+       }
+-      f12 = devm_kzalloc(&fn->dev, sizeof(struct f12_data), GFP_KERNEL);
++      f12 = devm_kzalloc(&fn->dev, sizeof(struct f12_data) + mask_size * 2,
++                      GFP_KERNEL);
+       if (!f12)
+               return -ENOMEM;
++      f12->abs_mask = (unsigned long *)((char *)f12
++                      + sizeof(struct f12_data));
++      f12->rel_mask = (unsigned long *)((char *)f12
++                      + sizeof(struct f12_data) + mask_size);
++
++      set_bit(fn->irq_pos, f12->abs_mask);
++      set_bit(fn->irq_pos + 1, f12->rel_mask);
++
+       f12->has_dribble = !!(buf & BIT(3));
+       if (fn->dev.of_node) {
diff --git a/queue-4.19/input-synaptics-rmi4-do-not-consume-more-data-than-we-have-f11-f12.patch b/queue-4.19/input-synaptics-rmi4-do-not-consume-more-data-than-we-have-f11-f12.patch
new file mode 100644 (file)
index 0000000..72b1d6a
--- /dev/null
@@ -0,0 +1,53 @@
+From 5d40d95e7e64756cc30606c2ba169271704d47cb Mon Sep 17 00:00:00 2001
+From: Andrew Duggan <aduggan@synaptics.com>
+Date: Mon, 4 Nov 2019 16:07:30 -0800
+Subject: Input: synaptics-rmi4 - do not consume more data than we have (F11, F12)
+
+From: Andrew Duggan <aduggan@synaptics.com>
+
+commit 5d40d95e7e64756cc30606c2ba169271704d47cb upstream.
+
+Currently, rmi_f11_attention() and rmi_f12_attention() functions update
+the attn_data data pointer and size based on the size of the expected
+size of the attention data. However, if the actual valid data in the
+attn buffer is less then the expected value then the updated data
+pointer will point to memory beyond the end of the attn buffer. Using
+the calculated valid_bytes instead will prevent this from happening.
+
+Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191025002527.3189-3-aduggan@synaptics.com
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/rmi4/rmi_f11.c |    4 ++--
+ drivers/input/rmi4/rmi_f12.c |    4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/input/rmi4/rmi_f11.c
++++ b/drivers/input/rmi4/rmi_f11.c
+@@ -1287,8 +1287,8 @@ static irqreturn_t rmi_f11_attention(int
+                       valid_bytes = f11->sensor.attn_size;
+               memcpy(f11->sensor.data_pkt, drvdata->attn_data.data,
+                       valid_bytes);
+-              drvdata->attn_data.data += f11->sensor.attn_size;
+-              drvdata->attn_data.size -= f11->sensor.attn_size;
++              drvdata->attn_data.data += valid_bytes;
++              drvdata->attn_data.size -= valid_bytes;
+       } else {
+               error = rmi_read_block(rmi_dev,
+                               data_base_addr, f11->sensor.data_pkt,
+--- a/drivers/input/rmi4/rmi_f12.c
++++ b/drivers/input/rmi4/rmi_f12.c
+@@ -217,8 +217,8 @@ static irqreturn_t rmi_f12_attention(int
+                       valid_bytes = sensor->attn_size;
+               memcpy(sensor->data_pkt, drvdata->attn_data.data,
+                       valid_bytes);
+-              drvdata->attn_data.data += sensor->attn_size;
+-              drvdata->attn_data.size -= sensor->attn_size;
++              drvdata->attn_data.data += valid_bytes;
++              drvdata->attn_data.size -= valid_bytes;
+       } else {
+               retval = rmi_read_block(rmi_dev, f12->data_addr,
+                                       sensor->data_pkt, sensor->pkt_size);
diff --git a/queue-4.19/input-synaptics-rmi4-fix-video-buffer-size.patch b/queue-4.19/input-synaptics-rmi4-fix-video-buffer-size.patch
new file mode 100644 (file)
index 0000000..042d365
--- /dev/null
@@ -0,0 +1,36 @@
+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
+@@ -362,7 +362,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,
diff --git a/queue-4.19/iommu-vt-d-fix-qi_dev_iotlb_pfsid-and-qi_dev_eiotlb_pfsid-macros.patch b/queue-4.19/iommu-vt-d-fix-qi_dev_iotlb_pfsid-and-qi_dev_eiotlb_pfsid-macros.patch
new file mode 100644 (file)
index 0000000..2bb15bd
--- /dev/null
@@ -0,0 +1,50 @@
+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
+@@ -286,7 +286,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
+@@ -311,7 +312,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)
diff --git a/queue-4.19/mm-hugetlb-switch-to-css_tryget-in-hugetlb_cgroup_charge_cgroup.patch b/queue-4.19/mm-hugetlb-switch-to-css_tryget-in-hugetlb_cgroup_charge_cgroup.patch
new file mode 100644 (file)
index 0000000..f303af7
--- /dev/null
@@ -0,0 +1,49 @@
+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;
+       }
diff --git a/queue-4.19/mm-memcg-switch-to-css_tryget-in-get_mem_cgroup_from_mm.patch b/queue-4.19/mm-memcg-switch-to-css_tryget-in-get_mem_cgroup_from_mm.patch
new file mode 100644 (file)
index 0000000..26e8e20
--- /dev/null
@@ -0,0 +1,80 @@
+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
+@@ -851,7 +851,7 @@ struct mem_cgroup *get_mem_cgroup_from_m
+                       if (unlikely(!memcg))
+                               memcg = root_mem_cgroup;
+               }
+-      } while (!css_tryget_online(&memcg->css));
++      } while (!css_tryget(&memcg->css));
+       rcu_read_unlock();
+       return memcg;
+ }
diff --git a/queue-4.19/mm-mempolicy-fix-the-wrong-return-value-and-potential-pages-leak-of-mbind.patch b/queue-4.19/mm-mempolicy-fix-the-wrong-return-value-and-potential-pages-leak-of-mbind.patch
new file mode 100644 (file)
index 0000000..5b33817
--- /dev/null
@@ -0,0 +1,78 @@
+From a85dfc305a21acfc48fa28a0fa0a0cb6ad496120 Mon Sep 17 00:00:00 2001
+From: Yang Shi <yang.shi@linux.alibaba.com>
+Date: Fri, 15 Nov 2019 17:34:33 -0800
+Subject: mm: mempolicy: fix the wrong return value and potential pages leak of mbind
+
+From: Yang Shi <yang.shi@linux.alibaba.com>
+
+commit a85dfc305a21acfc48fa28a0fa0a0cb6ad496120 upstream.
+
+Commit d883544515aa ("mm: mempolicy: make the behavior consistent when
+MPOL_MF_MOVE* and MPOL_MF_STRICT were specified") fixed the return value
+of mbind() for a couple of corner cases.  But, it altered the errno for
+some other cases, for example, mbind() should return -EFAULT when part
+or all of the memory range specified by nodemask and maxnode points
+outside your accessible address space, or there was an unmapped hole in
+the specified memory range specified by addr and len.
+
+Fix this by preserving the errno returned by queue_pages_range().  And,
+the pagelist may be not empty even though queue_pages_range() returns
+error, put the pages back to LRU since mbind_range() is not called to
+really apply the policy so those pages should not be migrated, this is
+also the old behavior before the problematic commit.
+
+Link: http://lkml.kernel.org/r/1572454731-3925-1-git-send-email-yang.shi@linux.alibaba.com
+Fixes: d883544515aa ("mm: mempolicy: make the behavior consistent when MPOL_MF_MOVE* and MPOL_MF_STRICT were specified")
+Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
+Reported-by: Li Xinhai <lixinhai.lxh@gmail.com>
+Reviewed-by: Li Xinhai <lixinhai.lxh@gmail.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Mel Gorman <mgorman@techsingularity.net>
+Cc: <stable@vger.kernel.org>   [4.19 and 5.2+]
+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/mempolicy.c |   14 +++++++++-----
+ 1 file changed, 9 insertions(+), 5 deletions(-)
+
+--- a/mm/mempolicy.c
++++ b/mm/mempolicy.c
+@@ -666,7 +666,9 @@ static int queue_pages_test_walk(unsigne
+  * 1 - there is unmovable page, but MPOL_MF_MOVE* & MPOL_MF_STRICT were
+  *     specified.
+  * 0 - queue pages successfully or no misplaced page.
+- * -EIO - there is misplaced page and only MPOL_MF_STRICT was specified.
++ * errno - i.e. misplaced pages with MPOL_MF_STRICT specified (-EIO) or
++ *         memory range specified by nodemask and maxnode points outside
++ *         your accessible address space (-EFAULT)
+  */
+ static int
+ queue_pages_range(struct mm_struct *mm, unsigned long start, unsigned long end,
+@@ -1273,7 +1275,7 @@ static long do_mbind(unsigned long start
+                         flags | MPOL_MF_INVERT, &pagelist);
+       if (ret < 0) {
+-              err = -EIO;
++              err = ret;
+               goto up_out;
+       }
+@@ -1292,10 +1294,12 @@ static long do_mbind(unsigned long start
+               if ((ret > 0) || (nr_failed && (flags & MPOL_MF_STRICT)))
+                       err = -EIO;
+-      } else
+-              putback_movable_pages(&pagelist);
+-
++      } else {
+ up_out:
++              if (!list_empty(&pagelist))
++                      putback_movable_pages(&pagelist);
++      }
++
+       up_write(&mm->mmap_sem);
+ mpol_out:
+       mpol_put(new);
diff --git a/queue-4.19/mm-page_io.c-do-not-free-shared-swap-slots.patch b/queue-4.19/mm-page_io.c-do-not-free-shared-swap-slots.patch
new file mode 100644 (file)
index 0000000..08a6f75
--- /dev/null
@@ -0,0 +1,75 @@
+From 5df373e95689b9519b8557da7c5bd0db0856d776 Mon Sep 17 00:00:00 2001
+From: Vinayak Menon <vinmenon@codeaurora.org>
+Date: Fri, 15 Nov 2019 17:35:00 -0800
+Subject: mm/page_io.c: do not free shared swap slots
+
+From: Vinayak Menon <vinmenon@codeaurora.org>
+
+commit 5df373e95689b9519b8557da7c5bd0db0856d776 upstream.
+
+The following race is observed due to which a processes faulting on a
+swap entry, finds the page neither in swapcache nor swap.  This causes
+zram to give a zero filled page that gets mapped to the process,
+resulting in a user space crash later.
+
+Consider parent and child processes Pa and Pb sharing the same swap slot
+with swap_count 2.  Swap is on zram with SWP_SYNCHRONOUS_IO set.
+Virtual address 'VA' of Pa and Pb points to the shared swap entry.
+
+Pa                                       Pb
+
+fault on VA                              fault on VA
+do_swap_page                             do_swap_page
+lookup_swap_cache fails                  lookup_swap_cache fails
+                                         Pb scheduled out
+swapin_readahead (deletes zram entry)
+swap_free (makes swap_count 1)
+                                         Pb scheduled in
+                                         swap_readpage (swap_count == 1)
+                                         Takes SWP_SYNCHRONOUS_IO path
+                                         zram enrty absent
+                                         zram gives a zero filled page
+
+Fix this by making sure that swap slot is freed only when swap count
+drops down to one.
+
+Link: http://lkml.kernel.org/r/1571743294-14285-1-git-send-email-vinmenon@codeaurora.org
+Fixes: aa8d22a11da9 ("mm: swap: SWP_SYNCHRONOUS_IO: skip swapcache only if swapped page has no other reference")
+Signed-off-by: Vinayak Menon <vinmenon@codeaurora.org>
+Suggested-by: Minchan Kim <minchan@google.com>
+Acked-by: Minchan Kim <minchan@kernel.org>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: Hugh Dickins <hughd@google.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/page_io.c |    6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/mm/page_io.c
++++ b/mm/page_io.c
+@@ -76,6 +76,7 @@ static void swap_slot_free_notify(struct
+ {
+       struct swap_info_struct *sis;
+       struct gendisk *disk;
++      swp_entry_t entry;
+       /*
+        * There is no guarantee that the page is in swap cache - the software
+@@ -107,11 +108,10 @@ static void swap_slot_free_notify(struct
+        * we again wish to reclaim it.
+        */
+       disk = sis->bdev->bd_disk;
+-      if (disk->fops->swap_slot_free_notify) {
+-              swp_entry_t entry;
++      entry.val = page_private(page);
++      if (disk->fops->swap_slot_free_notify && __swap_count(entry) == 1) {
+               unsigned long offset;
+-              entry.val = page_private(page);
+               offset = swp_offset(entry);
+               SetPageDirty(page);
diff --git a/queue-4.19/mmc-sdhci-of-at91-fix-quirk2-overwrite.patch b/queue-4.19/mmc-sdhci-of-at91-fix-quirk2-overwrite.patch
new file mode 100644 (file)
index 0000000..5d98eb8
--- /dev/null
@@ -0,0 +1,35 @@
+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
+@@ -366,7 +366,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)
diff --git a/queue-4.19/net-ethernet-dwmac-sun8i-use-the-correct-function-in-exit-path.patch b/queue-4.19/net-ethernet-dwmac-sun8i-use-the-correct-function-in-exit-path.patch
new file mode 100644 (file)
index 0000000..8c1449a
--- /dev/null
@@ -0,0 +1,39 @@
+From 40a1dcee2d1846a24619fe9ca45c661ca0db7dda Mon Sep 17 00:00:00 2001
+From: Corentin Labbe <clabbe@baylibre.com>
+Date: Sun, 10 Nov 2019 11:30:48 +0000
+Subject: net: ethernet: dwmac-sun8i: Use the correct function in exit path
+
+From: Corentin Labbe <clabbe@baylibre.com>
+
+commit 40a1dcee2d1846a24619fe9ca45c661ca0db7dda upstream.
+
+When PHY is not powered, the probe function fail and some resource are
+still unallocated.
+Furthermore some BUG happens:
+dwmac-sun8i 5020000.ethernet: EMAC reset timeout
+------------[ cut here ]------------
+kernel BUG at /linux-next/net/core/dev.c:9844!
+
+So let's use the right function (stmmac_pltfr_remove) in the error path.
+
+Fixes: 9f93ac8d4085 ("net-next: stmmac: Add dwmac-sun8i")
+Cc: <stable@vger.kernel.org> # v4.15+
+Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c |    2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+@@ -1199,7 +1199,7 @@ static int sun8i_dwmac_probe(struct plat
+ dwmac_mux:
+       sun8i_dwmac_unset_syscon(gmac);
+ dwmac_exit:
+-      sun8i_dwmac_exit(pdev, plat_dat->bsp_priv);
++      stmmac_pltfr_remove(pdev);
+ return ret;
+ }
index d35ef123cc811edbda72c38016122b538209ebb2..3ab1699fd5a6ee585e7257b3e3ff07e9f3a956b4 100644 (file)
@@ -7,3 +7,27 @@ net-gemini-add-missed-free_netdev.patch
 net-usb-qmi_wwan-add-support-for-foxconn-t77w968-lte-modules.patch
 slip-fix-memory-leak-in-slip_open-error-path.patch
 devlink-disallow-reload-operation-during-device-cleanup.patch
+alsa-usb-audio-fix-missing-error-check-at-mixer-resolution-test.patch
+alsa-usb-audio-not-submit-urb-for-stopped-endpoint.patch
+alsa-usb-audio-fix-incorrect-null-check-in-create_yamaha_midi_quirk.patch
+alsa-usb-audio-fix-incorrect-size-check-for-processing-extension-units.patch
+btrfs-fix-log-context-list-corruption-after-rename-exchange-operation.patch
+input-ff-memless-kill-timer-in-destroy.patch
+input-synaptics-rmi4-fix-video-buffer-size.patch
+input-synaptics-rmi4-disable-the-relative-position-irq-in-the-f12-driver.patch
+input-synaptics-rmi4-do-not-consume-more-data-than-we-have-f11-f12.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
+ib-hfi1-use-a-common-pad-buffer-for-9b-and-16b-packets.patch
+i2c-acpi-force-bus-speed-to-400khz-if-a-silead-touchscreen-is-present.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
+net-ethernet-dwmac-sun8i-use-the-correct-function-in-exit-path.patch
+iommu-vt-d-fix-qi_dev_iotlb_pfsid-and-qi_dev_eiotlb_pfsid-macros.patch
+mm-mempolicy-fix-the-wrong-return-value-and-potential-pages-leak-of-mbind.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
+mm-page_io.c-do-not-free-shared-swap-slots.patch
+mmc-sdhci-of-at91-fix-quirk2-overwrite.patch
diff --git a/queue-4.19/x86-quirks-disable-hpet-on-intel-coffe-lake-platforms.patch b/queue-4.19/x86-quirks-disable-hpet-on-intel-coffe-lake-platforms.patch
new file mode 100644 (file)
index 0000000..a468fa3
--- /dev/null
@@ -0,0 +1,44 @@
+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
+@@ -707,6 +707,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},
+       {}