--- /dev/null
+From 8cdddd182bd7befae6af49c5fd612893f55d6ccb Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Wed, 24 Mar 2021 16:22:19 +0100
+Subject: ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead()
+
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+
+commit 8cdddd182bd7befae6af49c5fd612893f55d6ccb upstream.
+
+Commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms
+with one ACPI C-state") broke CPU0 hotplug on certain systems, e.g.
+I'm observing the following on AWS Nitro (e.g r5b.xlarge but other
+instance types are affected as well):
+
+ # echo 0 > /sys/devices/system/cpu/cpu0/online
+ # echo 1 > /sys/devices/system/cpu/cpu0/online
+ <10 seconds delay>
+ -bash: echo: write error: Input/output error
+
+In fact, the above mentioned commit only revealed the problem and did
+not introduce it. On x86, to wakeup CPU an NMI is being used and
+hlt_play_dead()/mwait_play_dead() loops are prepared to handle it:
+
+ /*
+ * If NMI wants to wake up CPU0, start CPU0.
+ */
+ if (wakeup_cpu0())
+ start_cpu0();
+
+cpuidle_play_dead() -> acpi_idle_play_dead() (which is now being called on
+systems where it wasn't called before the above mentioned commit) serves
+the same purpose but it doesn't have a path for CPU0. What happens now on
+wakeup is:
+ - NMI is sent to CPU0
+ - wakeup_cpu0_nmi() works as expected
+ - we get back to while (1) loop in acpi_idle_play_dead()
+ - safe_halt() puts CPU0 to sleep again.
+
+The straightforward/minimal fix is add the special handling for CPU0 on x86
+and that's what the patch is doing.
+
+Fixes: 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state")
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/include/asm/smp.h | 1 +
+ arch/x86/kernel/smpboot.c | 2 +-
+ drivers/acpi/processor_idle.c | 7 +++++++
+ 3 files changed, 9 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/smp.h
++++ b/arch/x86/include/asm/smp.h
+@@ -132,6 +132,7 @@ void native_play_dead(void);
+ void play_dead_common(void);
+ void wbinvd_on_cpu(int cpu);
+ int wbinvd_on_all_cpus(void);
++bool wakeup_cpu0(void);
+
+ void native_smp_send_reschedule(int cpu);
+ void native_send_call_func_ipi(const struct cpumask *mask);
+--- a/arch/x86/kernel/smpboot.c
++++ b/arch/x86/kernel/smpboot.c
+@@ -1655,7 +1655,7 @@ void play_dead_common(void)
+ local_irq_disable();
+ }
+
+-static bool wakeup_cpu0(void)
++bool wakeup_cpu0(void)
+ {
+ if (smp_processor_id() == 0 && enable_start_cpu0)
+ return true;
+--- a/drivers/acpi/processor_idle.c
++++ b/drivers/acpi/processor_idle.c
+@@ -29,6 +29,7 @@
+ */
+ #ifdef CONFIG_X86
+ #include <asm/apic.h>
++#include <asm/cpu.h>
+ #endif
+
+ #define ACPI_PROCESSOR_CLASS "processor"
+@@ -542,6 +543,12 @@ static int acpi_idle_play_dead(struct cp
+ wait_for_freeze();
+ } else
+ return -ENODEV;
++
++#if defined(CONFIG_X86) && defined(CONFIG_HOTPLUG_CPU)
++ /* If NMI wants to wake up CPU0, start CPU0. */
++ if (wakeup_cpu0())
++ start_cpu0();
++#endif
+ }
+
+ /* Never reached */
--- /dev/null
+From 1a1c130ab7575498eed5bcf7220037ae09cd1f8a Mon Sep 17 00:00:00 2001
+From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
+Date: Tue, 23 Mar 2021 20:26:52 +0100
+Subject: ACPI: tables: x86: Reserve memory occupied by ACPI tables
+
+From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+
+commit 1a1c130ab7575498eed5bcf7220037ae09cd1f8a upstream.
+
+The following problem has been reported by George Kennedy:
+
+ Since commit 7fef431be9c9 ("mm/page_alloc: place pages to tail
+ in __free_pages_core()") the following use after free occurs
+ intermittently when ACPI tables are accessed.
+
+ BUG: KASAN: use-after-free in ibft_init+0x134/0xc49
+ Read of size 4 at addr ffff8880be453004 by task swapper/0/1
+ CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc1-7a7fd0d #1
+ Call Trace:
+ dump_stack+0xf6/0x158
+ print_address_description.constprop.9+0x41/0x60
+ kasan_report.cold.14+0x7b/0xd4
+ __asan_report_load_n_noabort+0xf/0x20
+ ibft_init+0x134/0xc49
+ do_one_initcall+0xc4/0x3e0
+ kernel_init_freeable+0x5af/0x66b
+ kernel_init+0x16/0x1d0
+ ret_from_fork+0x22/0x30
+
+ ACPI tables mapped via kmap() do not have their mapped pages
+ reserved and the pages can be "stolen" by the buddy allocator.
+
+Apparently, on the affected system, the ACPI table in question is
+not located in "reserved" memory, like ACPI NVS or ACPI Data, that
+will not be used by the buddy allocator, so the memory occupied by
+that table has to be explicitly reserved to prevent the buddy
+allocator from using it.
+
+In order to address this problem, rearrange the initialization of the
+ACPI tables on x86 to locate the initial tables earlier and reserve
+the memory occupied by them.
+
+The other architectures using ACPI should not be affected by this
+change.
+
+Link: https://lore.kernel.org/linux-acpi/1614802160-29362-1-git-send-email-george.kennedy@oracle.com/
+Reported-by: George Kennedy <george.kennedy@oracle.com>
+Tested-by: George Kennedy <george.kennedy@oracle.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
+Cc: 5.10+ <stable@vger.kernel.org> # 5.10+
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/acpi/boot.c | 25 ++++++++++++-------------
+ arch/x86/kernel/setup.c | 8 +++-----
+ drivers/acpi/tables.c | 42 +++++++++++++++++++++++++++++++++++++++---
+ include/linux/acpi.h | 9 ++++++++-
+ 4 files changed, 62 insertions(+), 22 deletions(-)
+
+--- a/arch/x86/kernel/acpi/boot.c
++++ b/arch/x86/kernel/acpi/boot.c
+@@ -1554,10 +1554,18 @@ void __init acpi_boot_table_init(void)
+ /*
+ * Initialize the ACPI boot-time table parser.
+ */
+- if (acpi_table_init()) {
++ if (acpi_locate_initial_tables())
+ disable_acpi();
+- return;
+- }
++ else
++ acpi_reserve_initial_tables();
++}
++
++int __init early_acpi_boot_init(void)
++{
++ if (acpi_disabled)
++ return 1;
++
++ acpi_table_init_complete();
+
+ acpi_table_parse(ACPI_SIG_BOOT, acpi_parse_sbf);
+
+@@ -1570,18 +1578,9 @@ void __init acpi_boot_table_init(void)
+ } else {
+ printk(KERN_WARNING PREFIX "Disabling ACPI support\n");
+ disable_acpi();
+- return;
++ return 1;
+ }
+ }
+-}
+-
+-int __init early_acpi_boot_init(void)
+-{
+- /*
+- * If acpi_disabled, bail out
+- */
+- if (acpi_disabled)
+- return 1;
+
+ /*
+ * Process the Multiple APIC Description Table (MADT), if present
+--- a/arch/x86/kernel/setup.c
++++ b/arch/x86/kernel/setup.c
+@@ -1051,6 +1051,9 @@ void __init setup_arch(char **cmdline_p)
+
+ cleanup_highmap();
+
++ /* Look for ACPI tables and reserve memory occupied by them. */
++ acpi_boot_table_init();
++
+ memblock_set_current_limit(ISA_END_ADDRESS);
+ e820__memblock_setup();
+
+@@ -1136,11 +1139,6 @@ void __init setup_arch(char **cmdline_p)
+
+ early_platform_quirks();
+
+- /*
+- * Parse the ACPI tables for possible boot-time SMP configuration.
+- */
+- acpi_boot_table_init();
+-
+ early_acpi_boot_init();
+
+ initmem_init();
+--- a/drivers/acpi/tables.c
++++ b/drivers/acpi/tables.c
+@@ -780,7 +780,7 @@ acpi_status acpi_os_table_override(struc
+ }
+
+ /*
+- * acpi_table_init()
++ * acpi_locate_initial_tables()
+ *
+ * find RSDP, find and checksum SDT/XSDT.
+ * checksum all tables, print SDT/XSDT
+@@ -788,7 +788,7 @@ acpi_status acpi_os_table_override(struc
+ * result: sdt_entry[] is initialized
+ */
+
+-int __init acpi_table_init(void)
++int __init acpi_locate_initial_tables(void)
+ {
+ acpi_status status;
+
+@@ -803,9 +803,45 @@ int __init acpi_table_init(void)
+ status = acpi_initialize_tables(initial_tables, ACPI_MAX_TABLES, 0);
+ if (ACPI_FAILURE(status))
+ return -EINVAL;
+- acpi_table_initrd_scan();
+
++ return 0;
++}
++
++void __init acpi_reserve_initial_tables(void)
++{
++ int i;
++
++ for (i = 0; i < ACPI_MAX_TABLES; i++) {
++ struct acpi_table_desc *table_desc = &initial_tables[i];
++ u64 start = table_desc->address;
++ u64 size = table_desc->length;
++
++ if (!start || !size)
++ break;
++
++ pr_info("Reserving %4s table memory at [mem 0x%llx-0x%llx]\n",
++ table_desc->signature.ascii, start, start + size - 1);
++
++ memblock_reserve(start, size);
++ }
++}
++
++void __init acpi_table_init_complete(void)
++{
++ acpi_table_initrd_scan();
+ check_multiple_madt();
++}
++
++int __init acpi_table_init(void)
++{
++ int ret;
++
++ ret = acpi_locate_initial_tables();
++ if (ret)
++ return ret;
++
++ acpi_table_init_complete();
++
+ return 0;
+ }
+
+--- a/include/linux/acpi.h
++++ b/include/linux/acpi.h
+@@ -222,10 +222,14 @@ void __iomem *__acpi_map_table(unsigned
+ void __acpi_unmap_table(void __iomem *map, unsigned long size);
+ int early_acpi_boot_init(void);
+ int acpi_boot_init (void);
++void acpi_boot_table_prepare (void);
+ void acpi_boot_table_init (void);
+ int acpi_mps_check (void);
+ int acpi_numa_init (void);
+
++int acpi_locate_initial_tables (void);
++void acpi_reserve_initial_tables (void);
++void acpi_table_init_complete (void);
+ int acpi_table_init (void);
+ int acpi_table_parse(char *id, acpi_tbl_table_handler handler);
+ int __init acpi_table_parse_entries(char *id, unsigned long table_size,
+@@ -807,9 +811,12 @@ static inline int acpi_boot_init(void)
+ return 0;
+ }
+
++static inline void acpi_boot_table_prepare(void)
++{
++}
++
+ static inline void acpi_boot_table_init(void)
+ {
+- return;
+ }
+
+ static inline int acpi_mps_check(void)
--- /dev/null
+From 66affb7bb0dc0905155a1b2475261aa704d1ddb5 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 29 Mar 2021 13:30:59 +0200
+Subject: ALSA: hda: Add missing sanity checks in PM prepare/complete callbacks
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit 66affb7bb0dc0905155a1b2475261aa704d1ddb5 upstream.
+
+The recently added PM prepare and complete callbacks don't have the
+sanity check whether the card instance has been properly initialized,
+which may potentially lead to Oops.
+
+This patch adds the azx_is_pm_ready() call in each place
+appropriately like other PM callbacks.
+
+Fixes: f5dac54d9d93 ("ALSA: hda: Separate runtime and system suspend")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210329113059.25035-2-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/hda_intel.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -1023,6 +1023,9 @@ static int azx_prepare(struct device *de
+ struct snd_card *card = dev_get_drvdata(dev);
+ struct azx *chip;
+
++ if (!azx_is_pm_ready(card))
++ return 0;
++
+ chip = card->private_data;
+ chip->pm_prepared = 1;
+ snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
+@@ -1040,6 +1043,9 @@ static void azx_complete(struct device *
+ struct snd_card *card = dev_get_drvdata(dev);
+ struct azx *chip;
+
++ if (!azx_is_pm_ready(card))
++ return;
++
+ chip = card->private_data;
+ snd_power_change_state(card, SNDRV_CTL_POWER_D0);
+ chip->pm_prepared = 0;
--- /dev/null
+From c8f79808cd8eb5bc8d14de129bd6d586d3fce0aa Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 29 Mar 2021 13:30:58 +0200
+Subject: ALSA: hda: Re-add dropped snd_poewr_change_state() calls
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit c8f79808cd8eb5bc8d14de129bd6d586d3fce0aa upstream.
+
+The card power state change via snd_power_change_state() at the system
+suspend/resume seems dropped mistakenly during the PM code rewrite.
+The card power state doesn't play much role nowadays but it's still
+referred in a few places such as the HDMI codec driver.
+
+This patch restores them, but in a more appropriate place now in the
+prepare and complete callbacks.
+
+Fixes: f5dac54d9d93 ("ALSA: hda: Separate runtime and system suspend")
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210329113059.25035-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/hda_intel.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/sound/pci/hda/hda_intel.c
++++ b/sound/pci/hda/hda_intel.c
+@@ -1025,6 +1025,7 @@ static int azx_prepare(struct device *de
+
+ chip = card->private_data;
+ chip->pm_prepared = 1;
++ snd_power_change_state(card, SNDRV_CTL_POWER_D3hot);
+
+ flush_work(&azx_bus(chip)->unsol_work);
+
+@@ -1040,6 +1041,7 @@ static void azx_complete(struct device *
+ struct azx *chip;
+
+ chip = card->private_data;
++ snd_power_change_state(card, SNDRV_CTL_POWER_D0);
+ chip->pm_prepared = 0;
+ }
+
--- /dev/null
+From e54f30befa7990b897189b44a56c1138c6bfdbb5 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Sat, 20 Mar 2021 17:15:42 +0800
+Subject: ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit e54f30befa7990b897189b44a56c1138c6bfdbb5 upstream.
+
+We found the alc_update_headset_mode() is not called on some machines
+when unplugging the headset, as a result, the mode of the
+ALC_HEADSET_MODE_UNPLUGGED can't be set, then the current_headset_type
+is not cleared, if users plug a differnt type of headset next time,
+the determine_headset_type() will not be called and the audio jack is
+set to the headset type of previous time.
+
+On the Dell machines which connect the dmic to the PCH, if we open
+the gnome-sound-setting and unplug the headset, this issue will
+happen. Those machines disable the auto-mute by ucm and has no
+internal mic in the input source, so the update_headset_mode() will
+not be called by cap_sync_hook or automute_hook when unplugging, and
+because the gnome-sound-setting is opened, the codec will not enter
+the runtime_suspend state, so the update_headset_mode() will not be
+called by alc_resume when unplugging. In this case the
+hp_automute_hook is called when unplugging, so add
+update_headset_mode() calling to this function.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5440,6 +5440,7 @@ static void alc_update_headset_jack_cb(s
+ struct hda_jack_callback *jack)
+ {
+ snd_hda_gen_hp_automute(codec, jack);
++ alc_update_headset_mode(codec);
+ }
+
+ static void alc_probe_headset_mode(struct hda_codec *codec)
--- /dev/null
+From febf22565549ea7111e7d45e8f2d64373cc66b11 Mon Sep 17 00:00:00 2001
+From: Hui Wang <hui.wang@canonical.com>
+Date: Sat, 20 Mar 2021 17:15:41 +0800
+Subject: ALSA: hda/realtek: fix a determine_headset_type issue for a Dell AIO
+
+From: Hui Wang <hui.wang@canonical.com>
+
+commit febf22565549ea7111e7d45e8f2d64373cc66b11 upstream.
+
+We found a recording issue on a Dell AIO, users plug a headset-mic and
+select headset-mic from UI, but can't record any sound from
+headset-mic. The root cause is the determine_headset_type() returns a
+wrong type, e.g. users plug a ctia type headset, but that function
+returns omtp type.
+
+On this machine, the internal mic is not connected to the codec, the
+"Input Source" is headset mic by default. And when users plug a
+headset, the determine_headset_type() will be called immediately, the
+codec on this AIO is alc274, the delay time for this codec in the
+determine_headset_type() is only 80ms, the delay is too short to
+correctly determine the headset type, the fail rate is nearly 99% when
+users plug the headset with the normal speed.
+
+Other codecs set several hundred ms delay time, so here I change the
+delay time to 850ms for alc2x4 series, after this change, the fail
+rate is zero unless users plug the headset slowly on purpose.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Hui Wang <hui.wang@canonical.com>
+Link: https://lore.kernel.org/r/20210320091542.6748-1-hui.wang@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -5256,7 +5256,7 @@ static void alc_determine_headset_type(s
+ case 0x10ec0274:
+ case 0x10ec0294:
+ alc_process_coef_fw(codec, coef0274);
+- msleep(80);
++ msleep(850);
+ val = alc_read_coef_idx(codec, 0x46);
+ is_ctia = (val & 0x00f0) == 0x00f0;
+ break;
--- /dev/null
+From 417eadfdd9e25188465280edf3668ed163fda2d0 Mon Sep 17 00:00:00 2001
+From: Jeremy Szu <jeremy.szu@canonical.com>
+Date: Tue, 30 Mar 2021 19:44:27 +0800
+Subject: ALSA: hda/realtek: fix mute/micmute LEDs for HP 640 G8
+
+From: Jeremy Szu <jeremy.szu@canonical.com>
+
+commit 417eadfdd9e25188465280edf3668ed163fda2d0 upstream.
+
+The HP EliteBook 640 G8 Notebook PC is using ALC236 codec which is
+using 0x02 to control mute LED and 0x01 to control micmute LED.
+Therefore, add a quirk to make it works.
+
+Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210330114428.40490-1-jeremy.szu@canonical.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/pci/hda/patch_realtek.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/pci/hda/patch_realtek.c
++++ b/sound/pci/hda/patch_realtek.c
+@@ -8058,6 +8058,7 @@ static const struct snd_pci_quirk alc269
+ ALC285_FIXUP_HP_GPIO_AMP_INIT),
+ SND_PCI_QUIRK(0x103c, 0x87c8, "HP", ALC287_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87e5, "HP ProBook 440 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
++ SND_PCI_QUIRK(0x103c, 0x87f2, "HP ProBook 640 G8 Notebook PC", ALC236_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87f4, "HP", ALC287_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87f5, "HP", ALC287_FIXUP_HP_GPIO_LED),
+ SND_PCI_QUIRK(0x103c, 0x87f7, "HP Spectre x360 14", ALC245_FIXUP_HP_X360_AMP),
--- /dev/null
+From 625bd5a616ceda4840cd28f82e957c8ced394b6a Mon Sep 17 00:00:00 2001
+From: Ikjoon Jang <ikjn@chromium.org>
+Date: Wed, 24 Mar 2021 18:51:52 +0800
+Subject: ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
+
+From: Ikjoon Jang <ikjn@chromium.org>
+
+commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
+
+Logitech ConferenceCam Connect is a compound USB device with UVC and
+UAC. Not 100% reproducible but sometimes it keeps responding STALL to
+every control transfer once it receives get_freq request.
+
+This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419
+Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/r/20210324105153.2322881-1-ikjn@chromium.org
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/usb/quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/sound/usb/quirks.c
++++ b/sound/usb/quirks.c
+@@ -1521,6 +1521,7 @@ bool snd_usb_get_sample_rate_quirk(struc
+ case USB_ID(0x21b4, 0x0081): /* AudioQuest DragonFly */
+ case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */
+ case USB_ID(0x413c, 0xa506): /* Dell AE515 sound bar */
++ case USB_ID(0x046d, 0x084c): /* Logitech ConferenceCam Connect */
+ return true;
+ }
+
--- /dev/null
+From 6306c1189e77a513bf02720450bb43bd4ba5d8ae Mon Sep 17 00:00:00 2001
+From: Jesper Dangaard Brouer <brouer@redhat.com>
+Date: Tue, 9 Feb 2021 14:38:09 +0100
+Subject: bpf: Remove MTU check in __bpf_skb_max_len
+
+From: Jesper Dangaard Brouer <brouer@redhat.com>
+
+commit 6306c1189e77a513bf02720450bb43bd4ba5d8ae upstream.
+
+Multiple BPF-helpers that can manipulate/increase the size of the SKB uses
+__bpf_skb_max_len() as the max-length. This function limit size against
+the current net_device MTU (skb->dev->mtu).
+
+When a BPF-prog grow the packet size, then it should not be limited to the
+MTU. The MTU is a transmit limitation, and software receiving this packet
+should be allowed to increase the size. Further more, current MTU check in
+__bpf_skb_max_len uses the MTU from ingress/current net_device, which in
+case of redirects uses the wrong net_device.
+
+This patch keeps a sanity max limit of SKB_MAX_ALLOC (16KiB). The real limit
+is elsewhere in the system. Jesper's testing[1] showed it was not possible
+to exceed 8KiB when expanding the SKB size via BPF-helper. The limiting
+factor is the define KMALLOC_MAX_CACHE_SIZE which is 8192 for
+SLUB-allocator (CONFIG_SLUB) in-case PAGE_SIZE is 4096. This define is
+in-effect due to this being called from softirq context see code
+__gfp_pfmemalloc_flags() and __do_kmalloc_node(). Jakub's testing showed
+that frames above 16KiB can cause NICs to reset (but not crash). Keep this
+sanity limit at this level as memory layer can differ based on kernel
+config.
+
+[1] https://github.com/xdp-project/bpf-examples/tree/master/MTU-tests
+
+Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Acked-by: John Fastabend <john.fastabend@gmail.com>
+Link: https://lore.kernel.org/bpf/161287788936.790810.2937823995775097177.stgit@firesoul
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/core/filter.c | 12 ++++--------
+ 1 file changed, 4 insertions(+), 8 deletions(-)
+
+--- a/net/core/filter.c
++++ b/net/core/filter.c
+@@ -3552,11 +3552,7 @@ static int bpf_skb_net_shrink(struct sk_
+ return 0;
+ }
+
+-static u32 __bpf_skb_max_len(const struct sk_buff *skb)
+-{
+- return skb->dev ? skb->dev->mtu + skb->dev->hard_header_len :
+- SKB_MAX_ALLOC;
+-}
++#define BPF_SKB_MAX_LEN SKB_MAX_ALLOC
+
+ BPF_CALL_4(sk_skb_adjust_room, struct sk_buff *, skb, s32, len_diff,
+ u32, mode, u64, flags)
+@@ -3605,7 +3601,7 @@ BPF_CALL_4(bpf_skb_adjust_room, struct s
+ {
+ u32 len_cur, len_diff_abs = abs(len_diff);
+ u32 len_min = bpf_skb_net_base_len(skb);
+- u32 len_max = __bpf_skb_max_len(skb);
++ u32 len_max = BPF_SKB_MAX_LEN;
+ __be16 proto = skb->protocol;
+ bool shrink = len_diff < 0;
+ u32 off;
+@@ -3688,7 +3684,7 @@ static int bpf_skb_trim_rcsum(struct sk_
+ static inline int __bpf_skb_change_tail(struct sk_buff *skb, u32 new_len,
+ u64 flags)
+ {
+- u32 max_len = __bpf_skb_max_len(skb);
++ u32 max_len = BPF_SKB_MAX_LEN;
+ u32 min_len = __bpf_skb_min_len(skb);
+ int ret;
+
+@@ -3764,7 +3760,7 @@ static const struct bpf_func_proto sk_sk
+ static inline int __bpf_skb_change_head(struct sk_buff *skb, u32 head_room,
+ u64 flags)
+ {
+- u32 max_len = __bpf_skb_max_len(skb);
++ u32 max_len = BPF_SKB_MAX_LEN;
+ u32 new_len = skb->len + head_room;
+ int ret;
+
--- /dev/null
+From 3c346c0c60ab06a021d1c0884a0ef494bc4ee3a7 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Wed, 31 Mar 2021 06:28:01 -0400
+Subject: KVM: SVM: ensure that EFER.SVME is set when running nested guest or on nested vmexit
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit 3c346c0c60ab06a021d1c0884a0ef494bc4ee3a7 upstream.
+
+Fixing nested_vmcb_check_save to avoid all TOC/TOU races
+is a bit harder in released kernels, so do the bare minimum
+by avoiding that EFER.SVME is cleared. This is problematic
+because svm_set_efer frees the data structures for nested
+virtualization if EFER.SVME is cleared.
+
+Also check that EFER.SVME remains set after a nested vmexit;
+clearing it could happen if the bit is zero in the save area
+that is passed to KVM_SET_NESTED_STATE (the save area of the
+nested state corresponds to the nested hypervisor's state
+and is restored on the next nested vmexit).
+
+Cc: stable@vger.kernel.org
+Fixes: 2fcf4876ada ("KVM: nSVM: implement on demand allocation of the nested state")
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/nested.c | 18 +++++++++++++++++-
+ 1 file changed, 17 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/svm/nested.c
++++ b/arch/x86/kvm/svm/nested.c
+@@ -251,6 +251,13 @@ static bool nested_vmcb_check_save(struc
+ struct kvm_vcpu *vcpu = &svm->vcpu;
+ bool vmcb12_lma;
+
++ /*
++ * FIXME: these should be done after copying the fields,
++ * to avoid TOC/TOU races. For these save area checks
++ * the possible damage is limited since kvm_set_cr0 and
++ * kvm_set_cr4 handle failure; EFER_SVME is an exception
++ * so it is force-set later in nested_prepare_vmcb_save.
++ */
+ if ((vmcb12->save.efer & EFER_SVME) == 0)
+ return false;
+
+@@ -396,7 +403,14 @@ static void nested_prepare_vmcb_save(str
+ svm->vmcb->save.gdtr = vmcb12->save.gdtr;
+ svm->vmcb->save.idtr = vmcb12->save.idtr;
+ kvm_set_rflags(&svm->vcpu, vmcb12->save.rflags);
+- svm_set_efer(&svm->vcpu, vmcb12->save.efer);
++
++ /*
++ * Force-set EFER_SVME even though it is checked earlier on the
++ * VMCB12, because the guest can flip the bit between the check
++ * and now. Clearing EFER_SVME would call svm_free_nested.
++ */
++ svm_set_efer(&svm->vcpu, vmcb12->save.efer | EFER_SVME);
++
+ svm_set_cr0(&svm->vcpu, vmcb12->save.cr0);
+ svm_set_cr4(&svm->vcpu, vmcb12->save.cr4);
+ svm->vmcb->save.cr2 = svm->vcpu.arch.cr2 = vmcb12->save.cr2;
+@@ -1207,6 +1221,8 @@ static int svm_set_nested_state(struct k
+ */
+ if (!(save->cr0 & X86_CR0_PG))
+ goto out_free;
++ if (!(save->efer & EFER_SVME))
++ goto out_free;
+
+ /*
+ * All checks done, we can enter guest mode. L1 control fields
--- /dev/null
+From a58d9166a756a0f4a6618e4f593232593d6df134 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Wed, 31 Mar 2021 06:24:43 -0400
+Subject: KVM: SVM: load control fields from VMCB12 before checking them
+
+From: Paolo Bonzini <pbonzini@redhat.com>
+
+commit a58d9166a756a0f4a6618e4f593232593d6df134 upstream.
+
+Avoid races between check and use of the nested VMCB controls. This
+for example ensures that the VMRUN intercept is always reflected to the
+nested hypervisor, instead of being processed by the host. Without this
+patch, it is possible to end up with svm->nested.hsave pointing to
+the MSR permission bitmap for nested guests.
+
+This bug is CVE-2021-29657.
+
+Reported-by: Felix Wilhelm <fwilhelm@google.com>
+Cc: stable@vger.kernel.org
+Fixes: 2fcf4876ada ("KVM: nSVM: implement on demand allocation of the nested state")
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/nested.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/kvm/svm/nested.c
++++ b/arch/x86/kvm/svm/nested.c
+@@ -246,7 +246,7 @@ static bool nested_vmcb_check_controls(s
+ return true;
+ }
+
+-static bool nested_vmcb_checks(struct vcpu_svm *svm, struct vmcb *vmcb12)
++static bool nested_vmcb_check_save(struct vcpu_svm *svm, struct vmcb *vmcb12)
+ {
+ struct kvm_vcpu *vcpu = &svm->vcpu;
+ bool vmcb12_lma;
+@@ -271,7 +271,7 @@ static bool nested_vmcb_checks(struct vc
+ if (kvm_valid_cr4(&svm->vcpu, vmcb12->save.cr4))
+ return false;
+
+- return nested_vmcb_check_controls(&vmcb12->control);
++ return true;
+ }
+
+ static void load_nested_vmcb_control(struct vcpu_svm *svm,
+@@ -454,7 +454,6 @@ int enter_svm_guest_mode(struct vcpu_svm
+ int ret;
+
+ svm->nested.vmcb12_gpa = vmcb12_gpa;
+- load_nested_vmcb_control(svm, &vmcb12->control);
+ nested_prepare_vmcb_save(svm, vmcb12);
+ nested_prepare_vmcb_control(svm);
+
+@@ -501,7 +500,10 @@ int nested_svm_vmrun(struct vcpu_svm *sv
+ if (WARN_ON_ONCE(!svm->nested.initialized))
+ return -EINVAL;
+
+- if (!nested_vmcb_checks(svm, vmcb12)) {
++ load_nested_vmcb_control(svm, &vmcb12->control);
++
++ if (!nested_vmcb_check_save(svm, vmcb12) ||
++ !nested_vmcb_check_controls(&svm->nested.ctl)) {
+ vmcb12->control.exit_code = SVM_EXIT_ERR;
+ vmcb12->control.exit_code_hi = 0;
+ vmcb12->control.exit_info_1 = 0;
--- /dev/null
+From c0c33442f7203704aef345647e14c2fb86071001 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 26 Mar 2021 12:56:18 +0200
+Subject: PM: runtime: Fix ordering in pm_runtime_get_suppliers()
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit c0c33442f7203704aef345647e14c2fb86071001 upstream.
+
+rpm_active indicates how many times the supplier usage_count has been
+incremented. Consequently it must be updated after pm_runtime_get_sync() of
+the supplier, not before.
+
+Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance")
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/power/runtime.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/base/power/runtime.c
++++ b/drivers/base/power/runtime.c
+@@ -1690,8 +1690,8 @@ void pm_runtime_get_suppliers(struct dev
+ device_links_read_lock_held())
+ if (link->flags & DL_FLAG_PM_RUNTIME) {
+ link->supplier_preactivated = true;
+- refcount_inc(&link->rpm_active);
+ pm_runtime_get_sync(link->supplier);
++ refcount_inc(&link->rpm_active);
+ }
+
+ device_links_read_unlock(idx);
--- /dev/null
+From 9dfacc54a8661bc8be6e08cffee59596ec59f263 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 26 Mar 2021 12:56:19 +0200
+Subject: PM: runtime: Fix race getting/putting suppliers at probe
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 9dfacc54a8661bc8be6e08cffee59596ec59f263 upstream.
+
+pm_runtime_put_suppliers() must not decrement rpm_active unless the
+consumer is suspended. That is because, otherwise, it could suspend
+suppliers for an active consumer.
+
+That can happen as follows:
+
+ static int driver_probe_device(struct device_driver *drv, struct device *dev)
+ {
+ int ret = 0;
+
+ if (!device_is_registered(dev))
+ return -ENODEV;
+
+ dev->can_match = true;
+ pr_debug("bus: '%s': %s: matched device %s with driver %s\n",
+ drv->bus->name, __func__, dev_name(dev), drv->name);
+
+ pm_runtime_get_suppliers(dev);
+ if (dev->parent)
+ pm_runtime_get_sync(dev->parent);
+
+ At this point, dev can runtime suspend so rpm_put_suppliers() can run,
+ rpm_active becomes 1 (the lowest value).
+
+ pm_runtime_barrier(dev);
+ if (initcall_debug)
+ ret = really_probe_debug(dev, drv);
+ else
+ ret = really_probe(dev, drv);
+
+ Probe callback can have runtime resumed dev, and then runtime put
+ so dev is awaiting autosuspend, but rpm_active is 2.
+
+ pm_request_idle(dev);
+
+ if (dev->parent)
+ pm_runtime_put(dev->parent);
+
+ pm_runtime_put_suppliers(dev);
+
+ Now pm_runtime_put_suppliers() will put the supplier
+ i.e. rpm_active 2 -> 1, but consumer can still be active.
+
+ return ret;
+ }
+
+Fix by checking the runtime status. For any status other than
+RPM_SUSPENDED, rpm_active can be considered to be "owned" by
+rpm_[get/put]_suppliers() and pm_runtime_put_suppliers() need do nothing.
+
+Reported-by: Asutosh Das <asutoshd@codeaurora.org>
+Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance")
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/base/power/runtime.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/base/power/runtime.c
++++ b/drivers/base/power/runtime.c
+@@ -1704,6 +1704,8 @@ void pm_runtime_get_suppliers(struct dev
+ void pm_runtime_put_suppliers(struct device *dev)
+ {
+ struct device_link *link;
++ unsigned long flags;
++ bool put;
+ int idx;
+
+ idx = device_links_read_lock();
+@@ -1712,7 +1714,11 @@ void pm_runtime_put_suppliers(struct dev
+ device_links_read_lock_held())
+ if (link->supplier_preactivated) {
+ link->supplier_preactivated = false;
+- if (refcount_dec_not_one(&link->rpm_active))
++ spin_lock_irqsave(&dev->power.lock, flags);
++ put = pm_runtime_status_suspended(dev) &&
++ refcount_dec_not_one(&link->rpm_active);
++ spin_unlock_irqrestore(&dev->power.lock, flags);
++ if (put)
+ pm_runtime_put(link->supplier);
+ }
+
--- /dev/null
+From 72bbc226ed2ef0a46c165a482861fff00dd6d4e1 Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <hca@linux.ibm.com>
+Date: Tue, 23 Mar 2021 21:40:11 +0100
+Subject: s390/vdso: copy tod_steering_delta value to vdso_data page
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+commit 72bbc226ed2ef0a46c165a482861fff00dd6d4e1 upstream.
+
+When converting the vdso assembler code to C it was forgotten to
+actually copy the tod_steering_delta value to vdso_data page.
+
+Which in turn means that tod clock steering will not work correctly.
+
+Fix this by simply copying the value whenever it is updated.
+
+Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
+Cc: <stable@vger.kernel.org> # 5.10
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/kernel/time.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/s390/kernel/time.c
++++ b/arch/s390/kernel/time.c
+@@ -398,6 +398,7 @@ static void clock_sync_global(unsigned l
+ tod_steering_delta);
+ tod_steering_end = now + (abs(tod_steering_delta) << 15);
+ vdso_data->arch_data.tod_steering_end = tod_steering_end;
++ vdso_data->arch_data.tod_steering_delta = tod_steering_delta;
+
+ /* Update LPAR offset. */
+ if (ptff_query(PTFF_QTO) && ptff(&qto, sizeof(qto), PTFF_QTO) == 0)
--- /dev/null
+From b24bacd67ffddd9192c4745500fd6f73dbfe565e Mon Sep 17 00:00:00 2001
+From: Heiko Carstens <hca@linux.ibm.com>
+Date: Wed, 24 Mar 2021 20:22:42 +0100
+Subject: s390/vdso: fix tod_steering_delta type
+
+From: Heiko Carstens <hca@linux.ibm.com>
+
+commit b24bacd67ffddd9192c4745500fd6f73dbfe565e upstream.
+
+The s390 specific vdso function __arch_get_hw_counter() is supposed to
+consider tod clock steering.
+
+If a tod clock steering event happens and the tod clock is set to a
+new value __arch_get_hw_counter() will not return the real tod clock
+value but slowly drift it from the old delta until the returned value
+finally matches the real tod clock value again.
+
+Unfortunately the type of tod_steering_delta unsigned while it is
+supposed to be signed. It depends on if tod_steering_delta is negative
+or positive in which direction the vdso code drifts the clock value.
+
+Worst case is now that instead of drifting the clock slowly it will
+jump into the opposite direction by a factor of two.
+
+Fix this by simply making tod_steering_delta signed.
+
+Fixes: 4bff8cb54502 ("s390: convert to GENERIC_VDSO")
+Cc: <stable@vger.kernel.org> # 5.10
+Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/s390/include/asm/vdso/data.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/s390/include/asm/vdso/data.h
++++ b/arch/s390/include/asm/vdso/data.h
+@@ -6,7 +6,7 @@
+ #include <vdso/datapage.h>
+
+ struct arch_vdso_data {
+- __u64 tod_steering_delta;
++ __s64 tod_steering_delta;
+ __u64 tod_steering_end;
+ };
+
net-ipa-fix-register-write-command-validation.patch
net-wan-lmc-unregister-device-when-no-matching-devic.patch
net-9p-advance-iov-on-empty-read.patch
+bpf-remove-mtu-check-in-__bpf_skb_max_len.patch
+acpi-tables-x86-reserve-memory-occupied-by-acpi-tables.patch
+acpi-processor-fix-cpu0-wakeup-in-acpi_idle_play_dead.patch
+alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch
+alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch
+alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch
+alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch
+alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch
+alsa-hda-realtek-fix-mute-micmute-leds-for-hp-640-g8.patch
+xtensa-fix-uaccess-related-livelock-in-do_page_fault.patch
+xtensa-move-coprocessor_flush-to-the-.text-section.patch
+kvm-svm-load-control-fields-from-vmcb12-before-checking-them.patch
+kvm-svm-ensure-that-efer.svme-is-set-when-running-nested-guest-or-on-nested-vmexit.patch
+pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch
+pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch
+tracing-fix-stack-trace-event-size.patch
+s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch
+s390-vdso-fix-tod_steering_delta-type.patch
--- /dev/null
+From 9deb193af69d3fd6dd8e47f292b67c805a787010 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 1 Apr 2021 13:54:40 -0400
+Subject: tracing: Fix stack trace event size
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 9deb193af69d3fd6dd8e47f292b67c805a787010 upstream.
+
+Commit cbc3b92ce037 fixed an issue to modify the macros of the stack trace
+event so that user space could parse it properly. Originally the stack
+trace format to user space showed that the called stack was a dynamic
+array. But it is not actually a dynamic array, in the way that other
+dynamic event arrays worked, and this broke user space parsing for it. The
+update was to make the array look to have 8 entries in it. Helper
+functions were added to make it parse it correctly, as the stack was
+dynamic, but was determined by the size of the event stored.
+
+Although this fixed user space on how it read the event, it changed the
+internal structure used for the stack trace event. It changed the array
+size from [0] to [8] (added 8 entries). This increased the size of the
+stack trace event by 8 words. The size reserved on the ring buffer was the
+size of the stack trace event plus the number of stack entries found in
+the stack trace. That commit caused the amount to be 8 more than what was
+needed because it did not expect the caller field to have any size. This
+produced 8 entries of garbage (and reading random data) from the stack
+trace event:
+
+ <idle>-0 [002] d... 1976396.837549: <stack trace>
+ => trace_event_raw_event_sched_switch
+ => __traceiter_sched_switch
+ => __schedule
+ => schedule_idle
+ => do_idle
+ => cpu_startup_entry
+ => secondary_startup_64_no_verify
+ => 0xc8c5e150ffff93de
+ => 0xffff93de
+ => 0
+ => 0
+ => 0xc8c5e17800000000
+ => 0x1f30affff93de
+ => 0x00000004
+ => 0x200000000
+
+Instead, subtract the size of the caller field from the size of the event
+to make sure that only the amount needed to store the stack trace is
+reserved.
+
+Link: https://lore.kernel.org/lkml/your-ad-here.call-01617191565-ext-9692@work.hours/
+
+Cc: stable@vger.kernel.org
+Fixes: cbc3b92ce037 ("tracing: Set kernel_stack's caller size properly")
+Reported-by: Vasily Gorbik <gor@linux.ibm.com>
+Tested-by: Vasily Gorbik <gor@linux.ibm.com>
+Acked-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -2984,7 +2984,8 @@ static void __ftrace_trace_stack(struct
+
+ size = nr_entries * sizeof(unsigned long);
+ event = __trace_buffer_lock_reserve(buffer, TRACE_STACK,
+- sizeof(*entry) + size, flags, pc);
++ (sizeof(*entry) - sizeof(entry->caller)) + size,
++ flags, pc);
+ if (!event)
+ goto out;
+ entry = ring_buffer_event_data(event);
--- /dev/null
+From 7b9acbb6aad4f54623dcd4bd4b1a60fe0c727b09 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Sun, 7 Feb 2021 04:57:58 -0800
+Subject: xtensa: fix uaccess-related livelock in do_page_fault
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit 7b9acbb6aad4f54623dcd4bd4b1a60fe0c727b09 upstream.
+
+If a uaccess (e.g. get_user()) triggers a fault and there's a
+fault signal pending, the handler will return to the uaccess without
+having performed a uaccess fault fixup, and so the CPU will immediately
+execute the uaccess instruction again, whereupon it will livelock
+bouncing between that instruction and the fault handler.
+
+https://lore.kernel.org/lkml/20210121123140.GD48431@C02TD0UTHF1T.local/
+
+Cc: stable@vger.kernel.org
+Reported-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/xtensa/mm/fault.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/arch/xtensa/mm/fault.c
++++ b/arch/xtensa/mm/fault.c
+@@ -112,8 +112,11 @@ good_area:
+ */
+ fault = handle_mm_fault(vma, address, flags, regs);
+
+- if (fault_signal_pending(fault, regs))
++ if (fault_signal_pending(fault, regs)) {
++ if (!user_mode(regs))
++ goto bad_page_fault;
+ return;
++ }
+
+ if (unlikely(fault & VM_FAULT_ERROR)) {
+ if (fault & VM_FAULT_OOM)
--- /dev/null
+From ab5eb336411f18fd449a1fb37d36a55ec422603f Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Thu, 25 Feb 2021 11:42:46 -0800
+Subject: xtensa: move coprocessor_flush to the .text section
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit ab5eb336411f18fd449a1fb37d36a55ec422603f upstream.
+
+coprocessor_flush is not a part of fast exception handlers, but it uses
+parts of fast coprocessor handling code that's why it's in the same
+source file. It uses call0 opcode to invoke those parts so there are no
+limitations on their relative location, but the rest of the code calls
+coprocessor_flush with call8 and that doesn't work when vectors are
+placed in a different gigabyte-aligned area than the rest of the kernel.
+
+Move coprocessor_flush from the .exception.text section to the .text so
+that it's reachable from the rest of the kernel with call8.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/xtensa/kernel/coprocessor.S | 64 ++++++++++++++++++++-------------------
+ 1 file changed, 33 insertions(+), 31 deletions(-)
+
+--- a/arch/xtensa/kernel/coprocessor.S
++++ b/arch/xtensa/kernel/coprocessor.S
+@@ -100,37 +100,6 @@
+ LOAD_CP_REGS_TAB(7)
+
+ /*
+- * coprocessor_flush(struct thread_info*, index)
+- * a2 a3
+- *
+- * Save coprocessor registers for coprocessor 'index'.
+- * The register values are saved to or loaded from the coprocessor area
+- * inside the task_info structure.
+- *
+- * Note that this function doesn't update the coprocessor_owner information!
+- *
+- */
+-
+-ENTRY(coprocessor_flush)
+-
+- /* reserve 4 bytes on stack to save a0 */
+- abi_entry(4)
+-
+- s32i a0, a1, 0
+- movi a0, .Lsave_cp_regs_jump_table
+- addx8 a3, a3, a0
+- l32i a4, a3, 4
+- l32i a3, a3, 0
+- add a2, a2, a4
+- beqz a3, 1f
+- callx0 a3
+-1: l32i a0, a1, 0
+-
+- abi_ret(4)
+-
+-ENDPROC(coprocessor_flush)
+-
+-/*
+ * Entry condition:
+ *
+ * a0: trashed, original value saved on stack (PT_AREG0)
+@@ -245,6 +214,39 @@ ENTRY(fast_coprocessor)
+
+ ENDPROC(fast_coprocessor)
+
++ .text
++
++/*
++ * coprocessor_flush(struct thread_info*, index)
++ * a2 a3
++ *
++ * Save coprocessor registers for coprocessor 'index'.
++ * The register values are saved to or loaded from the coprocessor area
++ * inside the task_info structure.
++ *
++ * Note that this function doesn't update the coprocessor_owner information!
++ *
++ */
++
++ENTRY(coprocessor_flush)
++
++ /* reserve 4 bytes on stack to save a0 */
++ abi_entry(4)
++
++ s32i a0, a1, 0
++ movi a0, .Lsave_cp_regs_jump_table
++ addx8 a3, a3, a0
++ l32i a4, a3, 4
++ l32i a3, a3, 0
++ add a2, a2, a4
++ beqz a3, 1f
++ callx0 a3
++1: l32i a0, a1, 0
++
++ abi_ret(4)
++
++ENDPROC(coprocessor_flush)
++
+ .data
+
+ ENTRY(coprocessor_owner)
projects / thirdparty / kernel / stable-queue.git / commitdiff
