From 72679a087bcf707326a2b435c7dae6dd09410c1e Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 13 Jun 2024 10:12:49 +0200 Subject: [PATCH] 6.6-stable patches added patches: bonding-fix-oops-during-rmmod.patch cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch hid-i2c-hid-elan-fix-reset-suspend-current-leakage.patch i2c-acpi-unbind-mux-adapters-before-delete.patch intel_th-pci-add-meteor-lake-s-cpu-support.patch kdb-fix-buffer-overflow-during-tab-complete.patch kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch kdb-merge-identical-case-statements-in-kdb_read.patch kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch mm-ksm-fix-ksm_pages_scanned-accounting.patch mm-ksm-fix-ksm_zero_pages-accounting.patch mm-proc-pid-smaps_rollup-avoid-skipping-vma-after-getting-mmap_lock-again.patch mm-vmalloc-fix-vmalloc-which-may-return-null-if-called-with-__gfp_nofail.patch net-9p-fix-uninit-value-in-p9_client_rpc.patch net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch rtla-timerlat-fix-histogram-report-when-a-cpu-count-is-0.patch scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch selftests-mm-compaction_test-fix-incorrect-write-of-zero-to-nr_hugepages.patch selftests-mm-fix-build-warnings-on-ppc64.patch sparc64-fix-number-of-online-cpus.patch tpm_tis-do-not-flush-uninitialized-work.patch watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch wifi-ath10k-fix-qcom_rproc_common-dependency.patch --- queue-6.6/bonding-fix-oops-during-rmmod.patch | 113 +++++++++++++ ...inconsistency-in-max-frequency-units.patch | 59 +++++++ ...an-fix-reset-suspend-current-leakage.patch | 159 ++++++++++++++++++ ...pi-unbind-mux-adapters-before-delete.patch | 153 +++++++++++++++++ ...th-pci-add-meteor-lake-s-cpu-support.patch | 34 ++++ ...-buffer-overflow-during-tab-complete.patch | 64 +++++++ ...-editing-and-tab-completing-commands.patch | 63 +++++++ ...dentical-case-statements-in-kdb_read.patch | 48 ++++++ ...-than-memset-for-padding-in-kdb_read.patch | 46 +++++ ...-rather-than-0-injection-in-kdb_read.patch | 127 ++++++++++++++ ...rigin-when-doing-partial-unpoisoning.patch | 68 ++++++++ ...nment-check-in-cma_init_reserved_mem.patch | 46 +++++ ...er_bit-to-cma_declare_contiguous_nid.patch | 58 +++++++ ...ksm-fix-ksm_pages_scanned-accounting.patch | 71 ++++++++ ...mm-ksm-fix-ksm_zero_pages-accounting.patch | 143 ++++++++++++++++ ...ng-vma-after-getting-mmap_lock-again.patch | 52 ++++++ ...urn-null-if-called-with-__gfp_nofail.patch | 109 ++++++++++++ ...9p-fix-uninit-value-in-p9_client_rpc.patch | 90 ++++++++++ ...eleting-failure-when-metric-equals-0.patch | 81 +++++++++ ...stogram-report-when-a-cpu-count-is-0.patch | 136 +++++++++++++++ ...rn-an-unusually-large-vpd-page-count.patch | 51 ++++++ ...orrect-write-of-zero-to-nr_hugepages.patch | 37 ++++ ...tests-mm-fix-build-warnings-on-ppc64.patch | 47 ++++++ queue-6.6/series | 27 +++ .../sparc64-fix-number-of-online-cpus.patch | 123 ++++++++++++++ ..._tis-do-not-flush-uninitialized-work.patch | 40 +++++ ...at_ms-to-accommodate-a-safety-margin.patch | 107 ++++++++++++ ...10k-fix-qcom_rproc_common-dependency.patch | 40 +++++ 28 files changed, 2192 insertions(+) create mode 100644 queue-6.6/bonding-fix-oops-during-rmmod.patch create mode 100644 queue-6.6/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch create mode 100644 queue-6.6/hid-i2c-hid-elan-fix-reset-suspend-current-leakage.patch create mode 100644 queue-6.6/i2c-acpi-unbind-mux-adapters-before-delete.patch create mode 100644 queue-6.6/intel_th-pci-add-meteor-lake-s-cpu-support.patch create mode 100644 queue-6.6/kdb-fix-buffer-overflow-during-tab-complete.patch create mode 100644 queue-6.6/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch create mode 100644 queue-6.6/kdb-merge-identical-case-statements-in-kdb_read.patch create mode 100644 queue-6.6/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch create mode 100644 queue-6.6/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch create mode 100644 queue-6.6/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch create mode 100644 queue-6.6/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch create mode 100644 queue-6.6/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch create mode 100644 queue-6.6/mm-ksm-fix-ksm_pages_scanned-accounting.patch create mode 100644 queue-6.6/mm-ksm-fix-ksm_zero_pages-accounting.patch create mode 100644 queue-6.6/mm-proc-pid-smaps_rollup-avoid-skipping-vma-after-getting-mmap_lock-again.patch create mode 100644 queue-6.6/mm-vmalloc-fix-vmalloc-which-may-return-null-if-called-with-__gfp_nofail.patch create mode 100644 queue-6.6/net-9p-fix-uninit-value-in-p9_client_rpc.patch create mode 100644 queue-6.6/net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch create mode 100644 queue-6.6/rtla-timerlat-fix-histogram-report-when-a-cpu-count-is-0.patch create mode 100644 queue-6.6/scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch create mode 100644 queue-6.6/selftests-mm-compaction_test-fix-incorrect-write-of-zero-to-nr_hugepages.patch create mode 100644 queue-6.6/selftests-mm-fix-build-warnings-on-ppc64.patch create mode 100644 queue-6.6/sparc64-fix-number-of-online-cpus.patch create mode 100644 queue-6.6/tpm_tis-do-not-flush-uninitialized-work.patch create mode 100644 queue-6.6/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch create mode 100644 queue-6.6/wifi-ath10k-fix-qcom_rproc_common-dependency.patch diff --git a/queue-6.6/bonding-fix-oops-during-rmmod.patch b/queue-6.6/bonding-fix-oops-during-rmmod.patch new file mode 100644 index 00000000000..3165885c972 --- /dev/null +++ b/queue-6.6/bonding-fix-oops-during-rmmod.patch @@ -0,0 +1,113 @@ +From a45835a0bb6ef7d5ddbc0714dd760de979cb6ece Mon Sep 17 00:00:00 2001 +From: Tony Battersby +Date: Tue, 14 May 2024 15:57:29 -0400 +Subject: bonding: fix oops during rmmod + +From: Tony Battersby + +commit a45835a0bb6ef7d5ddbc0714dd760de979cb6ece upstream. + +"rmmod bonding" causes an oops ever since commit cc317ea3d927 ("bonding: +remove redundant NULL check in debugfs function"). Here are the relevant +functions being called: + +bonding_exit() + bond_destroy_debugfs() + debugfs_remove_recursive(bonding_debug_root); + bonding_debug_root = NULL; <--------- SET TO NULL HERE + bond_netlink_fini() + rtnl_link_unregister() + __rtnl_link_unregister() + unregister_netdevice_many_notify() + bond_uninit() + bond_debug_unregister() + (commit removed check for bonding_debug_root == NULL) + debugfs_remove() + simple_recursive_removal() + down_write() -> OOPS + +However, reverting the bad commit does not solve the problem completely +because the original code contains a race that could cause the same +oops, although it was much less likely to be triggered unintentionally: + +CPU1 + rmmod bonding + bonding_exit() + bond_destroy_debugfs() + debugfs_remove_recursive(bonding_debug_root); + +CPU2 + echo -bond0 > /sys/class/net/bonding_masters + bond_uninit() + bond_debug_unregister() + if (!bonding_debug_root) + +CPU1 + bonding_debug_root = NULL; + +So do NOT revert the bad commit (since the removed checks were racy +anyway), and instead change the order of actions taken during module +removal. The same oops can also happen if there is an error during +module init, so apply the same fix there. + +Fixes: cc317ea3d927 ("bonding: remove redundant NULL check in debugfs function") +Cc: stable@vger.kernel.org +Signed-off-by: Tony Battersby +Reviewed-by: Simon Horman +Acked-by: Jay Vosburgh +Link: https://lore.kernel.org/r/641f914f-3216-4eeb-87dd-91b78aa97773@cybernetics.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/bonding/bond_main.c | 13 +++++++------ + 1 file changed, 7 insertions(+), 6 deletions(-) + +--- a/drivers/net/bonding/bond_main.c ++++ b/drivers/net/bonding/bond_main.c +@@ -6484,16 +6484,16 @@ static int __init bonding_init(void) + if (res) + goto out; + ++ bond_create_debugfs(); ++ + res = register_pernet_subsys(&bond_net_ops); + if (res) +- goto out; ++ goto err_net_ops; + + res = bond_netlink_init(); + if (res) + goto err_link; + +- bond_create_debugfs(); +- + for (i = 0; i < max_bonds; i++) { + res = bond_create(&init_net, NULL); + if (res) +@@ -6508,10 +6508,11 @@ static int __init bonding_init(void) + out: + return res; + err: +- bond_destroy_debugfs(); + bond_netlink_fini(); + err_link: + unregister_pernet_subsys(&bond_net_ops); ++err_net_ops: ++ bond_destroy_debugfs(); + goto out; + + } +@@ -6520,11 +6521,11 @@ static void __exit bonding_exit(void) + { + unregister_netdevice_notifier(&bond_netdev_notifier); + +- bond_destroy_debugfs(); +- + bond_netlink_fini(); + unregister_pernet_subsys(&bond_net_ops); + ++ bond_destroy_debugfs(); ++ + #ifdef CONFIG_NET_POLL_CONTROLLER + /* Make sure we don't have an imbalance on our netpoll blocking */ + WARN_ON(atomic_read(&netpoll_block_tx)); diff --git a/queue-6.6/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch b/queue-6.6/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch new file mode 100644 index 00000000000..133944db47f --- /dev/null +++ b/queue-6.6/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch @@ -0,0 +1,59 @@ +From e4731baaf29438508197d3a8a6d4f5a8c51663f8 Mon Sep 17 00:00:00 2001 +From: Dhananjay Ugwekar +Date: Mon, 27 May 2024 10:41:28 +0530 +Subject: cpufreq: amd-pstate: Fix the inconsistency in max frequency units + +From: Dhananjay Ugwekar + +commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream. + +The nominal frequency in cpudata is maintained in MHz whereas all other +frequencies are in KHz. This means we have to convert nominal frequency +value to KHz before we do any interaction with other frequency values. + +In amd_pstate_set_boost(), this conversion from MHz to KHz is missed, +fix that. + +Tested on a AMD Zen4 EPYC server + +Before: +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq +2151 +$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq +400000 +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq +2151 +409422 + +After: +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq +2151000 +$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq +400000 +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq +2151000 +1799527 + +Fixes: ec437d71db77 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors") +Signed-off-by: Dhananjay Ugwekar +Acked-by: Mario Limonciello +Acked-by: Gautham R. Shenoy +Tested-by: Peter Jung +Cc: 5.17+ # 5.17+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/amd-pstate.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/cpufreq/amd-pstate.c ++++ b/drivers/cpufreq/amd-pstate.c +@@ -675,7 +675,7 @@ static int amd_pstate_set_boost(struct c + if (state) + policy->cpuinfo.max_freq = cpudata->max_freq; + else +- policy->cpuinfo.max_freq = cpudata->nominal_freq; ++ policy->cpuinfo.max_freq = cpudata->nominal_freq * 1000; + + policy->max = policy->cpuinfo.max_freq; + diff --git a/queue-6.6/hid-i2c-hid-elan-fix-reset-suspend-current-leakage.patch b/queue-6.6/hid-i2c-hid-elan-fix-reset-suspend-current-leakage.patch new file mode 100644 index 00000000000..45a4e54fc6a --- /dev/null +++ b/queue-6.6/hid-i2c-hid-elan-fix-reset-suspend-current-leakage.patch @@ -0,0 +1,159 @@ +From 0eafc58f2194dbd01d4be40f99a697681171995b Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Tue, 7 May 2024 16:48:18 +0200 +Subject: HID: i2c-hid: elan: fix reset suspend current leakage + +From: Johan Hovold + +commit 0eafc58f2194dbd01d4be40f99a697681171995b upstream. + +The Elan eKTH5015M touch controller found on the Lenovo ThinkPad X13s +shares the VCC33 supply with other peripherals that may remain powered +during suspend (e.g. when enabled as wakeup sources). + +The reset line is also wired so that it can be left deasserted when the +supply is off. + +This is important as it avoids holding the controller in reset for +extended periods of time when it remains powered, which can lead to +increased power consumption, and also avoids leaking current through the +X13s reset circuitry during suspend (and after driver unbind). + +Use the new 'no-reset-on-power-off' devicetree property to determine +when reset needs to be asserted on power down. + +Notably this also avoids wasting power on machine variants without a +touchscreen for which the driver would otherwise exit probe with reset +asserted. + +Fixes: bd3cba00dcc6 ("HID: i2c-hid: elan: Add support for Elan eKTH6915 i2c-hid touchscreens") +Cc: # 6.0 +Cc: Douglas Anderson +Tested-by: Steev Klimaszewski +Signed-off-by: Johan Hovold +Reviewed-by: Douglas Anderson +Link: https://lore.kernel.org/r/20240507144821.12275-5-johan+linaro@kernel.org +Signed-off-by: Benjamin Tissoires +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/i2c-hid/i2c-hid-of-elan.c | 59 +++++++++++++++++++++++++++------- + 1 file changed, 47 insertions(+), 12 deletions(-) + +--- a/drivers/hid/i2c-hid/i2c-hid-of-elan.c ++++ b/drivers/hid/i2c-hid/i2c-hid-of-elan.c +@@ -31,6 +31,7 @@ struct i2c_hid_of_elan { + struct regulator *vcc33; + struct regulator *vccio; + struct gpio_desc *reset_gpio; ++ bool no_reset_on_power_off; + const struct elan_i2c_hid_chip_data *chip_data; + }; + +@@ -40,17 +41,17 @@ static int elan_i2c_hid_power_up(struct + container_of(ops, struct i2c_hid_of_elan, ops); + int ret; + ++ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1); ++ + if (ihid_elan->vcc33) { + ret = regulator_enable(ihid_elan->vcc33); + if (ret) +- return ret; ++ goto err_deassert_reset; + } + + ret = regulator_enable(ihid_elan->vccio); +- if (ret) { +- regulator_disable(ihid_elan->vcc33); +- return ret; +- } ++ if (ret) ++ goto err_disable_vcc33; + + if (ihid_elan->chip_data->post_power_delay_ms) + msleep(ihid_elan->chip_data->post_power_delay_ms); +@@ -60,6 +61,15 @@ static int elan_i2c_hid_power_up(struct + msleep(ihid_elan->chip_data->post_gpio_reset_on_delay_ms); + + return 0; ++ ++err_disable_vcc33: ++ if (ihid_elan->vcc33) ++ regulator_disable(ihid_elan->vcc33); ++err_deassert_reset: ++ if (ihid_elan->no_reset_on_power_off) ++ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0); ++ ++ return ret; + } + + static void elan_i2c_hid_power_down(struct i2chid_ops *ops) +@@ -67,7 +77,14 @@ static void elan_i2c_hid_power_down(stru + struct i2c_hid_of_elan *ihid_elan = + container_of(ops, struct i2c_hid_of_elan, ops); + +- gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1); ++ /* ++ * Do not assert reset when the hardware allows for it to remain ++ * deasserted regardless of the state of the (shared) power supply to ++ * avoid wasting power when the supply is left on. ++ */ ++ if (!ihid_elan->no_reset_on_power_off) ++ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 1); ++ + if (ihid_elan->chip_data->post_gpio_reset_off_delay_ms) + msleep(ihid_elan->chip_data->post_gpio_reset_off_delay_ms); + +@@ -79,6 +96,7 @@ static void elan_i2c_hid_power_down(stru + static int i2c_hid_of_elan_probe(struct i2c_client *client) + { + struct i2c_hid_of_elan *ihid_elan; ++ int ret; + + ihid_elan = devm_kzalloc(&client->dev, sizeof(*ihid_elan), GFP_KERNEL); + if (!ihid_elan) +@@ -93,21 +111,38 @@ static int i2c_hid_of_elan_probe(struct + if (IS_ERR(ihid_elan->reset_gpio)) + return PTR_ERR(ihid_elan->reset_gpio); + ++ ihid_elan->no_reset_on_power_off = of_property_read_bool(client->dev.of_node, ++ "no-reset-on-power-off"); ++ + ihid_elan->vccio = devm_regulator_get(&client->dev, "vccio"); +- if (IS_ERR(ihid_elan->vccio)) +- return PTR_ERR(ihid_elan->vccio); ++ if (IS_ERR(ihid_elan->vccio)) { ++ ret = PTR_ERR(ihid_elan->vccio); ++ goto err_deassert_reset; ++ } + + ihid_elan->chip_data = device_get_match_data(&client->dev); + + if (ihid_elan->chip_data->main_supply_name) { + ihid_elan->vcc33 = devm_regulator_get(&client->dev, + ihid_elan->chip_data->main_supply_name); +- if (IS_ERR(ihid_elan->vcc33)) +- return PTR_ERR(ihid_elan->vcc33); ++ if (IS_ERR(ihid_elan->vcc33)) { ++ ret = PTR_ERR(ihid_elan->vcc33); ++ goto err_deassert_reset; ++ } + } + +- return i2c_hid_core_probe(client, &ihid_elan->ops, +- ihid_elan->chip_data->hid_descriptor_address, 0); ++ ret = i2c_hid_core_probe(client, &ihid_elan->ops, ++ ihid_elan->chip_data->hid_descriptor_address, 0); ++ if (ret) ++ goto err_deassert_reset; ++ ++ return 0; ++ ++err_deassert_reset: ++ if (ihid_elan->no_reset_on_power_off) ++ gpiod_set_value_cansleep(ihid_elan->reset_gpio, 0); ++ ++ return ret; + } + + static const struct elan_i2c_hid_chip_data elan_ekth6915_chip_data = { diff --git a/queue-6.6/i2c-acpi-unbind-mux-adapters-before-delete.patch b/queue-6.6/i2c-acpi-unbind-mux-adapters-before-delete.patch new file mode 100644 index 00000000000..ca088070e9b --- /dev/null +++ b/queue-6.6/i2c-acpi-unbind-mux-adapters-before-delete.patch @@ -0,0 +1,153 @@ +From 3f858bbf04dbac934ac279aaee05d49eb9910051 Mon Sep 17 00:00:00 2001 +From: Hamish Martin +Date: Wed, 13 Mar 2024 11:16:32 +1300 +Subject: i2c: acpi: Unbind mux adapters before delete + +From: Hamish Martin + +commit 3f858bbf04dbac934ac279aaee05d49eb9910051 upstream. + +There is an issue with ACPI overlay table removal specifically related +to I2C multiplexers. + +Consider an ACPI SSDT Overlay that defines a PCA9548 I2C mux on an +existing I2C bus. When this table is loaded we see the creation of a +device for the overall PCA9548 chip and 8 further devices - one +i2c_adapter each for the mux channels. These are all bound to their +ACPI equivalents via an eventual invocation of acpi_bind_one(). + +When we unload the SSDT overlay we run into the problem. The ACPI +devices are deleted as normal via acpi_device_del_work_fn() and the +acpi_device_del_list. + +However, the following warning and stack trace is output as the +deletion does not go smoothly: +------------[ cut here ]------------ +kernfs: can not remove 'physical_node', no directory +WARNING: CPU: 1 PID: 11 at fs/kernfs/dir.c:1674 kernfs_remove_by_name_ns+0xb9/0xc0 +Modules linked in: +CPU: 1 PID: 11 Comm: kworker/u128:0 Not tainted 6.8.0-rc6+ #1 +Hardware name: congatec AG conga-B7E3/conga-B7E3, BIOS 5.13 05/16/2023 +Workqueue: kacpi_hotplug acpi_device_del_work_fn +RIP: 0010:kernfs_remove_by_name_ns+0xb9/0xc0 +Code: e4 00 48 89 ef e8 07 71 db ff 5b b8 fe ff ff ff 5d 41 5c 41 5d e9 a7 55 e4 00 0f 0b eb a6 48 c7 c7 f0 38 0d 9d e8 97 0a d5 ff <0f> 0b eb dc 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 +RSP: 0018:ffff9f864008fb28 EFLAGS: 00010286 +RAX: 0000000000000000 RBX: ffff8ef90a8d4940 RCX: 0000000000000000 +RDX: ffff8f000e267d10 RSI: ffff8f000e25c780 RDI: ffff8f000e25c780 +RBP: ffff8ef9186f9870 R08: 0000000000013ffb R09: 00000000ffffbfff +R10: 00000000ffffbfff R11: ffff8f000e0a0000 R12: ffff9f864008fb50 +R13: ffff8ef90c93dd60 R14: ffff8ef9010d0958 R15: ffff8ef9186f98c8 +FS: 0000000000000000(0000) GS:ffff8f000e240000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 00007f48f5253a08 CR3: 00000003cb82e000 CR4: 00000000003506f0 +Call Trace: + + ? kernfs_remove_by_name_ns+0xb9/0xc0 + ? __warn+0x7c/0x130 + ? kernfs_remove_by_name_ns+0xb9/0xc0 + ? report_bug+0x171/0x1a0 + ? handle_bug+0x3c/0x70 + ? exc_invalid_op+0x17/0x70 + ? asm_exc_invalid_op+0x1a/0x20 + ? kernfs_remove_by_name_ns+0xb9/0xc0 + ? kernfs_remove_by_name_ns+0xb9/0xc0 + acpi_unbind_one+0x108/0x180 + device_del+0x18b/0x490 + ? srso_return_thunk+0x5/0x5f + ? srso_return_thunk+0x5/0x5f + device_unregister+0xd/0x30 + i2c_del_adapter.part.0+0x1bf/0x250 + i2c_mux_del_adapters+0xa1/0xe0 + i2c_device_remove+0x1e/0x80 + device_release_driver_internal+0x19a/0x200 + bus_remove_device+0xbf/0x100 + device_del+0x157/0x490 + ? __pfx_device_match_fwnode+0x10/0x10 + ? srso_return_thunk+0x5/0x5f + device_unregister+0xd/0x30 + i2c_acpi_notify+0x10f/0x140 + notifier_call_chain+0x58/0xd0 + blocking_notifier_call_chain+0x3a/0x60 + acpi_device_del_work_fn+0x85/0x1d0 + process_one_work+0x134/0x2f0 + worker_thread+0x2f0/0x410 + ? __pfx_worker_thread+0x10/0x10 + kthread+0xe3/0x110 + ? __pfx_kthread+0x10/0x10 + ret_from_fork+0x2f/0x50 + ? __pfx_kthread+0x10/0x10 + ret_from_fork_asm+0x1b/0x30 + +---[ end trace 0000000000000000 ]--- +... +repeated 7 more times, 1 for each channel of the mux +... + +The issue is that the binding of the ACPI devices to their peer I2C +adapters is not correctly cleaned up. Digging deeper into the issue we +see that the deletion order is such that the ACPI devices matching the +mux channel i2c adapters are deleted first during the SSDT overlay +removal. For each of the channels we see a call to i2c_acpi_notify() +with ACPI_RECONFIG_DEVICE_REMOVE but, because these devices are not +actually i2c_clients, nothing is done for them. + +Later on, after each of the mux channels has been dealt with, we come +to delete the i2c_client representing the PCA9548 device. This is the +call stack we see above, whereby the kernel cleans up the i2c_client +including destruction of the mux and its channel adapters. At this +point we do attempt to unbind from the ACPI peers but those peers no +longer exist and so we hit the kernfs errors. + +The fix is to augment i2c_acpi_notify() to handle i2c_adapters. But, +given that the life cycle of the adapters is linked to the i2c_client, +instead of deleting the i2c_adapters during the i2c_acpi_notify(), we +just trigger unbinding of the ACPI device from the adapter device, and +allow the clean up of the adapter to continue in the way it always has. + +Signed-off-by: Hamish Martin +Reviewed-by: Mika Westerberg +Reviewed-by: Andi Shyti +Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications") +Cc: # v4.8+ +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman +--- + drivers/i2c/i2c-core-acpi.c | 19 +++++++++++++++---- + 1 file changed, 15 insertions(+), 4 deletions(-) + +--- a/drivers/i2c/i2c-core-acpi.c ++++ b/drivers/i2c/i2c-core-acpi.c +@@ -445,6 +445,11 @@ static struct i2c_client *i2c_acpi_find_ + return i2c_find_device_by_fwnode(acpi_fwnode_handle(adev)); + } + ++static struct i2c_adapter *i2c_acpi_find_adapter_by_adev(struct acpi_device *adev) ++{ ++ return i2c_find_adapter_by_fwnode(acpi_fwnode_handle(adev)); ++} ++ + static int i2c_acpi_notify(struct notifier_block *nb, unsigned long value, + void *arg) + { +@@ -471,11 +476,17 @@ static int i2c_acpi_notify(struct notifi + break; + + client = i2c_acpi_find_client_by_adev(adev); +- if (!client) +- break; ++ if (client) { ++ i2c_unregister_device(client); ++ put_device(&client->dev); ++ } ++ ++ adapter = i2c_acpi_find_adapter_by_adev(adev); ++ if (adapter) { ++ acpi_unbind_one(&adapter->dev); ++ put_device(&adapter->dev); ++ } + +- i2c_unregister_device(client); +- put_device(&client->dev); + break; + } + diff --git a/queue-6.6/intel_th-pci-add-meteor-lake-s-cpu-support.patch b/queue-6.6/intel_th-pci-add-meteor-lake-s-cpu-support.patch new file mode 100644 index 00000000000..87f3fc397e6 --- /dev/null +++ b/queue-6.6/intel_th-pci-add-meteor-lake-s-cpu-support.patch @@ -0,0 +1,34 @@ +From a4f813c3ec9d1c32bc402becd1f011b3904dd699 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Mon, 29 Apr 2024 16:01:18 +0300 +Subject: intel_th: pci: Add Meteor Lake-S CPU support + +From: Alexander Shishkin + +commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream. + +Add support for the Trace Hub in Meteor Lake-S CPU. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20240429130119.1518073-15-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -290,6 +290,11 @@ static const struct pci_device_id intel_ + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + { ++ /* Meteor Lake-S CPU */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xae24), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, ++ { + /* Raptor Lake-S */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7a26), + .driver_data = (kernel_ulong_t)&intel_th_2x, diff --git a/queue-6.6/kdb-fix-buffer-overflow-during-tab-complete.patch b/queue-6.6/kdb-fix-buffer-overflow-during-tab-complete.patch new file mode 100644 index 00000000000..25088dae097 --- /dev/null +++ b/queue-6.6/kdb-fix-buffer-overflow-during-tab-complete.patch @@ -0,0 +1,64 @@ +From e9730744bf3af04cda23799029342aa3cddbc454 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:34 +0100 +Subject: kdb: Fix buffer overflow during tab-complete + +From: Daniel Thompson + +commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. + +Currently, when the user attempts symbol completion with the Tab key, kdb +will use strncpy() to insert the completed symbol into the command buffer. +Unfortunately it passes the size of the source buffer rather than the +destination to strncpy() with predictably horrible results. Most obviously +if the command buffer is already full but cp, the cursor position, is in +the middle of the buffer, then we will write past the end of the supplied +buffer. + +Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() +calls plus explicit boundary checks to make sure we have enough space +before we start moving characters around. + +Reported-by: Justin Stitt +Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziUJLpw@mail.gmail.com/ +Cc: stable@vger.kernel.org +Reviewed-by: Douglas Anderson +Reviewed-by: Justin Stitt +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- + 1 file changed, 13 insertions(+), 8 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -367,14 +367,19 @@ poll_again: + kdb_printf(kdb_prompt_str); + kdb_printf("%s", buffer); + } else if (tab != 2 && count > 0) { +- len_tmp = strlen(p_tmp); +- strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); +- len_tmp = strlen(p_tmp); +- strncpy(cp, p_tmp+len, len_tmp-len + 1); +- len = len_tmp - len; +- kdb_printf("%s", cp); +- cp += len; +- lastchar += len; ++ /* How many new characters do we want from tmpbuffer? */ ++ len_tmp = strlen(p_tmp) - len; ++ if (lastchar + len_tmp >= bufend) ++ len_tmp = bufend - lastchar; ++ ++ if (len_tmp) { ++ /* + 1 ensures the '\0' is memmove'd */ ++ memmove(cp+len_tmp, cp, (lastchar-cp) + 1); ++ memcpy(cp, p_tmp+len, len_tmp); ++ kdb_printf("%s", cp); ++ cp += len_tmp; ++ lastchar += len_tmp; ++ } + } + kdb_nextline = 1; /* reset output line number */ + break; diff --git a/queue-6.6/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch b/queue-6.6/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch new file mode 100644 index 00000000000..da79a962943 --- /dev/null +++ b/queue-6.6/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch @@ -0,0 +1,63 @@ +From db2f9c7dc29114f531df4a425d0867d01e1f1e28 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:36 +0100 +Subject: kdb: Fix console handling when editing and tab-completing commands + +From: Daniel Thompson + +commit db2f9c7dc29114f531df4a425d0867d01e1f1e28 upstream. + +Currently, if the cursor position is not at the end of the command buffer +and the user uses the Tab-complete functions, then the console does not +leave the cursor in the correct position. + +For example consider the following buffer with the cursor positioned +at the ^: + +md kdb_pro 10 + ^ + +Pressing tab should result in: + +md kdb_prompt_str 10 + ^ + +However this does not happen. Instead the cursor is placed at the end +(after then 10) and further cursor movement redraws incorrectly. The +same problem exists when we double-Tab but in a different part of the +code. + +Fix this by sending a carriage return and then redisplaying the text to +the left of the cursor. + +Cc: stable@vger.kernel.org +Reviewed-by: Douglas Anderson +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-3-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -383,6 +383,8 @@ poll_again: + kdb_printf("\n"); + kdb_printf(kdb_prompt_str); + kdb_printf("%s", buffer); ++ if (cp != lastchar) ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } else if (tab != 2 && count > 0) { + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; +@@ -396,6 +398,9 @@ poll_again: + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; ++ if (cp != lastchar) ++ kdb_position_cursor(kdb_prompt_str, ++ buffer, cp); + } + } + kdb_nextline = 1; /* reset output line number */ diff --git a/queue-6.6/kdb-merge-identical-case-statements-in-kdb_read.patch b/queue-6.6/kdb-merge-identical-case-statements-in-kdb_read.patch new file mode 100644 index 00000000000..15e8569cc2c --- /dev/null +++ b/queue-6.6/kdb-merge-identical-case-statements-in-kdb_read.patch @@ -0,0 +1,48 @@ +From 6244917f377bf64719551b58592a02a0336a7439 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:37 +0100 +Subject: kdb: Merge identical case statements in kdb_read() + +From: Daniel Thompson + +commit 6244917f377bf64719551b58592a02a0336a7439 upstream. + +The code that handles case 14 (down) and case 16 (up) has been copy and +pasted despite being byte-for-byte identical. Combine them. + +Cc: stable@vger.kernel.org # Not a bug fix but it is needed for later bug fixes +Reviewed-by: Douglas Anderson +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-4-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 10 +--------- + 1 file changed, 1 insertion(+), 9 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -317,6 +317,7 @@ poll_again: + } + break; + case 14: /* Down */ ++ case 16: /* Up */ + memset(tmpbuffer, ' ', + strlen(kdb_prompt_str) + (lastchar-buffer)); + *(tmpbuffer+strlen(kdb_prompt_str) + +@@ -331,15 +332,6 @@ poll_again: + ++cp; + } + break; +- case 16: /* Up */ +- memset(tmpbuffer, ' ', +- strlen(kdb_prompt_str) + (lastchar-buffer)); +- *(tmpbuffer+strlen(kdb_prompt_str) + +- (lastchar-buffer)) = '\0'; +- kdb_printf("\r%s\r", tmpbuffer); +- *lastchar = (char)key; +- *(lastchar+1) = '\0'; +- return lastchar; + case 9: /* Tab */ + if (tab < 2) + ++tab; diff --git a/queue-6.6/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch b/queue-6.6/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch new file mode 100644 index 00000000000..2e3817c86a0 --- /dev/null +++ b/queue-6.6/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch @@ -0,0 +1,46 @@ +From c9b51ddb66b1d96e4d364c088da0f1dfb004c574 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:38 +0100 +Subject: kdb: Use format-specifiers rather than memset() for padding in kdb_read() + +From: Daniel Thompson + +commit c9b51ddb66b1d96e4d364c088da0f1dfb004c574 upstream. + +Currently when the current line should be removed from the display +kdb_read() uses memset() to fill a temporary buffer with spaces. +The problem is not that this could be trivially implemented using a +format string rather than open coding it. The real problem is that +it is possible, on systems with a long kdb_prompt_str, to write past +the end of the tmpbuffer. + +Happily, as mentioned above, this can be trivially implemented using a +format string. Make it so! + +Cc: stable@vger.kernel.org +Reviewed-by: Douglas Anderson +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-5-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -318,11 +318,9 @@ poll_again: + break; + case 14: /* Down */ + case 16: /* Up */ +- memset(tmpbuffer, ' ', +- strlen(kdb_prompt_str) + (lastchar-buffer)); +- *(tmpbuffer+strlen(kdb_prompt_str) + +- (lastchar-buffer)) = '\0'; +- kdb_printf("\r%s\r", tmpbuffer); ++ kdb_printf("\r%*c\r", ++ (int)(strlen(kdb_prompt_str) + (lastchar - buffer)), ++ ' '); + *lastchar = (char)key; + *(lastchar+1) = '\0'; + return lastchar; diff --git a/queue-6.6/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch b/queue-6.6/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch new file mode 100644 index 00000000000..05bb38db278 --- /dev/null +++ b/queue-6.6/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch @@ -0,0 +1,127 @@ +From 09b35989421dfd5573f0b4683c7700a7483c71f9 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:35 +0100 +Subject: kdb: Use format-strings rather than '\0' injection in kdb_read() + +From: Daniel Thompson + +commit 09b35989421dfd5573f0b4683c7700a7483c71f9 upstream. + +Currently when kdb_read() needs to reposition the cursor it uses copy and +paste code that works by injecting an '\0' at the cursor position before +delivering a carriage-return and reprinting the line (which stops at the +'\0'). + +Tidy up the code by hoisting the copy and paste code into an appropriately +named function. Additionally let's replace the '\0' injection with a +proper field width parameter so that the string will be abridged during +formatting instead. + +Cc: stable@vger.kernel.org # Not a bug fix but it is needed for later bug fixes +Tested-by: Justin Stitt +Reviewed-by: Douglas Anderson +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-2-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 55 ++++++++++++++++++++++++++++------------------ + 1 file changed, 34 insertions(+), 21 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -184,6 +184,33 @@ char kdb_getchar(void) + unreachable(); + } + ++/** ++ * kdb_position_cursor() - Place cursor in the correct horizontal position ++ * @prompt: Nil-terminated string containing the prompt string ++ * @buffer: Nil-terminated string containing the entire command line ++ * @cp: Cursor position, pointer the character in buffer where the cursor ++ * should be positioned. ++ * ++ * The cursor is positioned by sending a carriage-return and then printing ++ * the content of the line until we reach the correct cursor position. ++ * ++ * There is some additional fine detail here. ++ * ++ * Firstly, even though kdb_printf() will correctly format zero-width fields ++ * we want the second call to kdb_printf() to be conditional. That keeps things ++ * a little cleaner when LOGGING=1. ++ * ++ * Secondly, we can't combine everything into one call to kdb_printf() since ++ * that renders into a fixed length buffer and the combined print could result ++ * in unwanted truncation. ++ */ ++static void kdb_position_cursor(char *prompt, char *buffer, char *cp) ++{ ++ kdb_printf("\r%s", kdb_prompt_str); ++ if (cp > buffer) ++ kdb_printf("%.*s", (int)(cp - buffer), buffer); ++} ++ + /* + * kdb_read + * +@@ -212,7 +239,6 @@ static char *kdb_read(char *buffer, size + * and null byte */ + char *lastchar; + char *p_tmp; +- char tmp; + static char tmpbuffer[CMD_BUFLEN]; + int len = strlen(buffer); + int len_tmp; +@@ -249,12 +275,8 @@ poll_again: + } + *(--lastchar) = '\0'; + --cp; +- kdb_printf("\b%s \r", cp); +- tmp = *cp; +- *cp = '\0'; +- kdb_printf(kdb_prompt_str); +- kdb_printf("%s", buffer); +- *cp = tmp; ++ kdb_printf("\b%s ", cp); ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } + break; + case 10: /* linefeed */ +@@ -272,19 +294,14 @@ poll_again: + memcpy(tmpbuffer, cp+1, lastchar - cp - 1); + memcpy(cp, tmpbuffer, lastchar - cp - 1); + *(--lastchar) = '\0'; +- kdb_printf("%s \r", cp); +- tmp = *cp; +- *cp = '\0'; +- kdb_printf(kdb_prompt_str); +- kdb_printf("%s", buffer); +- *cp = tmp; ++ kdb_printf("%s ", cp); ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } + break; + case 1: /* Home */ + if (cp > buffer) { +- kdb_printf("\r"); +- kdb_printf(kdb_prompt_str); + cp = buffer; ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } + break; + case 5: /* End */ +@@ -390,13 +407,9 @@ poll_again: + memcpy(cp+1, tmpbuffer, lastchar - cp); + *++lastchar = '\0'; + *cp = key; +- kdb_printf("%s\r", cp); ++ kdb_printf("%s", cp); + ++cp; +- tmp = *cp; +- *cp = '\0'; +- kdb_printf(kdb_prompt_str); +- kdb_printf("%s", buffer); +- *cp = tmp; ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } else { + *++lastchar = '\0'; + *cp++ = key; diff --git a/queue-6.6/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch b/queue-6.6/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch new file mode 100644 index 00000000000..a141362899b --- /dev/null +++ b/queue-6.6/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch @@ -0,0 +1,68 @@ +From 2ef3cec44c60ae171b287db7fc2aa341586d65ba Mon Sep 17 00:00:00 2001 +From: Alexander Potapenko +Date: Tue, 28 May 2024 12:48:06 +0200 +Subject: kmsan: do not wipe out origin when doing partial unpoisoning + +From: Alexander Potapenko + +commit 2ef3cec44c60ae171b287db7fc2aa341586d65ba upstream. + +As noticed by Brian, KMSAN should not be zeroing the origin when +unpoisoning parts of a four-byte uninitialized value, e.g.: + + char a[4]; + kmsan_unpoison_memory(a, 1); + +This led to false negatives, as certain poisoned values could receive zero +origins, preventing those values from being reported. + +To fix the problem, check that kmsan_internal_set_shadow_origin() writes +zero origins only to slots which have zero shadow. + +Link: https://lkml.kernel.org/r/20240528104807.738758-1-glider@google.com +Fixes: f80be4571b19 ("kmsan: add KMSAN runtime core") +Signed-off-by: Alexander Potapenko +Reported-by: Brian Johannesmeyer + Link: https://lore.kernel.org/lkml/20240524232804.1984355-1-bjohannesmeyer@gmail.com/T/ +Reviewed-by: Marco Elver +Tested-by: Brian Johannesmeyer +Cc: Dmitry Vyukov +Cc: Kees Cook +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/kmsan/core.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +--- a/mm/kmsan/core.c ++++ b/mm/kmsan/core.c +@@ -262,8 +262,7 @@ void kmsan_internal_set_shadow_origin(vo + u32 origin, bool checked) + { + u64 address = (u64)addr; +- void *shadow_start; +- u32 *origin_start; ++ u32 *shadow_start, *origin_start; + size_t pad = 0; + + KMSAN_WARN_ON(!kmsan_metadata_is_contiguous(addr, size)); +@@ -291,8 +290,16 @@ void kmsan_internal_set_shadow_origin(vo + origin_start = + (u32 *)kmsan_get_metadata((void *)address, KMSAN_META_ORIGIN); + +- for (int i = 0; i < size / KMSAN_ORIGIN_SIZE; i++) +- origin_start[i] = origin; ++ /* ++ * If the new origin is non-zero, assume that the shadow byte is also non-zero, ++ * and unconditionally overwrite the old origin slot. ++ * If the new origin is zero, overwrite the old origin slot iff the ++ * corresponding shadow slot is zero. ++ */ ++ for (int i = 0; i < size / KMSAN_ORIGIN_SIZE; i++) { ++ if (origin || !shadow_start[i]) ++ origin_start[i] = origin; ++ } + } + + struct page *kmsan_vmalloc_to_page_or_null(void *vaddr) diff --git a/queue-6.6/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch b/queue-6.6/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch new file mode 100644 index 00000000000..ee6866686c7 --- /dev/null +++ b/queue-6.6/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch @@ -0,0 +1,46 @@ +From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001 +From: Frank van der Linden +Date: Thu, 4 Apr 2024 16:25:14 +0000 +Subject: mm/cma: drop incorrect alignment check in cma_init_reserved_mem + +From: Frank van der Linden + +commit b174f139bdc8aaaf72f5b67ad1bd512c4868a87e upstream. + +cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by +one bit in the cma allocation bitmask is aligned with +CMA_MIN_ALIGNMENT_BYTES (pageblock size). + +However, this is too strict, as this will fail if order_per_bit > +pageblock_order, which is a valid configuration. + +We could check IS_ALIGNED both ways, but since both numbers are powers of +two, no check is needed at all. + +Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com +Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree") +Signed-off-by: Frank van der Linden +Acked-by: David Hildenbrand +Cc: Marek Szyprowski +Cc: Muchun Song +Cc: Roman Gushchin +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/cma.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/mm/cma.c ++++ b/mm/cma.c +@@ -187,10 +187,6 @@ int __init cma_init_reserved_mem(phys_ad + if (!size || !memblock_is_region_reserved(base, size)) + return -EINVAL; + +- /* alignment should be aligned with order_per_bit */ +- if (!IS_ALIGNED(CMA_MIN_ALIGNMENT_PAGES, 1 << order_per_bit)) +- return -EINVAL; +- + /* ensure minimal alignment required by mm core */ + if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) + return -EINVAL; diff --git a/queue-6.6/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch b/queue-6.6/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch new file mode 100644 index 00000000000..94087b9b063 --- /dev/null +++ b/queue-6.6/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch @@ -0,0 +1,58 @@ +From 55d134a7b499c77e7cfd0ee41046f3c376e791e5 Mon Sep 17 00:00:00 2001 +From: Frank van der Linden +Date: Thu, 4 Apr 2024 16:25:15 +0000 +Subject: mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid + +From: Frank van der Linden + +commit 55d134a7b499c77e7cfd0ee41046f3c376e791e5 upstream. + +The hugetlb_cma code passes 0 in the order_per_bit argument to +cma_declare_contiguous_nid (the alignment, computed using the page order, +is correctly passed in). + +This causes a bit in the cma allocation bitmap to always represent a 4k +page, making the bitmaps potentially very large, and slower. + +It would create bitmaps that would be pretty big. E.g. for a 4k page +size on x86, hugetlb_cma=64G would mean a bitmap size of (64G / 4k) / 8 +== 2M. With HUGETLB_PAGE_ORDER as order_per_bit, as intended, this +would be (64G / 2M) / 8 == 4k. So, that's quite a difference. + +Also, this restricted the hugetlb_cma area to ((PAGE_SIZE << +MAX_PAGE_ORDER) * 8) * PAGE_SIZE (e.g. 128G on x86) , since +bitmap_alloc uses normal page allocation, and is thus restricted by +MAX_PAGE_ORDER. Specifying anything about that would fail the CMA +initialization. + +So, correctly pass in the order instead. + +Link: https://lkml.kernel.org/r/20240404162515.527802-2-fvdl@google.com +Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") +Signed-off-by: Frank van der Linden +Acked-by: Roman Gushchin +Acked-by: David Hildenbrand +Cc: Marek Szyprowski +Cc: Muchun Song +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/hugetlb.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -7464,9 +7464,9 @@ void __init hugetlb_cma_reserve(int orde + * huge page demotion. + */ + res = cma_declare_contiguous_nid(0, size, 0, +- PAGE_SIZE << HUGETLB_PAGE_ORDER, +- 0, false, name, +- &hugetlb_cma[nid], nid); ++ PAGE_SIZE << HUGETLB_PAGE_ORDER, ++ HUGETLB_PAGE_ORDER, false, name, ++ &hugetlb_cma[nid], nid); + if (res) { + pr_warn("hugetlb_cma: reservation failed: err %d, node %d", + res, nid); diff --git a/queue-6.6/mm-ksm-fix-ksm_pages_scanned-accounting.patch b/queue-6.6/mm-ksm-fix-ksm_pages_scanned-accounting.patch new file mode 100644 index 00000000000..f98d3af5f13 --- /dev/null +++ b/queue-6.6/mm-ksm-fix-ksm_pages_scanned-accounting.patch @@ -0,0 +1,71 @@ +From 730cdc2c72c6905a2eda2fccbbf67dcef1206590 Mon Sep 17 00:00:00 2001 +From: Chengming Zhou +Date: Tue, 28 May 2024 13:15:21 +0800 +Subject: mm/ksm: fix ksm_pages_scanned accounting + +From: Chengming Zhou + +commit 730cdc2c72c6905a2eda2fccbbf67dcef1206590 upstream. + +Patch series "mm/ksm: fix some accounting problems", v3. + +We encountered some abnormal ksm_pages_scanned and ksm_zero_pages during +some random tests. + +1. ksm_pages_scanned unchanged even ksmd scanning has progress. +2. ksm_zero_pages maybe -1 in some rare cases. + + +This patch (of 2): + +During testing, I found ksm_pages_scanned is unchanged although the +scan_get_next_rmap_item() did return valid rmap_item that is not NULL. + +The reason is the scan_get_next_rmap_item() will return NULL after a full +scan, so ksm_do_scan() just return without accounting of the +ksm_pages_scanned. + +Fix it by just putting ksm_pages_scanned accounting in that loop, and it +will be accounted more timely if that loop would last for a long time. + +Link: https://lkml.kernel.org/r/20240528-b4-ksm-counters-v3-0-34bb358fdc13@linux.dev +Link: https://lkml.kernel.org/r/20240528-b4-ksm-counters-v3-1-34bb358fdc13@linux.dev +Fixes: b348b5fe2b5f ("mm/ksm: add pages scanned metric") +Signed-off-by: Chengming Zhou +Acked-by: David Hildenbrand +Reviewed-by: xu xin +Cc: Andrea Arcangeli +Cc: Hugh Dickins +Cc: Ran Xiaokai +Cc: Stefan Roesch +Cc: Yang Yang +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/ksm.c | 6 ++---- + 1 file changed, 2 insertions(+), 4 deletions(-) + +--- a/mm/ksm.c ++++ b/mm/ksm.c +@@ -2486,18 +2486,16 @@ static void ksm_do_scan(unsigned int sca + { + struct ksm_rmap_item *rmap_item; + struct page *page; +- unsigned int npages = scan_npages; + +- while (npages-- && likely(!freezing(current))) { ++ while (scan_npages-- && likely(!freezing(current))) { + cond_resched(); + rmap_item = scan_get_next_rmap_item(&page); + if (!rmap_item) + return; + cmp_and_merge_page(page, rmap_item); + put_page(page); ++ ksm_pages_scanned++; + } +- +- ksm_pages_scanned += scan_npages - npages; + } + + static int ksmd_should_run(void) diff --git a/queue-6.6/mm-ksm-fix-ksm_zero_pages-accounting.patch b/queue-6.6/mm-ksm-fix-ksm_zero_pages-accounting.patch new file mode 100644 index 00000000000..06b58e516af --- /dev/null +++ b/queue-6.6/mm-ksm-fix-ksm_zero_pages-accounting.patch @@ -0,0 +1,143 @@ +From c2dc78b86e0821ecf9a9d0c35dba2618279a5bb6 Mon Sep 17 00:00:00 2001 +From: Chengming Zhou +Date: Tue, 28 May 2024 13:15:22 +0800 +Subject: mm/ksm: fix ksm_zero_pages accounting + +From: Chengming Zhou + +commit c2dc78b86e0821ecf9a9d0c35dba2618279a5bb6 upstream. + +We normally ksm_zero_pages++ in ksmd when page is merged with zero page, +but ksm_zero_pages-- is done from page tables side, where there is no any +accessing protection of ksm_zero_pages. + +So we can read very exceptional value of ksm_zero_pages in rare cases, +such as -1, which is very confusing to users. + +Fix it by changing to use atomic_long_t, and the same case with the +mm->ksm_zero_pages. + +Link: https://lkml.kernel.org/r/20240528-b4-ksm-counters-v3-2-34bb358fdc13@linux.dev +Fixes: e2942062e01d ("ksm: count all zero pages placed by KSM") +Fixes: 6080d19f0704 ("ksm: add ksm zero pages for each process") +Signed-off-by: Chengming Zhou +Acked-by: David Hildenbrand +Cc: Andrea Arcangeli +Cc: Hugh Dickins +Cc: Ran Xiaokai +Cc: Stefan Roesch +Cc: xu xin +Cc: Yang Yang +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/proc/base.c | 2 +- + include/linux/ksm.h | 17 ++++++++++++++--- + include/linux/mm_types.h | 2 +- + mm/ksm.c | 11 +++++------ + 4 files changed, 21 insertions(+), 11 deletions(-) + +--- a/fs/proc/base.c ++++ b/fs/proc/base.c +@@ -3207,7 +3207,7 @@ static int proc_pid_ksm_stat(struct seq_ + mm = get_task_mm(task); + if (mm) { + seq_printf(m, "ksm_rmap_items %lu\n", mm->ksm_rmap_items); +- seq_printf(m, "ksm_zero_pages %lu\n", mm->ksm_zero_pages); ++ seq_printf(m, "ksm_zero_pages %ld\n", mm_ksm_zero_pages(mm)); + seq_printf(m, "ksm_merging_pages %lu\n", mm->ksm_merging_pages); + seq_printf(m, "ksm_process_profit %ld\n", ksm_process_profit(mm)); + mmput(mm); +--- a/include/linux/ksm.h ++++ b/include/linux/ksm.h +@@ -33,16 +33,27 @@ void __ksm_exit(struct mm_struct *mm); + */ + #define is_ksm_zero_pte(pte) (is_zero_pfn(pte_pfn(pte)) && pte_dirty(pte)) + +-extern unsigned long ksm_zero_pages; ++extern atomic_long_t ksm_zero_pages; ++ ++static inline void ksm_map_zero_page(struct mm_struct *mm) ++{ ++ atomic_long_inc(&ksm_zero_pages); ++ atomic_long_inc(&mm->ksm_zero_pages); ++} + + static inline void ksm_might_unmap_zero_page(struct mm_struct *mm, pte_t pte) + { + if (is_ksm_zero_pte(pte)) { +- ksm_zero_pages--; +- mm->ksm_zero_pages--; ++ atomic_long_dec(&ksm_zero_pages); ++ atomic_long_dec(&mm->ksm_zero_pages); + } + } + ++static inline long mm_ksm_zero_pages(struct mm_struct *mm) ++{ ++ return atomic_long_read(&mm->ksm_zero_pages); ++} ++ + static inline int ksm_fork(struct mm_struct *mm, struct mm_struct *oldmm) + { + int ret; +--- a/include/linux/mm_types.h ++++ b/include/linux/mm_types.h +@@ -899,7 +899,7 @@ struct mm_struct { + * Represent how many empty pages are merged with kernel zero + * pages when enabling KSM use_zero_pages. + */ +- unsigned long ksm_zero_pages; ++ atomic_long_t ksm_zero_pages; + #endif /* CONFIG_KSM */ + #ifdef CONFIG_LRU_GEN + struct { +--- a/mm/ksm.c ++++ b/mm/ksm.c +@@ -282,7 +282,7 @@ static unsigned int zero_checksum __read + static bool ksm_use_zero_pages __read_mostly; + + /* The number of zero pages which is placed by KSM */ +-unsigned long ksm_zero_pages; ++atomic_long_t ksm_zero_pages = ATOMIC_LONG_INIT(0); + + #ifdef CONFIG_NUMA + /* Zeroed when merging across nodes is not allowed */ +@@ -1242,8 +1242,7 @@ static int replace_page(struct vm_area_s + * the dirty bit in zero page's PTE is set. + */ + newpte = pte_mkdirty(pte_mkspecial(pfn_pte(page_to_pfn(kpage), vma->vm_page_prot))); +- ksm_zero_pages++; +- mm->ksm_zero_pages++; ++ ksm_map_zero_page(mm); + /* + * We're replacing an anonymous page with a zero page, which is + * not anonymous. We need to do proper accounting otherwise we +@@ -3105,7 +3104,7 @@ static void wait_while_offlining(void) + #ifdef CONFIG_PROC_FS + long ksm_process_profit(struct mm_struct *mm) + { +- return (long)(mm->ksm_merging_pages + mm->ksm_zero_pages) * PAGE_SIZE - ++ return (long)(mm->ksm_merging_pages + mm_ksm_zero_pages(mm)) * PAGE_SIZE - + mm->ksm_rmap_items * sizeof(struct ksm_rmap_item); + } + #endif /* CONFIG_PROC_FS */ +@@ -3384,7 +3383,7 @@ KSM_ATTR_RO(pages_volatile); + static ssize_t ksm_zero_pages_show(struct kobject *kobj, + struct kobj_attribute *attr, char *buf) + { +- return sysfs_emit(buf, "%ld\n", ksm_zero_pages); ++ return sysfs_emit(buf, "%ld\n", atomic_long_read(&ksm_zero_pages)); + } + KSM_ATTR_RO(ksm_zero_pages); + +@@ -3393,7 +3392,7 @@ static ssize_t general_profit_show(struc + { + long general_profit; + +- general_profit = (ksm_pages_sharing + ksm_zero_pages) * PAGE_SIZE - ++ general_profit = (ksm_pages_sharing + atomic_long_read(&ksm_zero_pages)) * PAGE_SIZE - + ksm_rmap_items * sizeof(struct ksm_rmap_item); + + return sysfs_emit(buf, "%ld\n", general_profit); diff --git a/queue-6.6/mm-proc-pid-smaps_rollup-avoid-skipping-vma-after-getting-mmap_lock-again.patch b/queue-6.6/mm-proc-pid-smaps_rollup-avoid-skipping-vma-after-getting-mmap_lock-again.patch new file mode 100644 index 00000000000..da04f35bbbe --- /dev/null +++ b/queue-6.6/mm-proc-pid-smaps_rollup-avoid-skipping-vma-after-getting-mmap_lock-again.patch @@ -0,0 +1,52 @@ +From 6d065f507d82307d6161ac75c025111fb8b08a46 Mon Sep 17 00:00:00 2001 +From: Yuanyuan Zhong +Date: Thu, 23 May 2024 12:35:31 -0600 +Subject: mm: /proc/pid/smaps_rollup: avoid skipping vma after getting mmap_lock again + +From: Yuanyuan Zhong + +commit 6d065f507d82307d6161ac75c025111fb8b08a46 upstream. + +After switching smaps_rollup to use VMA iterator, searching for next entry +is part of the condition expression of the do-while loop. So the current +VMA needs to be addressed before the continue statement. + +Otherwise, with some VMAs skipped, userspace observed memory +consumption from /proc/pid/smaps_rollup will be smaller than the sum of +the corresponding fields from /proc/pid/smaps. + +Link: https://lkml.kernel.org/r/20240523183531.2535436-1-yzhong@purestorage.com +Fixes: c4c84f06285e ("fs/proc/task_mmu: stop using linked list and highest_vm_end") +Signed-off-by: Yuanyuan Zhong +Reviewed-by: Mohamed Khalfella +Cc: David Hildenbrand +Cc: Matthew Wilcox (Oracle) +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/proc/task_mmu.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +--- a/fs/proc/task_mmu.c ++++ b/fs/proc/task_mmu.c +@@ -965,12 +965,17 @@ static int show_smaps_rollup(struct seq_ + break; + + /* Case 1 and 2 above */ +- if (vma->vm_start >= last_vma_end) ++ if (vma->vm_start >= last_vma_end) { ++ smap_gather_stats(vma, &mss, 0); ++ last_vma_end = vma->vm_end; + continue; ++ } + + /* Case 4 above */ +- if (vma->vm_end > last_vma_end) ++ if (vma->vm_end > last_vma_end) { + smap_gather_stats(vma, &mss, last_vma_end); ++ last_vma_end = vma->vm_end; ++ } + } + } for_each_vma(vmi, vma); + diff --git a/queue-6.6/mm-vmalloc-fix-vmalloc-which-may-return-null-if-called-with-__gfp_nofail.patch b/queue-6.6/mm-vmalloc-fix-vmalloc-which-may-return-null-if-called-with-__gfp_nofail.patch new file mode 100644 index 00000000000..22602923e7b --- /dev/null +++ b/queue-6.6/mm-vmalloc-fix-vmalloc-which-may-return-null-if-called-with-__gfp_nofail.patch @@ -0,0 +1,109 @@ +From 8e0545c83d672750632f46e3f9ad95c48c91a0fc Mon Sep 17 00:00:00 2001 +From: "Hailong.Liu" +Date: Fri, 10 May 2024 18:01:31 +0800 +Subject: mm/vmalloc: fix vmalloc which may return null if called with __GFP_NOFAIL + +From: Hailong.Liu + +commit 8e0545c83d672750632f46e3f9ad95c48c91a0fc upstream. + +commit a421ef303008 ("mm: allow !GFP_KERNEL allocations for kvmalloc") +includes support for __GFP_NOFAIL, but it presents a conflict with commit +dd544141b9eb ("vmalloc: back off when the current task is OOM-killed"). A +possible scenario is as follows: + +process-a +__vmalloc_node_range(GFP_KERNEL | __GFP_NOFAIL) + __vmalloc_area_node() + vm_area_alloc_pages() + --> oom-killer send SIGKILL to process-a + if (fatal_signal_pending(current)) break; +--> return NULL; + +To fix this, do not check fatal_signal_pending() in vm_area_alloc_pages() +if __GFP_NOFAIL set. + +This issue occurred during OPLUS KASAN TEST. Below is part of the log +-> oom-killer sends signal to process +[65731.222840] [ T1308] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/apps/uid_10198,task=gs.intelligence,pid=32454,uid=10198 + +[65731.259685] [T32454] Call trace: +[65731.259698] [T32454] dump_backtrace+0xf4/0x118 +[65731.259734] [T32454] show_stack+0x18/0x24 +[65731.259756] [T32454] dump_stack_lvl+0x60/0x7c +[65731.259781] [T32454] dump_stack+0x18/0x38 +[65731.259800] [T32454] mrdump_common_die+0x250/0x39c [mrdump] +[65731.259936] [T32454] ipanic_die+0x20/0x34 [mrdump] +[65731.260019] [T32454] atomic_notifier_call_chain+0xb4/0xfc +[65731.260047] [T32454] notify_die+0x114/0x198 +[65731.260073] [T32454] die+0xf4/0x5b4 +[65731.260098] [T32454] die_kernel_fault+0x80/0x98 +[65731.260124] [T32454] __do_kernel_fault+0x160/0x2a8 +[65731.260146] [T32454] do_bad_area+0x68/0x148 +[65731.260174] [T32454] do_mem_abort+0x151c/0x1b34 +[65731.260204] [T32454] el1_abort+0x3c/0x5c +[65731.260227] [T32454] el1h_64_sync_handler+0x54/0x90 +[65731.260248] [T32454] el1h_64_sync+0x68/0x6c + +[65731.260269] [T32454] z_erofs_decompress_queue+0x7f0/0x2258 +--> be->decompressed_pages = kvcalloc(be->nr_pages, sizeof(struct page *), GFP_KERNEL | __GFP_NOFAIL); + kernel panic by NULL pointer dereference. + erofs assume kvmalloc with __GFP_NOFAIL never return NULL. +[65731.260293] [T32454] z_erofs_runqueue+0xf30/0x104c +[65731.260314] [T32454] z_erofs_readahead+0x4f0/0x968 +[65731.260339] [T32454] read_pages+0x170/0xadc +[65731.260364] [T32454] page_cache_ra_unbounded+0x874/0xf30 +[65731.260388] [T32454] page_cache_ra_order+0x24c/0x714 +[65731.260411] [T32454] filemap_fault+0xbf0/0x1a74 +[65731.260437] [T32454] __do_fault+0xd0/0x33c +[65731.260462] [T32454] handle_mm_fault+0xf74/0x3fe0 +[65731.260486] [T32454] do_mem_abort+0x54c/0x1b34 +[65731.260509] [T32454] el0_da+0x44/0x94 +[65731.260531] [T32454] el0t_64_sync_handler+0x98/0xb4 +[65731.260553] [T32454] el0t_64_sync+0x198/0x19c + +Link: https://lkml.kernel.org/r/20240510100131.1865-1-hailong.liu@oppo.com +Fixes: 9376130c390a ("mm/vmalloc: add support for __GFP_NOFAIL") +Signed-off-by: Hailong.Liu +Acked-by: Michal Hocko +Suggested-by: Barry Song <21cnbao@gmail.com> +Reported-by: Oven +Reviewed-by: Barry Song +Reviewed-by: Uladzislau Rezki (Sony) +Cc: Chao Yu +Cc: Christoph Hellwig +Cc: Gao Xiang +Cc: Lorenzo Stoakes +Cc: Michal Hocko +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/vmalloc.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/mm/vmalloc.c ++++ b/mm/vmalloc.c +@@ -2994,7 +2994,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, + { + unsigned int nr_allocated = 0; + gfp_t alloc_gfp = gfp; +- bool nofail = false; ++ bool nofail = gfp & __GFP_NOFAIL; + struct page *page; + int i; + +@@ -3051,12 +3051,11 @@ vm_area_alloc_pages(gfp_t gfp, int nid, + * and compaction etc. + */ + alloc_gfp &= ~__GFP_NOFAIL; +- nofail = true; + } + + /* High-order pages or fallback path if "bulk" fails. */ + while (nr_allocated < nr_pages) { +- if (fatal_signal_pending(current)) ++ if (!nofail && fatal_signal_pending(current)) + break; + + if (nid == NUMA_NO_NODE) diff --git a/queue-6.6/net-9p-fix-uninit-value-in-p9_client_rpc.patch b/queue-6.6/net-9p-fix-uninit-value-in-p9_client_rpc.patch new file mode 100644 index 00000000000..23d7083a72e --- /dev/null +++ b/queue-6.6/net-9p-fix-uninit-value-in-p9_client_rpc.patch @@ -0,0 +1,90 @@ +From 25460d6f39024cc3b8241b14c7ccf0d6f11a736a Mon Sep 17 00:00:00 2001 +From: Nikita Zhandarovich +Date: Mon, 8 Apr 2024 07:10:39 -0700 +Subject: net/9p: fix uninit-value in p9_client_rpc() + +From: Nikita Zhandarovich + +commit 25460d6f39024cc3b8241b14c7ccf0d6f11a736a upstream. + +Syzbot with the help of KMSAN reported the following error: + +BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline] +BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 + trace_9p_client_res include/trace/events/9p.h:146 [inline] + p9_client_rpc+0x1314/0x1340 net/9p/client.c:754 + p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 + v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 + v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 + legacy_get_tree+0x114/0x290 fs/fs_context.c:662 + vfs_get_tree+0xa7/0x570 fs/super.c:1797 + do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 + path_mount+0x742/0x1f20 fs/namespace.c:3679 + do_mount fs/namespace.c:3692 [inline] + __do_sys_mount fs/namespace.c:3898 [inline] + __se_sys_mount+0x725/0x810 fs/namespace.c:3875 + __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 + do_syscall_64+0xd5/0x1f0 + entry_SYSCALL_64_after_hwframe+0x6d/0x75 + +Uninit was created at: + __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598 + __alloc_pages_node include/linux/gfp.h:238 [inline] + alloc_pages_node include/linux/gfp.h:261 [inline] + alloc_slab_page mm/slub.c:2175 [inline] + allocate_slab mm/slub.c:2338 [inline] + new_slab+0x2de/0x1400 mm/slub.c:2391 + ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525 + __slab_alloc mm/slub.c:3610 [inline] + __slab_alloc_node mm/slub.c:3663 [inline] + slab_alloc_node mm/slub.c:3835 [inline] + kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852 + p9_tag_alloc net/9p/client.c:278 [inline] + p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641 + p9_client_rpc+0x27e/0x1340 net/9p/client.c:688 + p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031 + v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410 + v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122 + legacy_get_tree+0x114/0x290 fs/fs_context.c:662 + vfs_get_tree+0xa7/0x570 fs/super.c:1797 + do_new_mount+0x71f/0x15e0 fs/namespace.c:3352 + path_mount+0x742/0x1f20 fs/namespace.c:3679 + do_mount fs/namespace.c:3692 [inline] + __do_sys_mount fs/namespace.c:3898 [inline] + __se_sys_mount+0x725/0x810 fs/namespace.c:3875 + __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875 + do_syscall_64+0xd5/0x1f0 + entry_SYSCALL_64_after_hwframe+0x6d/0x75 + +If p9_check_errors() fails early in p9_client_rpc(), req->rc.tag +will not be properly initialized. However, trace_9p_client_res() +ends up trying to print it out anyway before p9_client_rpc() +finishes. + +Fix this issue by assigning default values to p9_fcall fields +such as 'tag' and (just in case KMSAN unearths something new) 'id' +during the tag allocation stage. + +Reported-and-tested-by: syzbot+ff14db38f56329ef68df@syzkaller.appspotmail.com +Fixes: 348b59012e5c ("net/9p: Convert net/9p protocol dumps to tracepoints") +Signed-off-by: Nikita Zhandarovich +Reviewed-by: Christian Schoenebeck +Cc: stable@vger.kernel.org +Message-ID: <20240408141039.30428-1-n.zhandarovich@fintech.ru> +Signed-off-by: Dominique Martinet +Signed-off-by: Greg Kroah-Hartman +--- + net/9p/client.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/net/9p/client.c ++++ b/net/9p/client.c +@@ -235,6 +235,8 @@ static int p9_fcall_init(struct p9_clien + if (!fc->sdata) + return -ENOMEM; + fc->capacity = alloc_msize; ++ fc->id = 0; ++ fc->tag = P9_NOTAG; + return 0; + } + diff --git a/queue-6.6/net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch b/queue-6.6/net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch new file mode 100644 index 00000000000..efe7e9f7ad3 --- /dev/null +++ b/queue-6.6/net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch @@ -0,0 +1,81 @@ +From bb487272380d120295e955ad8acfcbb281b57642 Mon Sep 17 00:00:00 2001 +From: xu xin +Date: Tue, 14 May 2024 20:11:02 +0800 +Subject: net/ipv6: Fix route deleting failure when metric equals 0 + +From: xu xin + +commit bb487272380d120295e955ad8acfcbb281b57642 upstream. + +Problem +========= +After commit 67f695134703 ("ipv6: Move setting default metric for routes"), +we noticed that the logic of assigning the default value of fc_metirc +changed in the ioctl process. That is, when users use ioctl(fd, SIOCADDRT, +rt) with a non-zero metric to add a route, then they may fail to delete a +route with passing in a metric value of 0 to the kernel by ioctl(fd, +SIOCDELRT, rt). But iproute can succeed in deleting it. + +As a reference, when using iproute tools by netlink to delete routes with +a metric parameter equals 0, like the command as follows: + + ip -6 route del fe80::/64 via fe81::5054:ff:fe11:3451 dev eth0 metric 0 + +the user can still succeed in deleting the route entry with the smallest +metric. + +Root Reason +=========== +After commit 67f695134703 ("ipv6: Move setting default metric for routes"), +When ioctl() pass in SIOCDELRT with a zero metric, rtmsg_to_fib6_config() +will set a defalut value (1024) to cfg->fc_metric in kernel, and in +ip6_route_del() and the line 4074 at net/ipv3/route.c, it will check by + + if (cfg->fc_metric && cfg->fc_metric != rt->fib6_metric) + continue; + +and the condition is true and skip the later procedure (deleting route) +because cfg->fc_metric != rt->fib6_metric. But before that commit, +cfg->fc_metric is still zero there, so the condition is false and it +will do the following procedure (deleting). + +Solution +======== +In order to keep a consistent behaviour across netlink() and ioctl(), we +should allow to delete a route with a metric value of 0. So we only do +the default setting of fc_metric in route adding. + +CC: stable@vger.kernel.org # 5.4+ +Fixes: 67f695134703 ("ipv6: Move setting default metric for routes") +Co-developed-by: Fan Yu +Signed-off-by: Fan Yu +Signed-off-by: xu xin +Reviewed-by: David Ahern +Link: https://lore.kernel.org/r/20240514201102055dD2Ba45qKbLlUMxu_DTHP@zte.com.cn +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + net/ipv6/route.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/net/ipv6/route.c ++++ b/net/ipv6/route.c +@@ -4434,7 +4434,7 @@ static void rtmsg_to_fib6_config(struct + .fc_table = l3mdev_fib_table_by_index(net, rtmsg->rtmsg_ifindex) ? + : RT6_TABLE_MAIN, + .fc_ifindex = rtmsg->rtmsg_ifindex, +- .fc_metric = rtmsg->rtmsg_metric ? : IP6_RT_PRIO_USER, ++ .fc_metric = rtmsg->rtmsg_metric, + .fc_expires = rtmsg->rtmsg_info, + .fc_dst_len = rtmsg->rtmsg_dst_len, + .fc_src_len = rtmsg->rtmsg_src_len, +@@ -4464,6 +4464,9 @@ int ipv6_route_ioctl(struct net *net, un + rtnl_lock(); + switch (cmd) { + case SIOCADDRT: ++ /* Only do the default setting of fc_metric in route adding */ ++ if (cfg.fc_metric == 0) ++ cfg.fc_metric = IP6_RT_PRIO_USER; + err = ip6_route_add(&cfg, GFP_KERNEL, NULL); + break; + case SIOCDELRT: diff --git a/queue-6.6/rtla-timerlat-fix-histogram-report-when-a-cpu-count-is-0.patch b/queue-6.6/rtla-timerlat-fix-histogram-report-when-a-cpu-count-is-0.patch new file mode 100644 index 00000000000..f8bc2d6de35 --- /dev/null +++ b/queue-6.6/rtla-timerlat-fix-histogram-report-when-a-cpu-count-is-0.patch @@ -0,0 +1,136 @@ +From 01b05fc0e5f3aec443a9a8ffa0022cbca2fd3608 Mon Sep 17 00:00:00 2001 +From: John Kacur +Date: Fri, 10 May 2024 15:03:18 -0400 +Subject: rtla/timerlat: Fix histogram report when a cpu count is 0 + +From: John Kacur + +commit 01b05fc0e5f3aec443a9a8ffa0022cbca2fd3608 upstream. + +On short runs it is possible to get no samples on a cpu, like this: + + # rtla timerlat hist -u -T50 + + Index IRQ-001 Thr-001 Usr-001 IRQ-002 Thr-002 Usr-002 + 2 1 0 0 0 0 0 + 33 0 1 0 0 0 0 + 36 0 0 1 0 0 0 + 49 0 0 0 1 0 0 + 52 0 0 0 0 1 0 + over: 0 0 0 0 0 0 + count: 1 1 1 1 1 0 + min: 2 33 36 49 52 18446744073709551615 + avg: 2 33 36 49 52 - + max: 2 33 36 49 52 0 + rtla timerlat hit stop tracing + IRQ handler delay: (exit from idle) 48.21 us (91.09 %) + IRQ latency: 49.11 us + Timerlat IRQ duration: 2.17 us (4.09 %) + Blocking thread: 1.01 us (1.90 %) + swapper/2:0 1.01 us + ------------------------------------------------------------------------ + Thread latency: 52.93 us (100%) + + Max timerlat IRQ latency from idle: 49.11 us in cpu 2 + +Note, the value 18446744073709551615 is the same as ~0. + +Fix this by reporting no results for the min, avg and max if the count +is 0. + +Link: https://lkml.kernel.org/r/20240510190318.44295-1-jkacur@redhat.com + +Cc: stable@vger.kernel.org +Fixes: 1eeb6328e8b3 ("rtla/timerlat: Add timerlat hist mode") +Suggested-by: Daniel Bristot de Oliveria +Signed-off-by: John Kacur +Signed-off-by: Daniel Bristot de Oliveira +Signed-off-by: Greg Kroah-Hartman +--- + tools/tracing/rtla/src/timerlat_hist.c | 68 ++++++++++++++++++++++----------- + 1 file changed, 46 insertions(+), 22 deletions(-) + +--- a/tools/tracing/rtla/src/timerlat_hist.c ++++ b/tools/tracing/rtla/src/timerlat_hist.c +@@ -323,17 +323,29 @@ timerlat_print_summary(struct timerlat_h + if (!data->hist[cpu].irq_count && !data->hist[cpu].thread_count) + continue; + +- if (!params->no_irq) +- trace_seq_printf(trace->seq, "%9llu ", +- data->hist[cpu].min_irq); +- +- if (!params->no_thread) +- trace_seq_printf(trace->seq, "%9llu ", +- data->hist[cpu].min_thread); +- +- if (params->user_hist) +- trace_seq_printf(trace->seq, "%9llu ", +- data->hist[cpu].min_user); ++ if (!params->no_irq) { ++ if (data->hist[cpu].irq_count) ++ trace_seq_printf(trace->seq, "%9llu ", ++ data->hist[cpu].min_irq); ++ else ++ trace_seq_printf(trace->seq, " - "); ++ } ++ ++ if (!params->no_thread) { ++ if (data->hist[cpu].thread_count) ++ trace_seq_printf(trace->seq, "%9llu ", ++ data->hist[cpu].min_thread); ++ else ++ trace_seq_printf(trace->seq, " - "); ++ } ++ ++ if (params->user_hist) { ++ if (data->hist[cpu].user_count) ++ trace_seq_printf(trace->seq, "%9llu ", ++ data->hist[cpu].min_user); ++ else ++ trace_seq_printf(trace->seq, " - "); ++ } + } + trace_seq_printf(trace->seq, "\n"); + +@@ -383,17 +395,29 @@ timerlat_print_summary(struct timerlat_h + if (!data->hist[cpu].irq_count && !data->hist[cpu].thread_count) + continue; + +- if (!params->no_irq) +- trace_seq_printf(trace->seq, "%9llu ", +- data->hist[cpu].max_irq); +- +- if (!params->no_thread) +- trace_seq_printf(trace->seq, "%9llu ", +- data->hist[cpu].max_thread); +- +- if (params->user_hist) +- trace_seq_printf(trace->seq, "%9llu ", +- data->hist[cpu].max_user); ++ if (!params->no_irq) { ++ if (data->hist[cpu].irq_count) ++ trace_seq_printf(trace->seq, "%9llu ", ++ data->hist[cpu].max_irq); ++ else ++ trace_seq_printf(trace->seq, " - "); ++ } ++ ++ if (!params->no_thread) { ++ if (data->hist[cpu].thread_count) ++ trace_seq_printf(trace->seq, "%9llu ", ++ data->hist[cpu].max_thread); ++ else ++ trace_seq_printf(trace->seq, " - "); ++ } ++ ++ if (params->user_hist) { ++ if (data->hist[cpu].user_count) ++ trace_seq_printf(trace->seq, "%9llu ", ++ data->hist[cpu].max_user); ++ else ++ trace_seq_printf(trace->seq, " - "); ++ } + } + trace_seq_printf(trace->seq, "\n"); + trace_seq_do_printf(trace->seq); diff --git a/queue-6.6/scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch b/queue-6.6/scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch new file mode 100644 index 00000000000..914ad36d4c1 --- /dev/null +++ b/queue-6.6/scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch @@ -0,0 +1,51 @@ +From d09c05aa35909adb7d29f92f0cd79fdcd1338ef0 Mon Sep 17 00:00:00 2001 +From: "Martin K. Petersen" +Date: Mon, 20 May 2024 22:30:40 -0400 +Subject: scsi: core: Handle devices which return an unusually large VPD page count + +From: Martin K. Petersen + +commit d09c05aa35909adb7d29f92f0cd79fdcd1338ef0 upstream. + +Peter Schneider reported that a system would no longer boot after +updating to 6.8.4. Peter bisected the issue and identified commit +b5fc07a5fb56 ("scsi: core: Consult supported VPD page list prior to +fetching page") as being the culprit. + +Turns out the enclosure device in Peter's system reports a byteswapped +page length for VPD page 0. It reports "02 00" as page length instead +of "00 02". This causes us to attempt to access 516 bytes (page length ++ header) of information despite only 2 pages being present. + +Limit the page search scope to the size of our VPD buffer to guard +against devices returning a larger page count than requested. + +Link: https://lore.kernel.org/r/20240521023040.2703884-1-martin.petersen@oracle.com +Fixes: b5fc07a5fb56 ("scsi: core: Consult supported VPD page list prior to fetching page") +Cc: stable@vger.kernel.org +Reported-by: Peter Schneider +Closes: https://lore.kernel.org/all/eec6ebbf-061b-4a7b-96dc-ea748aa4d035@googlemail.com/ +Tested-by: Peter Schneider +Reviewed-by: Bart Van Assche +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/scsi.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/scsi/scsi.c ++++ b/drivers/scsi/scsi.c +@@ -350,6 +350,13 @@ static int scsi_get_vpd_size(struct scsi + if (result < SCSI_VPD_HEADER_SIZE) + return 0; + ++ if (result > sizeof(vpd)) { ++ dev_warn_once(&sdev->sdev_gendev, ++ "%s: long VPD page 0 length: %d bytes\n", ++ __func__, result); ++ result = sizeof(vpd); ++ } ++ + result -= SCSI_VPD_HEADER_SIZE; + if (!memchr(&vpd[SCSI_VPD_HEADER_SIZE], page, result)) + return 0; diff --git a/queue-6.6/selftests-mm-compaction_test-fix-incorrect-write-of-zero-to-nr_hugepages.patch b/queue-6.6/selftests-mm-compaction_test-fix-incorrect-write-of-zero-to-nr_hugepages.patch new file mode 100644 index 00000000000..0602b9cb95a --- /dev/null +++ b/queue-6.6/selftests-mm-compaction_test-fix-incorrect-write-of-zero-to-nr_hugepages.patch @@ -0,0 +1,37 @@ +From 9ad665ef55eaad1ead1406a58a34f615a7c18b5e Mon Sep 17 00:00:00 2001 +From: Dev Jain +Date: Tue, 21 May 2024 13:13:57 +0530 +Subject: selftests/mm: compaction_test: fix incorrect write of zero to nr_hugepages + +From: Dev Jain + +commit 9ad665ef55eaad1ead1406a58a34f615a7c18b5e upstream. + +Currently, the test tries to set nr_hugepages to zero, but that is not +actually done because the file offset is not reset after read(). Fix that +using lseek(). + +Link: https://lkml.kernel.org/r/20240521074358.675031-3-dev.jain@arm.com +Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory") +Signed-off-by: Dev Jain +Cc: +Cc: Anshuman Khandual +Cc: Shuah Khan +Cc: Sri Jayaramappa +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/mm/compaction_test.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/tools/testing/selftests/mm/compaction_test.c ++++ b/tools/testing/selftests/mm/compaction_test.c +@@ -103,6 +103,8 @@ int check_compaction(unsigned long mem_f + goto close_fd; + } + ++ lseek(fd, 0, SEEK_SET); ++ + /* Start with the initial condition of 0 huge pages*/ + if (write(fd, "0", sizeof(char)) != sizeof(char)) { + perror("Failed to write 0 to /proc/sys/vm/nr_hugepages\n"); diff --git a/queue-6.6/selftests-mm-fix-build-warnings-on-ppc64.patch b/queue-6.6/selftests-mm-fix-build-warnings-on-ppc64.patch new file mode 100644 index 00000000000..a2505cfe1fb --- /dev/null +++ b/queue-6.6/selftests-mm-fix-build-warnings-on-ppc64.patch @@ -0,0 +1,47 @@ +From 1901472fa880e5706f90926cd85a268d2d16bf84 Mon Sep 17 00:00:00 2001 +From: Michael Ellerman +Date: Tue, 21 May 2024 13:02:19 +1000 +Subject: selftests/mm: fix build warnings on ppc64 + +From: Michael Ellerman + +commit 1901472fa880e5706f90926cd85a268d2d16bf84 upstream. + +Fix warnings like: + + In file included from uffd-unit-tests.c:8: + uffd-unit-tests.c: In function `uffd_poison_handle_fault': + uffd-common.h:45:33: warning: format `%llu' expects argument of type + `long long unsigned int', but argument 3 has type `__u64' {aka `long + unsigned int'} [-Wformat=] + +By switching to unsigned long long for u64 for ppc64 builds. + +Link: https://lkml.kernel.org/r/20240521030219.57439-1-mpe@ellerman.id.au +Signed-off-by: Michael Ellerman +Cc: Shuah Khan +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/testing/selftests/mm/gup_test.c | 1 + + tools/testing/selftests/mm/uffd-common.h | 1 + + 2 files changed, 2 insertions(+) + +--- a/tools/testing/selftests/mm/gup_test.c ++++ b/tools/testing/selftests/mm/gup_test.c +@@ -1,3 +1,4 @@ ++#define __SANE_USERSPACE_TYPES__ // Use ll64 + #include + #include + #include +--- a/tools/testing/selftests/mm/uffd-common.h ++++ b/tools/testing/selftests/mm/uffd-common.h +@@ -8,6 +8,7 @@ + #define __UFFD_COMMON_H__ + + #define _GNU_SOURCE ++#define __SANE_USERSPACE_TYPES__ // Use ll64 + #include + #include + #include diff --git a/queue-6.6/series b/queue-6.6/series index 6fa0a35be15..586d8cda96a 100644 --- a/queue-6.6/series +++ b/queue-6.6/series @@ -73,3 +73,30 @@ kbuild-remove-support-for-clang-s-thinlto-caching.patch mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch filemap-add-helper-mapping_max_folio_size.patch iomap-fault-in-smaller-chunks-for-non-large-folio-mappings.patch +i2c-acpi-unbind-mux-adapters-before-delete.patch +hid-i2c-hid-elan-fix-reset-suspend-current-leakage.patch +scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch +net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch +net-9p-fix-uninit-value-in-p9_client_rpc.patch +mm-ksm-fix-ksm_pages_scanned-accounting.patch +mm-ksm-fix-ksm_zero_pages-accounting.patch +kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch +tpm_tis-do-not-flush-uninitialized-work.patch +cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch +intel_th-pci-add-meteor-lake-s-cpu-support.patch +rtla-timerlat-fix-histogram-report-when-a-cpu-count-is-0.patch +sparc64-fix-number-of-online-cpus.patch +mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch +mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch +mm-proc-pid-smaps_rollup-avoid-skipping-vma-after-getting-mmap_lock-again.patch +mm-vmalloc-fix-vmalloc-which-may-return-null-if-called-with-__gfp_nofail.patch +selftests-mm-compaction_test-fix-incorrect-write-of-zero-to-nr_hugepages.patch +selftests-mm-fix-build-warnings-on-ppc64.patch +watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch +bonding-fix-oops-during-rmmod.patch +wifi-ath10k-fix-qcom_rproc_common-dependency.patch +kdb-fix-buffer-overflow-during-tab-complete.patch +kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch +kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch +kdb-merge-identical-case-statements-in-kdb_read.patch +kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch diff --git a/queue-6.6/sparc64-fix-number-of-online-cpus.patch b/queue-6.6/sparc64-fix-number-of-online-cpus.patch new file mode 100644 index 00000000000..348e321151c --- /dev/null +++ b/queue-6.6/sparc64-fix-number-of-online-cpus.patch @@ -0,0 +1,123 @@ +From 98937707fea8375e8acea0aaa0b68a956dd52719 Mon Sep 17 00:00:00 2001 +From: Sam Ravnborg +Date: Sat, 30 Mar 2024 10:57:45 +0100 +Subject: sparc64: Fix number of online CPUs + +From: Sam Ravnborg + +commit 98937707fea8375e8acea0aaa0b68a956dd52719 upstream. + +Nick Bowler reported: + When using newer kernels on my Ultra 60 with dual 450MHz UltraSPARC-II + CPUs, I noticed that only CPU 0 comes up, while older kernels (including + 4.7) are working fine with both CPUs. + + I bisected the failure to this commit: + + 9b2f753ec23710aa32c0d837d2499db92fe9115b is the first bad commit + commit 9b2f753ec23710aa32c0d837d2499db92fe9115b + Author: Atish Patra + Date: Thu Sep 15 14:54:40 2016 -0600 + + sparc64: Fix cpu_possible_mask if nr_cpus is set + + This is a small change that reverts very easily on top of 5.18: there is + just one trivial conflict. Once reverted, both CPUs work again. + + Maybe this is related to the fact that the CPUs on this system are + numbered CPU0 and CPU2 (there is no CPU1)? + +The current code that adjust cpu_possible based on nr_cpu_ids do not +take into account that CPU's may not come one after each other. +Move the chech to the function that setup the cpu_possible mask +so there is no need to adjust it later. + +Signed-off-by: Sam Ravnborg +Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set") +Reported-by: Nick Bowler +Tested-by: Nick Bowler +Link: https://lore.kernel.org/sparclinux/20201009161924.c8f031c079dd852941307870@gmx.de/ +Link: https://lore.kernel.org/all/CADyTPEwt=ZNams+1bpMB1F9w_vUdPsGCt92DBQxxq_VtaLoTdw@mail.gmail.com/ +Cc: stable@vger.kernel.org # v4.8+ +Cc: Andreas Larsson +Cc: David S. Miller +Cc: Atish Patra +Cc: Bob Picco +Cc: Vijay Kumar +Cc: David S. Miller +Reviewed-by: Andreas Larsson +Acked-by: Arnd Bergmann +Link: https://lore.kernel.org/r/20240330-sparc64-warnings-v1-9-37201023ee2f@ravnborg.org +Signed-off-by: Andreas Larsson +Signed-off-by: Greg Kroah-Hartman +--- + arch/sparc/include/asm/smp_64.h | 2 -- + arch/sparc/kernel/prom_64.c | 4 +++- + arch/sparc/kernel/setup_64.c | 1 - + arch/sparc/kernel/smp_64.c | 14 -------------- + 4 files changed, 3 insertions(+), 18 deletions(-) + +--- a/arch/sparc/include/asm/smp_64.h ++++ b/arch/sparc/include/asm/smp_64.h +@@ -47,7 +47,6 @@ void arch_send_call_function_ipi_mask(co + int hard_smp_processor_id(void); + #define raw_smp_processor_id() (current_thread_info()->cpu) + +-void smp_fill_in_cpu_possible_map(void); + void smp_fill_in_sib_core_maps(void); + void __noreturn cpu_play_dead(void); + +@@ -77,7 +76,6 @@ void __cpu_die(unsigned int cpu); + #define smp_fill_in_sib_core_maps() do { } while (0) + #define smp_fetch_global_regs() do { } while (0) + #define smp_fetch_global_pmu() do { } while (0) +-#define smp_fill_in_cpu_possible_map() do { } while (0) + #define smp_init_cpu_poke() do { } while (0) + #define scheduler_poke() do { } while (0) + +--- a/arch/sparc/kernel/prom_64.c ++++ b/arch/sparc/kernel/prom_64.c +@@ -483,7 +483,9 @@ static void *record_one_cpu(struct devic + ncpus_probed++; + #ifdef CONFIG_SMP + set_cpu_present(cpuid, true); +- set_cpu_possible(cpuid, true); ++ ++ if (num_possible_cpus() < nr_cpu_ids) ++ set_cpu_possible(cpuid, true); + #endif + return NULL; + } +--- a/arch/sparc/kernel/setup_64.c ++++ b/arch/sparc/kernel/setup_64.c +@@ -684,7 +684,6 @@ void __init setup_arch(char **cmdline_p) + + paging_init(); + init_sparc64_elf_hwcap(); +- smp_fill_in_cpu_possible_map(); + /* + * Once the OF device tree and MDESC have been setup and nr_cpus has + * been parsed, we know the list of possible cpus. Therefore we can +--- a/arch/sparc/kernel/smp_64.c ++++ b/arch/sparc/kernel/smp_64.c +@@ -1220,20 +1220,6 @@ void __init smp_setup_processor_id(void) + xcall_deliver_impl = hypervisor_xcall_deliver; + } + +-void __init smp_fill_in_cpu_possible_map(void) +-{ +- int possible_cpus = num_possible_cpus(); +- int i; +- +- if (possible_cpus > nr_cpu_ids) +- possible_cpus = nr_cpu_ids; +- +- for (i = 0; i < possible_cpus; i++) +- set_cpu_possible(i, true); +- for (; i < NR_CPUS; i++) +- set_cpu_possible(i, false); +-} +- + void smp_fill_in_sib_core_maps(void) + { + unsigned int i; diff --git a/queue-6.6/tpm_tis-do-not-flush-uninitialized-work.patch b/queue-6.6/tpm_tis-do-not-flush-uninitialized-work.patch new file mode 100644 index 00000000000..60c3ed833ea --- /dev/null +++ b/queue-6.6/tpm_tis-do-not-flush-uninitialized-work.patch @@ -0,0 +1,40 @@ +From 0ea00e249ca992adee54dc71a526ee70ef109e40 Mon Sep 17 00:00:00 2001 +From: Jan Beulich +Date: Wed, 29 May 2024 15:23:25 +0300 +Subject: tpm_tis: Do *not* flush uninitialized work + +From: Jan Beulich + +commit 0ea00e249ca992adee54dc71a526ee70ef109e40 upstream. + +tpm_tis_core_init() may fail before tpm_tis_probe_irq_single() is +called, in which case tpm_tis_remove() unconditionally calling +flush_work() is triggering a warning for .func still being NULL. + +Cc: stable@vger.kernel.org # v6.5+ +Fixes: 481c2d14627d ("tpm,tpm_tis: Disable interrupts after 1000 unhandled IRQs") +Signed-off-by: Jan Beulich +Reviewed-by: Jarkko Sakkinen +Signed-off-by: Jarkko Sakkinen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/char/tpm/tpm_tis_core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c +index 176cd8dbf1db..fdef214b9f6b 100644 +--- a/drivers/char/tpm/tpm_tis_core.c ++++ b/drivers/char/tpm/tpm_tis_core.c +@@ -1020,7 +1020,8 @@ void tpm_tis_remove(struct tpm_chip *chip) + interrupt = 0; + + tpm_tis_write32(priv, reg, ~TPM_GLOBAL_INT_ENABLE & interrupt); +- flush_work(&priv->free_irq_work); ++ if (priv->free_irq_work.func) ++ flush_work(&priv->free_irq_work); + + tpm_tis_clkrun_enable(chip, false); + +-- +2.45.2 + diff --git a/queue-6.6/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch b/queue-6.6/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch new file mode 100644 index 00000000000..10eb4753fec --- /dev/null +++ b/queue-6.6/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch @@ -0,0 +1,107 @@ +From cae58516534e110f4a8558d48aa4435e15519121 Mon Sep 17 00:00:00 2001 +From: Judith Mendez +Date: Wed, 17 Apr 2024 15:57:00 -0500 +Subject: watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin + +From: Judith Mendez + +commit cae58516534e110f4a8558d48aa4435e15519121 upstream. + +On AM62x, the watchdog is pet before the valid window is open. Fix +min_hw_heartbeat and accommodate a 2% + static offset safety margin. +The static offset accounts for max hardware error. + +Remove the hack in the driver which shifts the open window boundary, +since it is no longer necessary due to the fix mentioned above. + +cc: stable@vger.kernel.org +Fixes: 5527483f8f7c ("watchdog: rti-wdt: attach to running watchdog during probe") +Signed-off-by: Judith Mendez +Reviewed-by: Guenter Roeck +Link: https://lore.kernel.org/r/20240417205700.3947408-1-jm@ti.com +Signed-off-by: Guenter Roeck +Signed-off-by: Wim Van Sebroeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/watchdog/rti_wdt.c | 34 +++++++++++++++------------------- + 1 file changed, 15 insertions(+), 19 deletions(-) + +--- a/drivers/watchdog/rti_wdt.c ++++ b/drivers/watchdog/rti_wdt.c +@@ -59,6 +59,8 @@ + #define PON_REASON_EOF_NUM 0xCCCCBBBB + #define RESERVED_MEM_MIN_SIZE 12 + ++#define MAX_HW_ERROR 250 ++ + static int heartbeat = DEFAULT_HEARTBEAT; + + /* +@@ -97,7 +99,7 @@ static int rti_wdt_start(struct watchdog + * to be 50% or less than that; we obviouly want to configure the open + * window as large as possible so we select the 50% option. + */ +- wdd->min_hw_heartbeat_ms = 500 * wdd->timeout; ++ wdd->min_hw_heartbeat_ms = 520 * wdd->timeout + MAX_HW_ERROR; + + /* Generate NMI when wdt expires */ + writel_relaxed(RTIWWDRX_NMI, wdt->base + RTIWWDRXCTRL); +@@ -131,31 +133,33 @@ static int rti_wdt_setup_hw_hb(struct wa + * be petted during the open window; not too early or not too late. + * The HW configuration options only allow for the open window size + * to be 50% or less than that. ++ * To avoid any glitches, we accommodate 2% + max hardware error ++ * safety margin. + */ + switch (wsize) { + case RTIWWDSIZE_50P: +- /* 50% open window => 50% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 500 * heartbeat; ++ /* 50% open window => 52% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 520 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_25P: +- /* 25% open window => 75% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 750 * heartbeat; ++ /* 25% open window => 77% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 770 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_12P5: +- /* 12.5% open window => 87.5% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 875 * heartbeat; ++ /* 12.5% open window => 89.5% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 895 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_6P25: +- /* 6.5% open window => 93.5% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 935 * heartbeat; ++ /* 6.5% open window => 95.5% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 955 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_3P125: +- /* 3.125% open window => 96.9% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 969 * heartbeat; ++ /* 3.125% open window => 98.9% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 989 * heartbeat + MAX_HW_ERROR; + break; + + default: +@@ -233,14 +237,6 @@ static int rti_wdt_probe(struct platform + return -EINVAL; + } + +- /* +- * If watchdog is running at 32k clock, it is not accurate. +- * Adjust frequency down in this case so that we don't pet +- * the watchdog too often. +- */ +- if (wdt->freq < 32768) +- wdt->freq = wdt->freq * 9 / 10; +- + pm_runtime_enable(dev); + ret = pm_runtime_resume_and_get(dev); + if (ret < 0) { diff --git a/queue-6.6/wifi-ath10k-fix-qcom_rproc_common-dependency.patch b/queue-6.6/wifi-ath10k-fix-qcom_rproc_common-dependency.patch new file mode 100644 index 00000000000..39c0f2a6182 --- /dev/null +++ b/queue-6.6/wifi-ath10k-fix-qcom_rproc_common-dependency.patch @@ -0,0 +1,40 @@ +From 21ae74e1bf18331ae5e279bd96304b3630828009 Mon Sep 17 00:00:00 2001 +From: Dmitry Baryshkov +Date: Fri, 17 May 2024 10:00:28 +0300 +Subject: wifi: ath10k: fix QCOM_RPROC_COMMON dependency + +From: Dmitry Baryshkov + +commit 21ae74e1bf18331ae5e279bd96304b3630828009 upstream. + +If ath10k_snoc is built-in, while Qualcomm remoteprocs are built as +modules, compilation fails with: + +/usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in function `ath10k_modem_init': +drivers/net/wireless/ath/ath10k/snoc.c:1534: undefined reference to `qcom_register_ssr_notifier' +/usr/bin/aarch64-linux-gnu-ld: drivers/net/wireless/ath/ath10k/snoc.o: in function `ath10k_modem_deinit': +drivers/net/wireless/ath/ath10k/snoc.c:1551: undefined reference to `qcom_unregister_ssr_notifier' + +Add corresponding dependency to ATH10K_SNOC Kconfig entry so that it's +built as module if QCOM_RPROC_COMMON is built as module too. + +Fixes: 747ff7d3d742 ("ath10k: Don't always treat modem stop events as crashes") +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Kalle Valo +Link: https://msgid.link/20240511-ath10k-snoc-dep-v1-1-9666e3af5c27@linaro.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/ath/ath10k/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/wireless/ath/ath10k/Kconfig ++++ b/drivers/net/wireless/ath/ath10k/Kconfig +@@ -45,6 +45,7 @@ config ATH10K_SNOC + depends on ATH10K + depends on ARCH_QCOM || COMPILE_TEST + depends on QCOM_SMEM ++ depends on QCOM_RPROC_COMMON || QCOM_RPROC_COMMON=n + select QCOM_SCM + select QCOM_QMI_HELPERS + help -- 2.47.3