From 9f79ad6b2c278b69fed5ce22955904ebd428ea8e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 3 Apr 2021 10:35:19 +0200 Subject: [PATCH] 5.11-stable patches added patches: acpi-processor-fix-cpu0-wakeup-in-acpi_idle_play_dead.patch acpi-scan-fix-_sta-getting-called-on-devices-with-unmet-dependencies.patch acpi-tables-x86-reserve-memory-occupied-by-acpi-tables.patch alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch alsa-hda-realtek-fix-mute-micmute-leds-for-hp-640-g8.patch alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch bpf-remove-mtu-check-in-__bpf_skb_max_len.patch drm-ttm-make-ttm_bo_unpin-more-defensive.patch kvm-svm-ensure-that-efer.svme-is-set-when-running-nested-guest-or-on-nested-vmexit.patch kvm-svm-load-control-fields-from-vmcb12-before-checking-them.patch pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch s390-vdso-fix-tod_steering_delta-type.patch tracing-fix-stack-trace-event-size.patch xtensa-fix-uaccess-related-livelock-in-do_page_fault.patch xtensa-move-coprocessor_flush-to-the-.text-section.patch --- ...x-cpu0-wakeup-in-acpi_idle_play_dead.patch | 96 ++++++++ ...d-on-devices-with-unmet-dependencies.patch | 83 +++++++ ...serve-memory-occupied-by-acpi-tables.patch | 225 ++++++++++++++++++ ...cks-in-pm-prepare-complete-callbacks.patch | 47 ++++ ...dropped-snd_poewr_change_state-calls.patch | 44 ++++ ...ate_headset_mode-in-hp_automute_hook.patch | 46 ++++ ...ne_headset_type-issue-for-a-dell-aio.patch | 47 ++++ ...-fix-mute-micmute-leds-for-hp-640-g8.patch | 32 +++ ...ample-rate-quirk-to-logitech-connect.patch | 35 +++ ...emove-mtu-check-in-__bpf_skb_max_len.patch | 83 +++++++ ...ttm-make-ttm_bo_unpin-more-defensive.patch | 38 +++ ...ing-nested-guest-or-on-nested-vmexit.patch | 70 ++++++ ...lds-from-vmcb12-before-checking-them.patch | 66 +++++ ...ordering-in-pm_runtime_get_suppliers.patch | 34 +++ ...e-getting-putting-suppliers-at-probe.patch | 93 ++++++++ ...eering_delta-value-to-vdso_data-page.patch | 34 +++ ...390-vdso-fix-tod_steering_delta-type.patch | 45 ++++ queue-5.11/series | 20 ++ .../tracing-fix-stack-trace-event-size.patch | 74 ++++++ ...ss-related-livelock-in-do_page_fault.patch | 40 ++++ ...processor_flush-to-the-.text-section.patch | 106 +++++++++ 21 files changed, 1358 insertions(+) create mode 100644 queue-5.11/acpi-processor-fix-cpu0-wakeup-in-acpi_idle_play_dead.patch create mode 100644 queue-5.11/acpi-scan-fix-_sta-getting-called-on-devices-with-unmet-dependencies.patch create mode 100644 queue-5.11/acpi-tables-x86-reserve-memory-occupied-by-acpi-tables.patch create mode 100644 queue-5.11/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch create mode 100644 queue-5.11/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch create mode 100644 queue-5.11/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch create mode 100644 queue-5.11/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch create mode 100644 queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-640-g8.patch create mode 100644 queue-5.11/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch create mode 100644 queue-5.11/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch create mode 100644 queue-5.11/drm-ttm-make-ttm_bo_unpin-more-defensive.patch create mode 100644 queue-5.11/kvm-svm-ensure-that-efer.svme-is-set-when-running-nested-guest-or-on-nested-vmexit.patch create mode 100644 queue-5.11/kvm-svm-load-control-fields-from-vmcb12-before-checking-them.patch create mode 100644 queue-5.11/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch create mode 100644 queue-5.11/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch create mode 100644 queue-5.11/s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch create mode 100644 queue-5.11/s390-vdso-fix-tod_steering_delta-type.patch create mode 100644 queue-5.11/tracing-fix-stack-trace-event-size.patch create mode 100644 queue-5.11/xtensa-fix-uaccess-related-livelock-in-do_page_fault.patch create mode 100644 queue-5.11/xtensa-move-coprocessor_flush-to-the-.text-section.patch diff --git a/queue-5.11/acpi-processor-fix-cpu0-wakeup-in-acpi_idle_play_dead.patch b/queue-5.11/acpi-processor-fix-cpu0-wakeup-in-acpi_idle_play_dead.patch new file mode 100644 index 00000000000..98e8ac67697 --- /dev/null +++ b/queue-5.11/acpi-processor-fix-cpu0-wakeup-in-acpi_idle_play_dead.patch @@ -0,0 +1,96 @@ +From 8cdddd182bd7befae6af49c5fd612893f55d6ccb Mon Sep 17 00:00:00 2001 +From: Vitaly Kuznetsov +Date: Wed, 24 Mar 2021 16:22:19 +0100 +Subject: ACPI: processor: Fix CPU0 wakeup in acpi_idle_play_dead() + +From: Vitaly Kuznetsov + +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 +Cc: 5.10+ # 5.10+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1659,7 +1659,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 ++#include + #endif + + #define _COMPONENT ACPI_PROCESSOR_COMPONENT +@@ -541,6 +542,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 */ diff --git a/queue-5.11/acpi-scan-fix-_sta-getting-called-on-devices-with-unmet-dependencies.patch b/queue-5.11/acpi-scan-fix-_sta-getting-called-on-devices-with-unmet-dependencies.patch new file mode 100644 index 00000000000..41450867b5f --- /dev/null +++ b/queue-5.11/acpi-scan-fix-_sta-getting-called-on-devices-with-unmet-dependencies.patch @@ -0,0 +1,83 @@ +From 3e759425cc3cf9a43392309819d34c65a3644c59 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Tue, 30 Mar 2021 20:49:32 +0200 +Subject: ACPI: scan: Fix _STA getting called on devices with unmet dependencies + +From: Hans de Goede + +commit 3e759425cc3cf9a43392309819d34c65a3644c59 upstream. + +Commit 71da201f38df ("ACPI: scan: Defer enumeration of devices with +_DEP lists") dropped the following 2 lines from acpi_init_device_object(): + + /* Assume there are unmet deps until acpi_device_dep_initialize() runs */ + device->dep_unmet = 1; + +Leaving the initial value of dep_unmet at the 0 from the kzalloc(). This +causes the acpi_bus_get_status() call in acpi_add_single_object() to +actually call _STA, even though there maybe unmet deps, leading to errors +like these: + +[ 0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c) + [GenericSerialBus] (20170831/evregion-166) +[ 0.123601] ACPI Error: Region GenericSerialBus (ID=9) has no handler + (20170831/exfldio-299) +[ 0.123618] ACPI Error: Method parse/execution failed + \_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550) + +Fix this by re-adding the dep_unmet = 1 initialization to +acpi_init_device_object() and modifying acpi_bus_check_add() to make sure +that dep_unmet always gets setup there, overriding the initial 1 value. + +This re-fixes the issue initially fixed by +commit 63347db0affa ("ACPI / scan: Use acpi_bus_get_status() to initialize +ACPI_TYPE_DEVICE devs"), which introduced the removed +"device->dep_unmet = 1;" statement. + +This issue was noticed; and the fix tested on a Dell Venue 10 Pro 5055. + +Fixes: 71da201f38df ("ACPI: scan: Defer enumeration of devices with _DEP lists") +Suggested-by: Rafael J. Wysocki +Signed-off-by: Hans de Goede +Cc: 5.11+ # 5.11+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/acpi/scan.c | 12 +++++++++++- + 1 file changed, 11 insertions(+), 1 deletion(-) + +--- a/drivers/acpi/scan.c ++++ b/drivers/acpi/scan.c +@@ -1669,6 +1669,8 @@ void acpi_init_device_object(struct acpi + device_initialize(&device->dev); + dev_set_uevent_suppress(&device->dev, true); + acpi_init_coherency(device); ++ /* Assume there are unmet deps to start with. */ ++ device->dep_unmet = 1; + } + + void acpi_device_add_finalize(struct acpi_device *device) +@@ -1934,6 +1936,8 @@ static void acpi_scan_dep_init(struct ac + { + struct acpi_dep_data *dep; + ++ adev->dep_unmet = 0; ++ + mutex_lock(&acpi_dep_list_lock); + + list_for_each_entry(dep, &acpi_dep_list, node) { +@@ -1981,7 +1985,13 @@ static acpi_status acpi_bus_check_add(ac + return AE_CTRL_DEPTH; + + acpi_scan_init_hotplug(device); +- if (!check_dep) ++ /* ++ * If check_dep is true at this point, the device has no dependencies, ++ * or the creation of the device object would have been postponed above. ++ */ ++ if (check_dep) ++ device->dep_unmet = 0; ++ else + acpi_scan_dep_init(device); + + out: diff --git a/queue-5.11/acpi-tables-x86-reserve-memory-occupied-by-acpi-tables.patch b/queue-5.11/acpi-tables-x86-reserve-memory-occupied-by-acpi-tables.patch new file mode 100644 index 00000000000..4fd0536ea25 --- /dev/null +++ b/queue-5.11/acpi-tables-x86-reserve-memory-occupied-by-acpi-tables.patch @@ -0,0 +1,225 @@ +From 1a1c130ab7575498eed5bcf7220037ae09cd1f8a Mon Sep 17 00:00:00 2001 +From: "Rafael J. Wysocki" +Date: Tue, 23 Mar 2021 20:26:52 +0100 +Subject: ACPI: tables: x86: Reserve memory occupied by ACPI tables + +From: Rafael J. Wysocki + +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 +Tested-by: George Kennedy +Signed-off-by: Rafael J. Wysocki +Reviewed-by: Mike Rapoport +Cc: 5.10+ # 5.10+ +Signed-off-by: Greg Kroah-Hartman +--- + 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 +@@ -1046,6 +1046,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(); + +@@ -1137,11 +1140,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) diff --git a/queue-5.11/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch b/queue-5.11/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch new file mode 100644 index 00000000000..d2b8ad0841c --- /dev/null +++ b/queue-5.11/alsa-hda-add-missing-sanity-checks-in-pm-prepare-complete-callbacks.patch @@ -0,0 +1,47 @@ +From 66affb7bb0dc0905155a1b2475261aa704d1ddb5 Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 29 Mar 2021 13:30:59 +0200 +Subject: ALSA: hda: Add missing sanity checks in PM prepare/complete callbacks + +From: Takashi Iwai + +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: +Link: https://lore.kernel.org/r/20210329113059.25035-2-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.11/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch b/queue-5.11/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch new file mode 100644 index 00000000000..aa1727060b9 --- /dev/null +++ b/queue-5.11/alsa-hda-re-add-dropped-snd_poewr_change_state-calls.patch @@ -0,0 +1,44 @@ +From c8f79808cd8eb5bc8d14de129bd6d586d3fce0aa Mon Sep 17 00:00:00 2001 +From: Takashi Iwai +Date: Mon, 29 Mar 2021 13:30:58 +0200 +Subject: ALSA: hda: Re-add dropped snd_poewr_change_state() calls + +From: Takashi Iwai + +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: +Link: https://lore.kernel.org/r/20210329113059.25035-1-tiwai@suse.de +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.11/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch b/queue-5.11/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch new file mode 100644 index 00000000000..fe541a80bdc --- /dev/null +++ b/queue-5.11/alsa-hda-realtek-call-alc_update_headset_mode-in-hp_automute_hook.patch @@ -0,0 +1,46 @@ +From e54f30befa7990b897189b44a56c1138c6bfdbb5 Mon Sep 17 00:00:00 2001 +From: Hui Wang +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 + +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: +Signed-off-by: Hui Wang +Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.11/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch b/queue-5.11/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch new file mode 100644 index 00000000000..bf80141eef2 --- /dev/null +++ b/queue-5.11/alsa-hda-realtek-fix-a-determine_headset_type-issue-for-a-dell-aio.patch @@ -0,0 +1,47 @@ +From febf22565549ea7111e7d45e8f2d64373cc66b11 Mon Sep 17 00:00:00 2001 +From: Hui Wang +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 + +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: +Signed-off-by: Hui Wang +Link: https://lore.kernel.org/r/20210320091542.6748-1-hui.wang@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; diff --git a/queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-640-g8.patch b/queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-640-g8.patch new file mode 100644 index 00000000000..caac16b057c --- /dev/null +++ b/queue-5.11/alsa-hda-realtek-fix-mute-micmute-leds-for-hp-640-g8.patch @@ -0,0 +1,32 @@ +From 417eadfdd9e25188465280edf3668ed163fda2d0 Mon Sep 17 00:00:00 2001 +From: Jeremy Szu +Date: Tue, 30 Mar 2021 19:44:27 +0800 +Subject: ALSA: hda/realtek: fix mute/micmute LEDs for HP 640 G8 + +From: Jeremy Szu + +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 +Cc: +Link: https://lore.kernel.org/r/20210330114428.40490-1-jeremy.szu@canonical.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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), diff --git a/queue-5.11/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch b/queue-5.11/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch new file mode 100644 index 00000000000..555d95875f3 --- /dev/null +++ b/queue-5.11/alsa-usb-audio-apply-sample-rate-quirk-to-logitech-connect.patch @@ -0,0 +1,35 @@ +From 625bd5a616ceda4840cd28f82e957c8ced394b6a Mon Sep 17 00:00:00 2001 +From: Ikjoon Jang +Date: Wed, 24 Mar 2021 18:51:52 +0800 +Subject: ALSA: usb-audio: Apply sample rate quirk to Logitech Connect + +From: Ikjoon Jang + +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 +Cc: +Link: https://lore.kernel.org/r/20210324105153.2322881-1-ikjn@chromium.org +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + diff --git a/queue-5.11/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch b/queue-5.11/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch new file mode 100644 index 00000000000..973444f19cc --- /dev/null +++ b/queue-5.11/bpf-remove-mtu-check-in-__bpf_skb_max_len.patch @@ -0,0 +1,83 @@ +From 6306c1189e77a513bf02720450bb43bd4ba5d8ae Mon Sep 17 00:00:00 2001 +From: Jesper Dangaard Brouer +Date: Tue, 9 Feb 2021 14:38:09 +0100 +Subject: bpf: Remove MTU check in __bpf_skb_max_len + +From: Jesper Dangaard Brouer + +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 +Signed-off-by: Daniel Borkmann +Acked-by: John Fastabend +Link: https://lore.kernel.org/bpf/161287788936.790810.2937823995775097177.stgit@firesoul +Signed-off-by: Greg Kroah-Hartman +--- + 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; + diff --git a/queue-5.11/drm-ttm-make-ttm_bo_unpin-more-defensive.patch b/queue-5.11/drm-ttm-make-ttm_bo_unpin-more-defensive.patch new file mode 100644 index 00000000000..29939753872 --- /dev/null +++ b/queue-5.11/drm-ttm-make-ttm_bo_unpin-more-defensive.patch @@ -0,0 +1,38 @@ +From 6c5403173a13a08ff61dbdafa4c0ed4a9dedbfe0 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= +Date: Fri, 12 Mar 2021 09:34:39 +0100 +Subject: drm/ttm: make ttm_bo_unpin more defensive +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian König + +commit 6c5403173a13a08ff61dbdafa4c0ed4a9dedbfe0 upstream. + +We seem to have some more driver bugs than thought. + +Signed-off-by: Christian König +Fixes: deb0814b43f3 ("drm/ttm: add ttm_bo_pin()/ttm_bo_unpin() v2") +Acked-by: Matthew Auld +Link: https://patchwork.freedesktop.org/patch/msgid/20210312093810.2202-1-christian.koenig@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + include/drm/ttm/ttm_bo_api.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/include/drm/ttm/ttm_bo_api.h ++++ b/include/drm/ttm/ttm_bo_api.h +@@ -612,8 +612,10 @@ static inline void ttm_bo_pin(struct ttm + static inline void ttm_bo_unpin(struct ttm_buffer_object *bo) + { + dma_resv_assert_held(bo->base.resv); +- WARN_ON_ONCE(!bo->pin_count); +- --bo->pin_count; ++ if (bo->pin_count) ++ --bo->pin_count; ++ else ++ WARN_ON_ONCE(true); + } + + int ttm_mem_evict_first(struct ttm_bo_device *bdev, diff --git a/queue-5.11/kvm-svm-ensure-that-efer.svme-is-set-when-running-nested-guest-or-on-nested-vmexit.patch b/queue-5.11/kvm-svm-ensure-that-efer.svme-is-set-when-running-nested-guest-or-on-nested-vmexit.patch new file mode 100644 index 00000000000..4d06b2ca20f --- /dev/null +++ b/queue-5.11/kvm-svm-ensure-that-efer.svme-is-set-when-running-nested-guest-or-on-nested-vmexit.patch @@ -0,0 +1,70 @@ +From 3c346c0c60ab06a021d1c0884a0ef494bc4ee3a7 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +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 + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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 | X86_EFLAGS_FIXED); +- 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; +@@ -1209,6 +1223,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 diff --git a/queue-5.11/kvm-svm-load-control-fields-from-vmcb12-before-checking-them.patch b/queue-5.11/kvm-svm-load-control-fields-from-vmcb12-before-checking-them.patch new file mode 100644 index 00000000000..70dc7081183 --- /dev/null +++ b/queue-5.11/kvm-svm-load-control-fields-from-vmcb12-before-checking-them.patch @@ -0,0 +1,66 @@ +From a58d9166a756a0f4a6618e4f593232593d6df134 Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Wed, 31 Mar 2021 06:24:43 -0400 +Subject: KVM: SVM: load control fields from VMCB12 before checking them + +From: Paolo Bonzini + +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 +Cc: stable@vger.kernel.org +Fixes: 2fcf4876ada ("KVM: nSVM: implement on demand allocation of the nested state") +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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_is_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; diff --git a/queue-5.11/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch b/queue-5.11/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch new file mode 100644 index 00000000000..e5e9575aaec --- /dev/null +++ b/queue-5.11/pm-runtime-fix-ordering-in-pm_runtime_get_suppliers.patch @@ -0,0 +1,34 @@ +From c0c33442f7203704aef345647e14c2fb86071001 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 26 Mar 2021 12:56:18 +0200 +Subject: PM: runtime: Fix ordering in pm_runtime_get_suppliers() + +From: Adrian Hunter + +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 +Cc: 5.1+ # 5.1+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.11/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch b/queue-5.11/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch new file mode 100644 index 00000000000..cd20d942ca9 --- /dev/null +++ b/queue-5.11/pm-runtime-fix-race-getting-putting-suppliers-at-probe.patch @@ -0,0 +1,93 @@ +From 9dfacc54a8661bc8be6e08cffee59596ec59f263 Mon Sep 17 00:00:00 2001 +From: Adrian Hunter +Date: Fri, 26 Mar 2021 12:56:19 +0200 +Subject: PM: runtime: Fix race getting/putting suppliers at probe + +From: Adrian Hunter + +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 +Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance") +Signed-off-by: Adrian Hunter +Cc: 5.1+ # 5.1+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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); + } + diff --git a/queue-5.11/s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch b/queue-5.11/s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch new file mode 100644 index 00000000000..77ae93288da --- /dev/null +++ b/queue-5.11/s390-vdso-copy-tod_steering_delta-value-to-vdso_data-page.patch @@ -0,0 +1,34 @@ +From 72bbc226ed2ef0a46c165a482861fff00dd6d4e1 Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Tue, 23 Mar 2021 21:40:11 +0100 +Subject: s390/vdso: copy tod_steering_delta value to vdso_data page + +From: Heiko Carstens + +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: # 5.10 +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.11/s390-vdso-fix-tod_steering_delta-type.patch b/queue-5.11/s390-vdso-fix-tod_steering_delta-type.patch new file mode 100644 index 00000000000..6d27ab2f9f2 --- /dev/null +++ b/queue-5.11/s390-vdso-fix-tod_steering_delta-type.patch @@ -0,0 +1,45 @@ +From b24bacd67ffddd9192c4745500fd6f73dbfe565e Mon Sep 17 00:00:00 2001 +From: Heiko Carstens +Date: Wed, 24 Mar 2021 20:22:42 +0100 +Subject: s390/vdso: fix tod_steering_delta type + +From: Heiko Carstens + +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: # 5.10 +Signed-off-by: Heiko Carstens +Signed-off-by: Greg Kroah-Hartman +--- + 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 + + struct arch_vdso_data { +- __u64 tod_steering_delta; ++ __s64 tod_steering_delta; + __u64 tod_steering_end; + }; + diff --git a/queue-5.11/series b/queue-5.11/series index b03ff83a58a..2f1ff795c13 100644 --- a/queue-5.11/series +++ b/queue-5.11/series @@ -64,3 +64,23 @@ net-ipa-use-a-separate-pointer-for-adjusted-gsi-memo.patch 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 +acpi-scan-fix-_sta-getting-called-on-devices-with-unmet-dependencies.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 +drm-ttm-make-ttm_bo_unpin-more-defensive.patch diff --git a/queue-5.11/tracing-fix-stack-trace-event-size.patch b/queue-5.11/tracing-fix-stack-trace-event-size.patch new file mode 100644 index 00000000000..ca67d24ea0f --- /dev/null +++ b/queue-5.11/tracing-fix-stack-trace-event-size.patch @@ -0,0 +1,74 @@ +From 9deb193af69d3fd6dd8e47f292b67c805a787010 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Thu, 1 Apr 2021 13:54:40 -0400 +Subject: tracing: Fix stack trace event size + +From: Steven Rostedt (VMware) + +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: + + -0 [002] d... 1976396.837549: + => 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 +Tested-by: Vasily Gorbik +Acked-by: Vasily Gorbik +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.11/xtensa-fix-uaccess-related-livelock-in-do_page_fault.patch b/queue-5.11/xtensa-fix-uaccess-related-livelock-in-do_page_fault.patch new file mode 100644 index 00000000000..3f31df520fc --- /dev/null +++ b/queue-5.11/xtensa-fix-uaccess-related-livelock-in-do_page_fault.patch @@ -0,0 +1,40 @@ +From 7b9acbb6aad4f54623dcd4bd4b1a60fe0c727b09 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Sun, 7 Feb 2021 04:57:58 -0800 +Subject: xtensa: fix uaccess-related livelock in do_page_fault + +From: Max Filippov + +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 +Signed-off-by: Max Filippov +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.11/xtensa-move-coprocessor_flush-to-the-.text-section.patch b/queue-5.11/xtensa-move-coprocessor_flush-to-the-.text-section.patch new file mode 100644 index 00000000000..fc695b7c57c --- /dev/null +++ b/queue-5.11/xtensa-move-coprocessor_flush-to-the-.text-section.patch @@ -0,0 +1,106 @@ +From ab5eb336411f18fd449a1fb37d36a55ec422603f Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Thu, 25 Feb 2021 11:42:46 -0800 +Subject: xtensa: move coprocessor_flush to the .text section + +From: Max Filippov + +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 +Signed-off-by: Greg Kroah-Hartman +--- + 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) -- 2.47.3