--- /dev/null
+From 82e06090473289ce63e23fdeb8737aad59b10645 Mon Sep 17 00:00:00 2001
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Date: Wed, 9 Dec 2020 20:13:24 -0800
+Subject: Input: cm109 - do not stomp on control URB
+
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+commit 82e06090473289ce63e23fdeb8737aad59b10645 upstream.
+
+We need to make sure we are not stomping on the control URB that was
+issued when opening the device when attempting to toggle buzzer.
+To do that we need to mark it as pending in cm109_open().
+
+Reported-and-tested-by: syzbot+150f793ac5bc18eee150@syzkaller.appspotmail.com
+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/misc/cm109.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/misc/cm109.c
++++ b/drivers/input/misc/cm109.c
+@@ -571,12 +571,15 @@ static int cm109_input_open(struct input
+ dev->ctl_data->byte[HID_OR2] = dev->keybit;
+ dev->ctl_data->byte[HID_OR3] = 0x00;
+
++ dev->ctl_urb_pending = 1;
+ error = usb_submit_urb(dev->urb_ctl, GFP_KERNEL);
+- if (error)
++ if (error) {
++ dev->ctl_urb_pending = 0;
+ dev_err(&dev->intf->dev, "%s: usb_submit_urb (urb_ctl) failed %d\n",
+ __func__, error);
+- else
++ } else {
+ dev->open = 1;
++ }
+
+ mutex_unlock(&dev->pm_mutex);
+
--- /dev/null
+From ce6520b0eafad5962ffc21dc47cd7bd3250e9045 Mon Sep 17 00:00:00 2001
+From: Chris Chiu <chiu@endlessos.org>
+Date: Wed, 9 Dec 2020 20:24:47 -0800
+Subject: Input: i8042 - add Acer laptops to the i8042 reset list
+
+From: Chris Chiu <chiu@endlessos.org>
+
+commit ce6520b0eafad5962ffc21dc47cd7bd3250e9045 upstream.
+
+The touchpad operates in Basic Mode by default in the Acer BIOS
+setup, but some Aspire/TravelMate models require the i8042 to be
+reset in order to be correctly detected.
+
+Signed-off-by: Chris Chiu <chiu@endlessos.org>
+Link: https://lore.kernel.org/r/20201207071250.15021-1-chiu@endlessos.org
+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/serio/i8042-x86ia64io.h | 42 ++++++++++++++++++++++++++++++++++
+ 1 file changed, 42 insertions(+)
+
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -616,6 +616,48 @@ static const struct dmi_system_id __init
+ },
+ },
+ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A114-31"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A314-31"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire A315-31"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-132"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-332"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire ES1-432"),
++ },
++ },
++ {
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate Spin B118-RN"),
++ },
++ },
++ {
+ /* Advent 4211 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "DIXONSXP"),
--- /dev/null
+From 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 11 Dec 2020 13:36:38 -0800
+Subject: kbuild: avoid static_assert for genksyms
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit 14dc3983b5dff513a90bd5a8cc90acaf7867c3d0 upstream.
+
+genksyms does not know or care about the _Static_assert() built-in, and
+sometimes falls back to ignoring the later symbols, which causes
+undefined behavior such as
+
+ WARNING: modpost: EXPORT symbol "ethtool_set_ethtool_phy_ops" [vmlinux] version generation failed, symbol will not be versioned.
+ ld: net/ethtool/common.o: relocation R_AARCH64_ABS32 against `__crc_ethtool_set_ethtool_phy_ops' can not be used when making a shared object
+ net/ethtool/common.o:(_ftrace_annotated_branch+0x0): dangerous relocation: unsupported relocation
+
+Redefine static_assert for genksyms to avoid that.
+
+Link: https://lkml.kernel.org/r/20201203230955.1482058-1-arnd@kernel.org
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Suggested-by: Ard Biesheuvel <ardb@kernel.org>
+Cc: Masahiro Yamada <masahiroy@kernel.org>
+Cc: Michal Marek <michal.lkml@markovi.net>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: Rikard Falkeborn <rikard.falkeborn@gmail.com>
+Cc: Marco Elver <elver@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>
+
+---
+ include/linux/build_bug.h | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/include/linux/build_bug.h
++++ b/include/linux/build_bug.h
+@@ -80,4 +80,9 @@
+
+ #endif /* __CHECKER__ */
+
++#ifdef __GENKSYMS__
++/* genksyms gets confused by _Static_assert */
++#define _Static_assert(expr, ...)
++#endif
++
+ #endif /* _LINUX_BUILD_BUG_H */
--- /dev/null
+From 6246d7c9d15aaff0bc3863f67900c6a6e6be921b Mon Sep 17 00:00:00 2001
+From: Bean Huo <beanhuo@micron.com>
+Date: Wed, 2 Dec 2020 21:23:20 +0100
+Subject: mmc: block: Fixup condition for CMD13 polling for RPMB requests
+
+From: Bean Huo <beanhuo@micron.com>
+
+commit 6246d7c9d15aaff0bc3863f67900c6a6e6be921b upstream.
+
+The CMD13 polling is needed for commands with R1B responses. In commit
+a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B
+response"), the intent was to introduce this for requests targeted to the
+RPMB partition. However, the condition to trigger the polling loop became
+wrong, leading to unnecessary polling. Let's fix the condition to avoid
+this.
+
+Fixes: a0d4c7eb71dd ("mmc: block: Add CMD13 polling for MMC IOCTLS with R1B response")
+Cc: stable@vger.kernel.org
+Reported-by: Zhan Liu <zliua@micron.com>
+Signed-off-by: Zhan Liu <zliua@micron.com>
+Signed-off-by: Bean Huo <beanhuo@micron.com>
+Link: https://lore.kernel.org/r/20201202202320.22165-1-huobean@gmail.com
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/core/block.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/core/block.c
++++ b/drivers/mmc/core/block.c
+@@ -631,7 +631,7 @@ static int __mmc_blk_ioctl_cmd(struct mm
+
+ memcpy(&(idata->ic.response), cmd.resp, sizeof(cmd.resp));
+
+- if (idata->rpmb || (cmd.flags & MMC_RSP_R1B)) {
++ if (idata->rpmb || (cmd.flags & MMC_RSP_R1B) == MMC_RSP_R1B) {
+ /*
+ * Ensure RPMB/R1B command has completed by polling CMD13
+ * "Send Status".
--- /dev/null
+From 47a0001436352c9853d72bf2071e85b316d688a2 Mon Sep 17 00:00:00 2001
+From: Coiby Xu <coiby.xu@gmail.com>
+Date: Wed, 25 Nov 2020 21:03:19 +0800
+Subject: pinctrl: amd: remove debounce filter setting in IRQ type setting
+
+From: Coiby Xu <coiby.xu@gmail.com>
+
+commit 47a0001436352c9853d72bf2071e85b316d688a2 upstream.
+
+Debounce filter setting should be independent from IRQ type setting
+because according to the ACPI specs, there are separate arguments for
+specifying debounce timeout and IRQ type in GpioIo() and GpioInt().
+
+Together with commit 06abe8291bc31839950f7d0362d9979edc88a666
+("pinctrl: amd: fix incorrect way to disable debounce filter") and
+Andy's patch "gpiolib: acpi: Take into account debounce settings" [1],
+this will fix broken touchpads for laptops whose BIOS set the
+debounce timeout to a relatively large value. For example, the BIOS
+of Lenovo AMD gaming laptops including Legion-5 15ARH05 (R7000),
+Legion-5P (R7000P) and IdeaPad Gaming 3 15ARH05, set the debounce
+timeout to 124.8ms. This led to the kernel receiving only ~7 HID
+reports per second from the Synaptics touchpad
+(MSFT0001:00 06CB:7F28).
+
+Existing touchpads like [2][3] are not troubled by this bug because
+the debounce timeout has been set to 0 by the BIOS before enabling
+the debounce filter in setting IRQ type.
+
+[1] https://lore.kernel.org/linux-gpio/20201111222008.39993-11-andriy.shevchenko@linux.intel.com/
+ 8dcb7a15a585 ("gpiolib: acpi: Take into account debounce settings")
+[2] https://github.com/Syniurge/i2c-amd-mp2/issues/11#issuecomment-721331582
+[3] https://forum.manjaro.org/t/random-short-touchpad-freezes/30832/28
+
+Signed-off-by: Coiby Xu <coiby.xu@gmail.com>
+Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: Hans de Goede <hdegoede@redhat.com>
+Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
+Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/linux-gpio/CAHp75VcwiGREBUJ0A06EEw-SyabqYsp%2Bdqs2DpSrhaY-2GVdAA%40mail.gmail.com/
+BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1887190
+Link: https://lore.kernel.org/r/20201125130320.311059-1-coiby.xu@gmail.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/pinctrl/pinctrl-amd.c | 7 -------
+ 1 file changed, 7 deletions(-)
+
+--- a/drivers/pinctrl/pinctrl-amd.c
++++ b/drivers/pinctrl/pinctrl-amd.c
+@@ -439,7 +439,6 @@ static int amd_gpio_irq_set_type(struct
+ pin_reg &= ~BIT(LEVEL_TRIG_OFF);
+ pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF);
+ pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF;
+- pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF;
+ irq_set_handler_locked(d, handle_edge_irq);
+ break;
+
+@@ -447,7 +446,6 @@ static int amd_gpio_irq_set_type(struct
+ pin_reg &= ~BIT(LEVEL_TRIG_OFF);
+ pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF);
+ pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF;
+- pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF;
+ irq_set_handler_locked(d, handle_edge_irq);
+ break;
+
+@@ -455,7 +453,6 @@ static int amd_gpio_irq_set_type(struct
+ pin_reg &= ~BIT(LEVEL_TRIG_OFF);
+ pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF);
+ pin_reg |= BOTH_EADGE << ACTIVE_LEVEL_OFF;
+- pin_reg |= DB_TYPE_REMOVE_GLITCH << DB_CNTRL_OFF;
+ irq_set_handler_locked(d, handle_edge_irq);
+ break;
+
+@@ -463,8 +460,6 @@ static int amd_gpio_irq_set_type(struct
+ pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF;
+ pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF);
+ pin_reg |= ACTIVE_HIGH << ACTIVE_LEVEL_OFF;
+- pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF);
+- pin_reg |= DB_TYPE_PRESERVE_LOW_GLITCH << DB_CNTRL_OFF;
+ irq_set_handler_locked(d, handle_level_irq);
+ break;
+
+@@ -472,8 +467,6 @@ static int amd_gpio_irq_set_type(struct
+ pin_reg |= LEVEL_TRIGGER << LEVEL_TRIG_OFF;
+ pin_reg &= ~(ACTIVE_LEVEL_MASK << ACTIVE_LEVEL_OFF);
+ pin_reg |= ACTIVE_LOW << ACTIVE_LEVEL_OFF;
+- pin_reg &= ~(DB_CNTRl_MASK << DB_CNTRL_OFF);
+- pin_reg |= DB_TYPE_PRESERVE_HIGH_GLITCH << DB_CNTRL_OFF;
+ irq_set_handler_locked(d, handle_level_irq);
+ break;
+
--- /dev/null
+From eeaf06af6f87e1dba371fbe42674e6f963220b9c Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Thu, 3 Dec 2020 15:18:26 +0300
+Subject: scsi: be2iscsi: Revert "Fix a theoretical leak in beiscsi_create_eqs()"
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit eeaf06af6f87e1dba371fbe42674e6f963220b9c upstream.
+
+My patch caused kernel Oopses and delays in boot. Revert it.
+
+The problem was that I moved the "mem->dma = paddr;" before the call to
+be_fill_queue(). But the first thing that the be_fill_queue() function
+does is memset the whole struct to zero which overwrites the assignment.
+
+Link: https://lore.kernel.org/r/X8jXkt6eThjyVP1v@mwanda
+Fixes: 38b2db564d9a ("scsi: be2iscsi: Fix a theoretical leak in beiscsi_create_eqs()")
+Cc: stable <stable@vger.kernel.org>
+Reported-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/be2iscsi/be_main.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/be2iscsi/be_main.c
++++ b/drivers/scsi/be2iscsi/be_main.c
+@@ -3039,7 +3039,6 @@ static int beiscsi_create_eqs(struct bei
+ goto create_eq_error;
+ }
+
+- mem->dma = paddr;
+ mem->va = eq_vaddress;
+ ret = be_fill_queue(eq, phba->params.num_eq_entries,
+ sizeof(struct be_eq_entry), eq_vaddress);
+@@ -3049,6 +3048,7 @@ static int beiscsi_create_eqs(struct bei
+ goto create_eq_error;
+ }
+
++ mem->dma = paddr;
+ ret = beiscsi_cmd_eq_create(&phba->ctrl, eq,
+ BEISCSI_EQ_DELAY_DEF);
+ if (ret) {
+@@ -3105,7 +3105,6 @@ static int beiscsi_create_cqs(struct bei
+ goto create_cq_error;
+ }
+
+- mem->dma = paddr;
+ ret = be_fill_queue(cq, phba->params.num_cq_entries,
+ sizeof(struct sol_cqe), cq_vaddress);
+ if (ret) {
+@@ -3115,6 +3114,7 @@ static int beiscsi_create_cqs(struct bei
+ goto create_cq_error;
+ }
+
++ mem->dma = paddr;
+ ret = beiscsi_cmd_cq_create(&phba->ctrl, cq, eq, false,
+ false, 0);
+ if (ret) {
platform-x86-thinkpad_acpi-add-bat1-is-primary-batte.patch
platform-x86-acer-wmi-add-automatic-keyboard-backgro.patch
platform-x86-intel-vbtn-support-for-tablet-mode-on-h.patch
+input-cm109-do-not-stomp-on-control-urb.patch
+input-i8042-add-acer-laptops-to-the-i8042-reset-list.patch
+pinctrl-amd-remove-debounce-filter-setting-in-irq-type-setting.patch
+mmc-block-fixup-condition-for-cmd13-polling-for-rpmb-requests.patch
+kbuild-avoid-static_assert-for-genksyms.patch
+scsi-be2iscsi-revert-fix-a-theoretical-leak-in-beiscsi_create_eqs.patch
+x86-mm-mem_encrypt-fix-definition-of-pmd_flags_dec_wp.patch
+x86-membarrier-get-rid-of-a-dubious-optimization.patch
+x86-apic-vector-fix-ordering-in-vector-assignment.patch
--- /dev/null
+From 190113b4c6531c8e09b31d5235f9b5175cbb0f72 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 10 Dec 2020 21:18:22 +0100
+Subject: x86/apic/vector: Fix ordering in vector assignment
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 190113b4c6531c8e09b31d5235f9b5175cbb0f72 upstream.
+
+Prarit reported that depending on the affinity setting the
+
+ ' irq $N: Affinity broken due to vector space exhaustion.'
+
+message is showing up in dmesg, but the vector space on the CPUs in the
+affinity mask is definitely not exhausted.
+
+Shung-Hsi provided traces and analysis which pinpoints the problem:
+
+The ordering of trying to assign an interrupt vector in
+assign_irq_vector_any_locked() is simply wrong if the interrupt data has a
+valid node assigned. It does:
+
+ 1) Try the intersection of affinity mask and node mask
+ 2) Try the node mask
+ 3) Try the full affinity mask
+ 4) Try the full online mask
+
+Obviously #2 and #3 are in the wrong order as the requested affinity
+mask has to take precedence.
+
+In the observed cases #1 failed because the affinity mask did not contain
+CPUs from node 0. That made it allocate a vector from node 0, thereby
+breaking affinity and emitting the misleading message.
+
+Revert the order of #2 and #3 so the full affinity mask without the node
+intersection is tried before actually affinity is broken.
+
+If no node is assigned then only the full affinity mask and if that fails
+the full online mask is tried.
+
+Fixes: d6ffc6ac83b1 ("x86/vector: Respect affinity mask in irq descriptor")
+Reported-by: Prarit Bhargava <prarit@redhat.com>
+Reported-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Tested-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/87ft4djtyp.fsf@nanos.tec.linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/apic/vector.c | 24 ++++++++++++++----------
+ 1 file changed, 14 insertions(+), 10 deletions(-)
+
+--- a/arch/x86/kernel/apic/vector.c
++++ b/arch/x86/kernel/apic/vector.c
+@@ -274,20 +274,24 @@ static int assign_irq_vector_any_locked(
+ const struct cpumask *affmsk = irq_data_get_affinity_mask(irqd);
+ int node = irq_data_get_node(irqd);
+
+- if (node == NUMA_NO_NODE)
+- goto all;
+- /* Try the intersection of @affmsk and node mask */
+- cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk);
+- if (!assign_vector_locked(irqd, vector_searchmask))
+- return 0;
+- /* Try the node mask */
+- if (!assign_vector_locked(irqd, cpumask_of_node(node)))
+- return 0;
+-all:
++ if (node != NUMA_NO_NODE) {
++ /* Try the intersection of @affmsk and node mask */
++ cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk);
++ if (!assign_vector_locked(irqd, vector_searchmask))
++ return 0;
++ }
++
+ /* Try the full affinity mask */
+ cpumask_and(vector_searchmask, affmsk, cpu_online_mask);
+ if (!assign_vector_locked(irqd, vector_searchmask))
+ return 0;
++
++ if (node != NUMA_NO_NODE) {
++ /* Try the node mask */
++ if (!assign_vector_locked(irqd, cpumask_of_node(node)))
++ return 0;
++ }
++
+ /* Try the full online mask */
+ return assign_vector_locked(irqd, cpu_online_mask);
+ }
--- /dev/null
+From a493d1ca1a03b532871f1da27f8dbda2b28b04c4 Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Thu, 3 Dec 2020 21:07:03 -0800
+Subject: x86/membarrier: Get rid of a dubious optimization
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit a493d1ca1a03b532871f1da27f8dbda2b28b04c4 upstream.
+
+sync_core_before_usermode() had an incorrect optimization. If the kernel
+returns from an interrupt, it can get to usermode without IRET. It just has
+to schedule to a different task in the same mm and do SYSRET. Fortunately,
+there were no callers of sync_core_before_usermode() that could have had
+in_irq() or in_nmi() equal to true, because it's only ever called from the
+scheduler.
+
+While at it, clarify a related comment.
+
+Fixes: 70216e18e519 ("membarrier: Provide core serializing command, *_SYNC_CORE")
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/5afc7632be1422f91eaf7611aaaa1b5b8580a086.1607058304.git.luto@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/sync_core.h | 9 +++++----
+ arch/x86/mm/tlb.c | 10 ++++++++--
+ 2 files changed, 13 insertions(+), 6 deletions(-)
+
+--- a/arch/x86/include/asm/sync_core.h
++++ b/arch/x86/include/asm/sync_core.h
+@@ -16,12 +16,13 @@ static inline void sync_core_before_user
+ /* With PTI, we unconditionally serialize before running user code. */
+ if (static_cpu_has(X86_FEATURE_PTI))
+ return;
++
+ /*
+- * Return from interrupt and NMI is done through iret, which is core
+- * serializing.
++ * Even if we're in an interrupt, we might reschedule before returning,
++ * in which case we could switch to a different thread in the same mm
++ * and return using SYSRET or SYSEXIT. Instead of trying to keep
++ * track of our need to sync the core, just sync right away.
+ */
+- if (in_irq() || in_nmi())
+- return;
+ sync_core();
+ }
+
+--- a/arch/x86/mm/tlb.c
++++ b/arch/x86/mm/tlb.c
+@@ -321,8 +321,14 @@ void switch_mm_irqs_off(struct mm_struct
+ /*
+ * The membarrier system call requires a full memory barrier and
+ * core serialization before returning to user-space, after
+- * storing to rq->curr. Writing to CR3 provides that full
+- * memory barrier and core serializing instruction.
++ * storing to rq->curr, when changing mm. This is because
++ * membarrier() sends IPIs to all CPUs that are in the target mm
++ * to make them issue memory barriers. However, if another CPU
++ * switches to/from the target mm concurrently with
++ * membarrier(), it can cause that CPU not to receive an IPI
++ * when it really should issue a memory barrier. Writing to CR3
++ * provides that full memory barrier and core serializing
++ * instruction.
+ */
+ if (real_prev == next) {
+ VM_WARN_ON(this_cpu_read(cpu_tlbstate.ctxs[prev_asid].ctx_id) !=
--- /dev/null
+From 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25 Mon Sep 17 00:00:00 2001
+From: Arvind Sankar <nivedita@alum.mit.edu>
+Date: Wed, 11 Nov 2020 11:09:45 -0500
+Subject: x86/mm/mem_encrypt: Fix definition of PMD_FLAGS_DEC_WP
+
+From: Arvind Sankar <nivedita@alum.mit.edu>
+
+commit 29ac40cbed2bc06fa218ca25d7f5e280d3d08a25 upstream.
+
+The PAT bit is in different locations for 4k and 2M/1G page table
+entries.
+
+Add a definition for _PAGE_LARGE_CACHE_MASK to represent the three
+caching bits (PWT, PCD, PAT), similar to _PAGE_CACHE_MASK for 4k pages,
+and use it in the definition of PMD_FLAGS_DEC_WP to get the correct PAT
+index for write-protected pages.
+
+Fixes: 6ebcb060713f ("x86/mm: Add support to encrypt the kernel in-place")
+Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20201111160946.147341-1-nivedita@alum.mit.edu
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/pgtable_types.h | 1 +
+ arch/x86/mm/mem_encrypt_identity.c | 4 ++--
+ 2 files changed, 3 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/include/asm/pgtable_types.h
++++ b/arch/x86/include/asm/pgtable_types.h
+@@ -148,6 +148,7 @@ enum page_cache_mode {
+ #endif
+
+ #define _PAGE_CACHE_MASK (_PAGE_PAT | _PAGE_PCD | _PAGE_PWT)
++#define _PAGE_LARGE_CACHE_MASK (_PAGE_PWT | _PAGE_PCD | _PAGE_PAT_LARGE)
+ #define _PAGE_NOCACHE (cachemode2protval(_PAGE_CACHE_MODE_UC))
+ #define _PAGE_CACHE_WP (cachemode2protval(_PAGE_CACHE_MODE_WP))
+
+--- a/arch/x86/mm/mem_encrypt_identity.c
++++ b/arch/x86/mm/mem_encrypt_identity.c
+@@ -47,8 +47,8 @@
+ #define PMD_FLAGS_LARGE (__PAGE_KERNEL_LARGE_EXEC & ~_PAGE_GLOBAL)
+
+ #define PMD_FLAGS_DEC PMD_FLAGS_LARGE
+-#define PMD_FLAGS_DEC_WP ((PMD_FLAGS_DEC & ~_PAGE_CACHE_MASK) | \
+- (_PAGE_PAT | _PAGE_PWT))
++#define PMD_FLAGS_DEC_WP ((PMD_FLAGS_DEC & ~_PAGE_LARGE_CACHE_MASK) | \
++ (_PAGE_PAT_LARGE | _PAGE_PWT))
+
+ #define PMD_FLAGS_ENC (PMD_FLAGS_LARGE | _PAGE_ENC)
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
