Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
- drivers/acpi/apei/einj-core.c | 2 +-
+ drivers/acpi/apei/einj-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-diff --git a/drivers/acpi/apei/einj-core.c b/drivers/acpi/apei/einj-core.c
-index 9515bcfe5e97..73903a497d73 100644
--- a/drivers/acpi/apei/einj-core.c
+++ b/drivers/acpi/apei/einj-core.c
-@@ -909,7 +909,7 @@ static void __exit einj_exit(void)
+@@ -903,7 +903,7 @@ static void __exit einj_exit(void)
if (einj_initialized)
platform_driver_unregister(&einj_driver);
}
module_init(einj_init);
---
-2.45.2
-
--- /dev/null
+From a45835a0bb6ef7d5ddbc0714dd760de979cb6ece Mon Sep 17 00:00:00 2001
+From: Tony Battersby <tonyb@cybernetics.com>
+Date: Tue, 14 May 2024 15:57:29 -0400
+Subject: bonding: fix oops during rmmod
+
+From: Tony Battersby <tonyb@cybernetics.com>
+
+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 <tonyb@cybernetics.com>
+Reviewed-by: Simon Horman <horms@kernel.org>
+Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
+Link: https://lore.kernel.org/r/641f914f-3216-4eeb-87dd-91b78aa97773@cybernetics.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -6477,16 +6477,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)
+@@ -6501,10 +6501,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;
+
+ }
+@@ -6513,11 +6514,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));
--- /dev/null
+From e4731baaf29438508197d3a8a6d4f5a8c51663f8 Mon Sep 17 00:00:00 2001
+From: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
+Date: Mon, 27 May 2024 10:41:28 +0530
+Subject: cpufreq: amd-pstate: Fix the inconsistency in max frequency units
+
+From: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
+
+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 <Dhananjay.Ugwekar@amd.com>
+Acked-by: Mario Limonciello <mario.limonciello@amd.com>
+Acked-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
+Tested-by: Peter Jung <ptr1337@cachyos.org>
+Cc: 5.17+ <stable@vger.kernel.org> # 5.17+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -705,7 +705,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;
+
--- /dev/null
+From 0eafc58f2194dbd01d4be40f99a697681171995b Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan+linaro@kernel.org>
+Date: Tue, 7 May 2024 16:48:18 +0200
+Subject: HID: i2c-hid: elan: fix reset suspend current leakage
+
+From: Johan Hovold <johan+linaro@kernel.org>
+
+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: <stable@vger.kernel.org> # 6.0
+Cc: Douglas Anderson <dianders@chromium.org>
+Tested-by: Steev Klimaszewski <steev@kali.org>
+Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Link: https://lore.kernel.org/r/20240507144821.12275-5-johan+linaro@kernel.org
+Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 = {
--- /dev/null
+From 3f858bbf04dbac934ac279aaee05d49eb9910051 Mon Sep 17 00:00:00 2001
+From: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
+Date: Wed, 13 Mar 2024 11:16:32 +1300
+Subject: i2c: acpi: Unbind mux adapters before delete
+
+From: Hamish Martin <hamish.martin@alliedtelesis.co.nz>
+
+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:
+ <TASK>
+ ? 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
+ </TASK>
+---[ 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 <hamish.martin@alliedtelesis.co.nz>
+Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Reviewed-by: Andi Shyti <andi.shyti@kernel.org>
+Fixes: 525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications")
+Cc: <stable@vger.kernel.org> # v4.8+
+Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From a4f813c3ec9d1c32bc402becd1f011b3904dd699 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Mon, 29 Apr 2024 16:01:18 +0300
+Subject: intel_th: pci: Add Meteor Lake-S CPU support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream.
+
+Add support for the Trace Hub in Meteor Lake-S CPU.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20240429130119.1518073-15-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From 0110c4b110477bb1f19b0d02361846be7ab08300 Mon Sep 17 00:00:00 2001
+From: Sunil V L <sunilvl@ventanamicro.com>
+Date: Mon, 27 May 2024 13:41:13 +0530
+Subject: irqchip/riscv-intc: Prevent memory leak when riscv_intc_init_common() fails
+
+From: Sunil V L <sunilvl@ventanamicro.com>
+
+commit 0110c4b110477bb1f19b0d02361846be7ab08300 upstream.
+
+When riscv_intc_init_common() fails, the firmware node allocated is not
+freed. Add the missing free().
+
+Fixes: 7023b9d83f03 ("irqchip/riscv-intc: Add ACPI support")
+Signed-off-by: Sunil V L <sunilvl@ventanamicro.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Reviewed-by: Anup Patel <anup@brainfault.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20240527081113.616189-1-sunilvl@ventanamicro.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/irqchip/irq-riscv-intc.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/irqchip/irq-riscv-intc.c
++++ b/drivers/irqchip/irq-riscv-intc.c
+@@ -253,8 +253,9 @@ IRQCHIP_DECLARE(andes, "andestech,cpu-in
+ static int __init riscv_intc_acpi_init(union acpi_subtable_headers *header,
+ const unsigned long end)
+ {
+- struct fwnode_handle *fn;
+ struct acpi_madt_rintc *rintc;
++ struct fwnode_handle *fn;
++ int rc;
+
+ rintc = (struct acpi_madt_rintc *)header;
+
+@@ -273,7 +274,11 @@ static int __init riscv_intc_acpi_init(u
+ return -ENOMEM;
+ }
+
+- return riscv_intc_init_common(fn, &riscv_intc_chip);
++ rc = riscv_intc_init_common(fn, &riscv_intc_chip);
++ if (rc)
++ irq_domain_free_fwnode(fn);
++
++ return rc;
+ }
+
+ IRQCHIP_ACPI_DECLARE(riscv_intc, ACPI_MADT_TYPE_RINTC, NULL,
--- /dev/null
+From e9730744bf3af04cda23799029342aa3cddbc454 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:34 +0100
+Subject: kdb: Fix buffer overflow during tab-complete
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <justinstitt@google.com>
+Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziUJLpw@mail.gmail.com/
+Cc: stable@vger.kernel.org
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Justin Stitt <justinstitt@google.com>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From db2f9c7dc29114f531df4a425d0867d01e1f1e28 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:36 +0100
+Subject: kdb: Fix console handling when editing and tab-completing commands
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <dianders@chromium.org>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-3-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 6244917f377bf64719551b58592a02a0336a7439 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:37 +0100
+Subject: kdb: Merge identical case statements in kdb_read()
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <dianders@chromium.org>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-4-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From c9b51ddb66b1d96e4d364c088da0f1dfb004c574 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+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 <daniel.thompson@linaro.org>
+
+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 <dianders@chromium.org>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-5-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 09b35989421dfd5573f0b4683c7700a7483c71f9 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:35 +0100
+Subject: kdb: Use format-strings rather than '\0' injection in kdb_read()
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <justinstitt@google.com>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-2-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 2ef3cec44c60ae171b287db7fc2aa341586d65ba Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Tue, 28 May 2024 12:48:06 +0200
+Subject: kmsan: do not wipe out origin when doing partial unpoisoning
+
+From: Alexander Potapenko <glider@google.com>
+
+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 <glider@google.com>
+Reported-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
+ Link: https://lore.kernel.org/lkml/20240524232804.1984355-1-bjohannesmeyer@gmail.com/T/
+Reviewed-by: Marco Elver <elver@google.com>
+Tested-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/kmsan/core.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/mm/kmsan/core.c
++++ b/mm/kmsan/core.c
+@@ -196,8 +196,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));
+@@ -225,8 +224,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)
--- /dev/null
+From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001
+From: Frank van der Linden <fvdl@google.com>
+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 <fvdl@google.com>
+
+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 <fvdl@google.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/cma.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/mm/cma.c
++++ b/mm/cma.c
+@@ -182,10 +182,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;
--- /dev/null
+From 8daf9c702ee7f825f0de8600abff764acfedea13 Mon Sep 17 00:00:00 2001
+From: Oscar Salvador <osalvador@suse.de>
+Date: Tue, 28 May 2024 22:53:23 +0200
+Subject: mm/hugetlb: do not call vma_add_reservation upon ENOMEM
+
+From: Oscar Salvador <osalvador@suse.de>
+
+commit 8daf9c702ee7f825f0de8600abff764acfedea13 upstream.
+
+sysbot reported a splat [1] on __unmap_hugepage_range(). This is because
+vma_needs_reservation() can return -ENOMEM if
+allocate_file_region_entries() fails to allocate the file_region struct
+for the reservation.
+
+Check for that and do not call vma_add_reservation() if that is the case,
+otherwise region_abort() and region_del() will see that we do not have any
+file_regions.
+
+If we detect that vma_needs_reservation() returned -ENOMEM, we clear the
+hugetlb_restore_reserve flag as if this reservation was still consumed, so
+free_huge_folio() will not increment the resv count.
+
+[1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa
+
+Link: https://lkml.kernel.org/r/20240528205323.20439-1-osalvador@suse.de
+Fixes: df7a6d1f6405 ("mm/hugetlb: restore the reservation if needed")
+Signed-off-by: Oscar Salvador <osalvador@suse.de>
+Reported-and-tested-by: syzbot+d3fe2dc5ffe9380b714b@syzkaller.appspotmail.com
+Closes: https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/
+Cc: Breno Leitao <leitao@debian.org>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/hugetlb.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -5774,8 +5774,20 @@ void __unmap_hugepage_range(struct mmu_g
+ * do_exit() will not see it, and will keep the reservation
+ * forever.
+ */
+- if (adjust_reservation && vma_needs_reservation(h, vma, address))
+- vma_add_reservation(h, vma, address);
++ if (adjust_reservation) {
++ int rc = vma_needs_reservation(h, vma, address);
++
++ if (rc < 0)
++ /* Pressumably allocate_file_region_entries failed
++ * to allocate a file_region struct. Clear
++ * hugetlb_restore_reserve so that global reserve
++ * count will not be incremented by free_huge_folio.
++ * Act as if we consumed the reservation.
++ */
++ folio_clear_hugetlb_restore_reserve(page_folio(page));
++ else if (rc)
++ vma_add_reservation(h, vma, address);
++ }
+
+ tlb_remove_page_size(tlb, page, huge_page_size(h));
+ /*
--- /dev/null
+From 55d134a7b499c77e7cfd0ee41046f3c376e791e5 Mon Sep 17 00:00:00 2001
+From: Frank van der Linden <fvdl@google.com>
+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 <fvdl@google.com>
+
+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 <fvdl@google.com>
+Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/hugetlb.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/mm/hugetlb.c
++++ b/mm/hugetlb.c
+@@ -7879,9 +7879,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);
--- /dev/null
+From 730cdc2c72c6905a2eda2fccbbf67dcef1206590 Mon Sep 17 00:00:00 2001
+From: Chengming Zhou <chengming.zhou@linux.dev>
+Date: Tue, 28 May 2024 13:15:21 +0800
+Subject: mm/ksm: fix ksm_pages_scanned accounting
+
+From: Chengming Zhou <chengming.zhou@linux.dev>
+
+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 <chengming.zhou@linux.dev>
+Acked-by: David Hildenbrand <david@redhat.com>
+Reviewed-by: xu xin <xu.xin16@zte.com.cn>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Ran Xiaokai <ran.xiaokai@zte.com.cn>
+Cc: Stefan Roesch <shr@devkernel.io>
+Cc: Yang Yang <yang.yang29@zte.com.cn>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/ksm.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/mm/ksm.c
++++ b/mm/ksm.c
+@@ -2747,18 +2747,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)
--- /dev/null
+From c2dc78b86e0821ecf9a9d0c35dba2618279a5bb6 Mon Sep 17 00:00:00 2001
+From: Chengming Zhou <chengming.zhou@linux.dev>
+Date: Tue, 28 May 2024 13:15:22 +0800
+Subject: mm/ksm: fix ksm_zero_pages accounting
+
+From: Chengming Zhou <chengming.zhou@linux.dev>
+
+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 <chengming.zhou@linux.dev>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Ran Xiaokai <ran.xiaokai@zte.com.cn>
+Cc: Stefan Roesch <shr@devkernel.io>
+Cc: xu xin <xu.xin16@zte.com.cn>
+Cc: Yang Yang <yang.yang29@zte.com.cn>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -3214,7 +3214,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
+@@ -988,7 +988,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_WALKS_MMU
+ struct {
+--- a/mm/ksm.c
++++ b/mm/ksm.c
+@@ -296,7 +296,7 @@ static bool ksm_use_zero_pages __read_mo
+ static bool ksm_smart_scan = true;
+
+ /* 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);
+
+ /* The number of pages that have been skipped due to "smart scanning" */
+ static unsigned long ksm_pages_skipped;
+@@ -1428,8 +1428,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
+@@ -3368,7 +3367,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 */
+@@ -3657,7 +3656,7 @@ KSM_ATTR_RO(pages_skipped);
+ 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);
+
+@@ -3666,7 +3665,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);
--- /dev/null
+From 8cf360b9d6a840700e06864236a01a883b34bbad Mon Sep 17 00:00:00 2001
+From: Miaohe Lin <linmiaohe@huawei.com>
+Date: Thu, 23 May 2024 15:12:17 +0800
+Subject: mm/memory-failure: fix handling of dissolved but not taken off from buddy pages
+
+From: Miaohe Lin <linmiaohe@huawei.com>
+
+commit 8cf360b9d6a840700e06864236a01a883b34bbad upstream.
+
+When I did memory failure tests recently, below panic occurs:
+
+page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
+flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
+raw: 06fffe0000000000 dead000000000100 dead000000000122 0000000000000000
+raw: 0000000000000000 0000000000000009 00000000ffffffff 0000000000000000
+page dumped because: VM_BUG_ON_PAGE(!PageBuddy(page))
+------------[ cut here ]------------
+kernel BUG at include/linux/page-flags.h:1009!
+invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
+RIP: 0010:__del_page_from_free_list+0x151/0x180
+RSP: 0018:ffffa49c90437998 EFLAGS: 00000046
+RAX: 0000000000000035 RBX: 0000000000000009 RCX: ffff8dd8dfd1c9c8
+RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff8dd8dfd1c9c0
+RBP: ffffd901233b8000 R08: ffffffffab5511f8 R09: 0000000000008c69
+R10: 0000000000003c15 R11: ffffffffab5511f8 R12: ffff8dd8fffc0c80
+R13: 0000000000000001 R14: ffff8dd8fffc0c80 R15: 0000000000000009
+FS: 00007ff916304740(0000) GS:ffff8dd8dfd00000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 000055eae50124c8 CR3: 00000008479e0000 CR4: 00000000000006f0
+Call Trace:
+ <TASK>
+ __rmqueue_pcplist+0x23b/0x520
+ get_page_from_freelist+0x26b/0xe40
+ __alloc_pages_noprof+0x113/0x1120
+ __folio_alloc_noprof+0x11/0xb0
+ alloc_buddy_hugetlb_folio.isra.0+0x5a/0x130
+ __alloc_fresh_hugetlb_folio+0xe7/0x140
+ alloc_pool_huge_folio+0x68/0x100
+ set_max_huge_pages+0x13d/0x340
+ hugetlb_sysctl_handler_common+0xe8/0x110
+ proc_sys_call_handler+0x194/0x280
+ vfs_write+0x387/0x550
+ ksys_write+0x64/0xe0
+ do_syscall_64+0xc2/0x1d0
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+RIP: 0033:0x7ff916114887
+RSP: 002b:00007ffec8a2fd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+RAX: ffffffffffffffda RBX: 000055eae500e350 RCX: 00007ff916114887
+RDX: 0000000000000004 RSI: 000055eae500e390 RDI: 0000000000000003
+RBP: 000055eae50104c0 R08: 0000000000000000 R09: 000055eae50104c0
+R10: 0000000000000077 R11: 0000000000000246 R12: 0000000000000004
+R13: 0000000000000004 R14: 00007ff916216b80 R15: 00007ff916216a00
+ </TASK>
+Modules linked in: mce_inject hwpoison_inject
+---[ end trace 0000000000000000 ]---
+
+And before the panic, there had an warning about bad page state:
+
+BUG: Bad page state in process page-types pfn:8cee00
+page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x8cee00
+flags: 0x6fffe0000000000(node=1|zone=2|lastcpupid=0x7fff)
+page_type: 0xffffff7f(buddy)
+raw: 06fffe0000000000 ffffd901241c0008 ffffd901240f8008 0000000000000000
+raw: 0000000000000000 0000000000000009 00000000ffffff7f 0000000000000000
+page dumped because: nonzero mapcount
+Modules linked in: mce_inject hwpoison_inject
+CPU: 8 PID: 154211 Comm: page-types Not tainted 6.9.0-rc4-00499-g5544ec3178e2-dirty #22
+Call Trace:
+ <TASK>
+ dump_stack_lvl+0x83/0xa0
+ bad_page+0x63/0xf0
+ free_unref_page+0x36e/0x5c0
+ unpoison_memory+0x50b/0x630
+ simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110
+ debugfs_attr_write+0x42/0x60
+ full_proxy_write+0x5b/0x80
+ vfs_write+0xcd/0x550
+ ksys_write+0x64/0xe0
+ do_syscall_64+0xc2/0x1d0
+ entry_SYSCALL_64_after_hwframe+0x77/0x7f
+RIP: 0033:0x7f189a514887
+RSP: 002b:00007ffdcd899718 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
+RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f189a514887
+RDX: 0000000000000009 RSI: 00007ffdcd899730 RDI: 0000000000000003
+RBP: 00007ffdcd8997a0 R08: 0000000000000000 R09: 00007ffdcd8994b2
+R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffdcda199a8
+R13: 0000000000404af1 R14: 000000000040ad78 R15: 00007f189a7a5040
+ </TASK>
+
+The root cause should be the below race:
+
+ memory_failure
+ try_memory_failure_hugetlb
+ me_huge_page
+ __page_handle_poison
+ dissolve_free_hugetlb_folio
+ drain_all_pages -- Buddy page can be isolated e.g. for compaction.
+ take_page_off_buddy -- Failed as page is not in the buddy list.
+ -- Page can be putback into buddy after compaction.
+ page_ref_inc -- Leads to buddy page with refcnt = 1.
+
+Then unpoison_memory() can unpoison the page and send the buddy page back
+into buddy list again leading to the above bad page state warning. And
+bad_page() will call page_mapcount_reset() to remove PageBuddy from buddy
+page leading to later VM_BUG_ON_PAGE(!PageBuddy(page)) when trying to
+allocate this page.
+
+Fix this issue by only treating __page_handle_poison() as successful when
+it returns 1.
+
+Link: https://lkml.kernel.org/r/20240523071217.1696196-1-linmiaohe@huawei.com
+Fixes: ceaf8fbea79a ("mm, hwpoison: skip raw hwpoison page in freeing 1GB hugepage")
+Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
+Cc: Naoya Horiguchi <nao.horiguchi@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/memory-failure.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/mm/memory-failure.c
++++ b/mm/memory-failure.c
+@@ -1218,7 +1218,7 @@ static int me_huge_page(struct page_stat
+ * subpages.
+ */
+ folio_put(folio);
+- if (__page_handle_poison(p) >= 0) {
++ if (__page_handle_poison(p) > 0) {
+ page_ref_inc(p);
+ res = MF_RECOVERED;
+ } else {
+@@ -2097,7 +2097,7 @@ retry:
+ */
+ if (res == 0) {
+ folio_unlock(folio);
+- if (__page_handle_poison(p) >= 0) {
++ if (__page_handle_poison(p) > 0) {
+ page_ref_inc(p);
+ res = MF_RECOVERED;
+ } else {
--- /dev/null
+From 6d065f507d82307d6161ac75c025111fb8b08a46 Mon Sep 17 00:00:00 2001
+From: Yuanyuan Zhong <yzhong@purestorage.com>
+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 <yzhong@purestorage.com>
+
+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 <yzhong@purestorage.com>
+Reviewed-by: Mohamed Khalfella <mkhalfella@purestorage.com>
+Cc: David Hildenbrand <david@redhat.com>
+Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 8e0545c83d672750632f46e3f9ad95c48c91a0fc Mon Sep 17 00:00:00 2001
+From: "Hailong.Liu" <hailong.liu@oppo.com>
+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 <hailong.liu@oppo.com>
+
+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 <hailong.liu@oppo.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Suggested-by: Barry Song <21cnbao@gmail.com>
+Reported-by: Oven <liyangouwen1@oppo.com>
+Reviewed-by: Barry Song <baohua@kernel.org>
+Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
+Cc: Chao Yu <chao@kernel.org>
+Cc: Christoph Hellwig <hch@infradead.org>
+Cc: Gao Xiang <xiang@kernel.org>
+Cc: Lorenzo Stoakes <lstoakes@gmail.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ mm/vmalloc.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/mm/vmalloc.c
++++ b/mm/vmalloc.c
+@@ -3492,7 +3492,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;
+
+@@ -3549,12 +3549,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)
--- /dev/null
+From 25460d6f39024cc3b8241b14c7ccf0d6f11a736a Mon Sep 17 00:00:00 2001
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+Date: Mon, 8 Apr 2024 07:10:39 -0700
+Subject: net/9p: fix uninit-value in p9_client_rpc()
+
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+
+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 <n.zhandarovich@fintech.ru>
+Reviewed-by: Christian Schoenebeck <linux_oss@crudebyte.com>
+Cc: stable@vger.kernel.org
+Message-ID: <20240408141039.30428-1-n.zhandarovich@fintech.ru>
+Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
--- /dev/null
+From bb487272380d120295e955ad8acfcbb281b57642 Mon Sep 17 00:00:00 2001
+From: xu xin <xu.xin16@zte.com.cn>
+Date: Tue, 14 May 2024 20:11:02 +0800
+Subject: net/ipv6: Fix route deleting failure when metric equals 0
+
+From: xu xin <xu.xin16@zte.com.cn>
+
+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 <fan.yu9@zte.com.cn>
+Signed-off-by: Fan Yu <fan.yu9@zte.com.cn>
+Signed-off-by: xu xin <xu.xin16@zte.com.cn>
+Reviewed-by: David Ahern <dsahern@kernel.org>
+Link: https://lore.kernel.org/r/20240514201102055dD2Ba45qKbLlUMxu_DTHP@zte.com.cn
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/ipv6/route.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/net/ipv6/route.c
++++ b/net/ipv6/route.c
+@@ -4446,7 +4446,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,
+@@ -4476,6 +4476,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:
--- /dev/null
+From 33700a0c9b562700c28d31360a5f04508f459a45 Mon Sep 17 00:00:00 2001
+From: Dmitry Safonov <0x7f454c46@gmail.com>
+Date: Wed, 29 May 2024 18:29:32 +0100
+Subject: net/tcp: Don't consider TCP_CLOSE in TCP_AO_ESTABLISHED
+
+From: Dmitry Safonov <0x7f454c46@gmail.com>
+
+commit 33700a0c9b562700c28d31360a5f04508f459a45 upstream.
+
+TCP_CLOSE may or may not have current/rnext keys and should not be
+considered "established". The fast-path for TCP_CLOSE is
+SKB_DROP_REASON_TCP_CLOSE. This is what tcp_rcv_state_process() does
+anyways. Add an early drop path to not spend any time verifying
+segment signatures for sockets in TCP_CLOSE state.
+
+Cc: stable@vger.kernel.org # v6.7
+Fixes: 0a3a809089eb ("net/tcp: Verify inbound TCP-AO signed segments")
+Signed-off-by: Dmitry Safonov <0x7f454c46@gmail.com>
+Link: https://lore.kernel.org/r/20240529-tcp_ao-sk_state-v1-1-d69b5d323c52@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/net/tcp_ao.h | 7 ++++---
+ net/ipv4/tcp_ao.c | 13 +++++++++----
+ 2 files changed, 13 insertions(+), 7 deletions(-)
+
+--- a/include/net/tcp_ao.h
++++ b/include/net/tcp_ao.h
+@@ -86,7 +86,8 @@ static inline int tcp_ao_sizeof_key(cons
+ struct tcp_ao_info {
+ /* List of tcp_ao_key's */
+ struct hlist_head head;
+- /* current_key and rnext_key aren't maintained on listen sockets.
++ /* current_key and rnext_key are maintained on sockets
++ * in TCP_AO_ESTABLISHED states.
+ * Their purpose is to cache keys on established connections,
+ * saving needless lookups. Never dereference any of them from
+ * listen sockets.
+@@ -201,9 +202,9 @@ struct tcp6_ao_context {
+ };
+
+ struct tcp_sigpool;
++/* Established states are fast-path and there always is current_key/rnext_key */
+ #define TCP_AO_ESTABLISHED (TCPF_ESTABLISHED | TCPF_FIN_WAIT1 | TCPF_FIN_WAIT2 | \
+- TCPF_CLOSE | TCPF_CLOSE_WAIT | \
+- TCPF_LAST_ACK | TCPF_CLOSING)
++ TCPF_CLOSE_WAIT | TCPF_LAST_ACK | TCPF_CLOSING)
+
+ int tcp_ao_transmit_skb(struct sock *sk, struct sk_buff *skb,
+ struct tcp_ao_key *key, struct tcphdr *th,
+--- a/net/ipv4/tcp_ao.c
++++ b/net/ipv4/tcp_ao.c
+@@ -933,6 +933,7 @@ tcp_inbound_ao_hash(struct sock *sk, con
+ struct tcp_ao_key *key;
+ __be32 sisn, disn;
+ u8 *traffic_key;
++ int state;
+ u32 sne = 0;
+
+ info = rcu_dereference(tcp_sk(sk)->ao_info);
+@@ -948,8 +949,9 @@ tcp_inbound_ao_hash(struct sock *sk, con
+ disn = 0;
+ }
+
++ state = READ_ONCE(sk->sk_state);
+ /* Fast-path */
+- if (likely((1 << sk->sk_state) & TCP_AO_ESTABLISHED)) {
++ if (likely((1 << state) & TCP_AO_ESTABLISHED)) {
+ enum skb_drop_reason err;
+ struct tcp_ao_key *current_key;
+
+@@ -988,6 +990,9 @@ tcp_inbound_ao_hash(struct sock *sk, con
+ return SKB_NOT_DROPPED_YET;
+ }
+
++ if (unlikely(state == TCP_CLOSE))
++ return SKB_DROP_REASON_TCP_CLOSE;
++
+ /* Lookup key based on peer address and keyid.
+ * current_key and rnext_key must not be used on tcp listen
+ * sockets as otherwise:
+@@ -1001,7 +1006,7 @@ tcp_inbound_ao_hash(struct sock *sk, con
+ if (th->syn && !th->ack)
+ goto verify_hash;
+
+- if ((1 << sk->sk_state) & (TCPF_LISTEN | TCPF_NEW_SYN_RECV)) {
++ if ((1 << state) & (TCPF_LISTEN | TCPF_NEW_SYN_RECV)) {
+ /* Make the initial syn the likely case here */
+ if (unlikely(req)) {
+ sne = tcp_ao_compute_sne(0, tcp_rsk(req)->rcv_isn,
+@@ -1018,14 +1023,14 @@ tcp_inbound_ao_hash(struct sock *sk, con
+ /* no way to figure out initial sisn/disn - drop */
+ return SKB_DROP_REASON_TCP_FLAGS;
+ }
+- } else if ((1 << sk->sk_state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
++ } else if ((1 << state) & (TCPF_SYN_SENT | TCPF_SYN_RECV)) {
+ disn = info->lisn;
+ if (th->syn || th->rst)
+ sisn = th->seq;
+ else
+ sisn = info->risn;
+ } else {
+- WARN_ONCE(1, "TCP-AO: Unexpected sk_state %d", sk->sk_state);
++ WARN_ONCE(1, "TCP-AO: Unexpected sk_state %d", state);
+ return SKB_DROP_REASON_TCP_AOFAILURE;
+ }
+ verify_hash:
--- /dev/null
+From 5b3cde198878b2f3269d5e7efbc0d514899b1fd8 Mon Sep 17 00:00:00 2001
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+Date: Tue, 4 Jun 2024 11:00:22 -0300
+Subject: Revert "perf record: Reduce memory for recording PERF_RECORD_LOST_SAMPLES event"
+
+From: Arnaldo Carvalho de Melo <acme@redhat.com>
+
+commit 5b3cde198878b2f3269d5e7efbc0d514899b1fd8 upstream.
+
+This reverts commit 7d1405c71df21f6c394b8a885aa8a133f749fa22.
+
+This causes segfaults in some cases, as reported by Milian:
+
+ ```
+ sudo /usr/bin/perf record -z --call-graph dwarf -e cycles -e
+ raw_syscalls:sys_enter ls
+ ...
+ [ perf record: Woken up 3 times to write data ]
+ malloc(): invalid next size (unsorted)
+ Aborted
+ ```
+
+ Backtrace with GDB + debuginfod:
+
+ ```
+ malloc(): invalid next size (unsorted)
+
+ Thread 1 "perf" received signal SIGABRT, Aborted.
+ __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6,
+ no_tid=no_tid@entry=0) at pthread_kill.c:44
+ Downloading source file /usr/src/debug/glibc/glibc/nptl/pthread_kill.c
+ 44 return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
+ (ret) : 0;
+ (gdb) bt
+ #0 __pthread_kill_implementation (threadid=<optimized out>,
+ signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44
+ #1 0x00007ffff6ea8eb3 in __pthread_kill_internal (threadid=<optimized out>,
+ signo=6) at pthread_kill.c:78
+ #2 0x00007ffff6e50a30 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/
+ raise.c:26
+ #3 0x00007ffff6e384c3 in __GI_abort () at abort.c:79
+ #4 0x00007ffff6e39354 in __libc_message_impl (fmt=fmt@entry=0x7ffff6fc22ea
+ "%s\n") at ../sysdeps/posix/libc_fatal.c:132
+ #5 0x00007ffff6eb3085 in malloc_printerr (str=str@entry=0x7ffff6fc5850
+ "malloc(): invalid next size (unsorted)") at malloc.c:5772
+ #6 0x00007ffff6eb657c in _int_malloc (av=av@entry=0x7ffff6ff6ac0
+ <main_arena>, bytes=bytes@entry=368) at malloc.c:4081
+ #7 0x00007ffff6eb877e in __libc_calloc (n=<optimized out>,
+ elem_size=<optimized out>) at malloc.c:3754
+ #8 0x000055555569bdb6 in perf_session.do_write_header ()
+ #9 0x00005555555a373a in __cmd_record.constprop.0 ()
+ #10 0x00005555555a6846 in cmd_record ()
+ #11 0x000055555564db7f in run_builtin ()
+ #12 0x000055555558ed77 in main ()
+ ```
+
+ Valgrind memcheck:
+ ```
+ ==45136== Invalid write of size 8
+ ==45136== at 0x2B38A5: perf_event__synthesize_id_sample (in /usr/bin/perf)
+ ==45136== by 0x157069: __cmd_record.constprop.0 (in /usr/bin/perf)
+ ==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
+ ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
+ ==45136== by 0x142D76: main (in /usr/bin/perf)
+ ==45136== Address 0x6a866a8 is 0 bytes after a block of size 40 alloc'd
+ ==45136== at 0x4849BF3: calloc (vg_replace_malloc.c:1675)
+ ==45136== by 0x3574AB: zalloc (in /usr/bin/perf)
+ ==45136== by 0x1570E0: __cmd_record.constprop.0 (in /usr/bin/perf)
+ ==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
+ ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
+ ==45136== by 0x142D76: main (in /usr/bin/perf)
+ ==45136==
+ ==45136== Syscall param write(buf) points to unaddressable byte(s)
+ ==45136== at 0x575953D: __libc_write (write.c:26)
+ ==45136== by 0x575953D: write (write.c:24)
+ ==45136== by 0x35761F: ion (in /usr/bin/perf)
+ ==45136== by 0x357778: writen (in /usr/bin/perf)
+ ==45136== by 0x1548F7: record__write (in /usr/bin/perf)
+ ==45136== by 0x15708A: __cmd_record.constprop.0 (in /usr/bin/perf)
+ ==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
+ ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
+ ==45136== by 0x142D76: main (in /usr/bin/perf)
+ ==45136== Address 0x6a866a8 is 0 bytes after a block of size 40 alloc'd
+ ==45136== at 0x4849BF3: calloc (vg_replace_malloc.c:1675)
+ ==45136== by 0x3574AB: zalloc (in /usr/bin/perf)
+ ==45136== by 0x1570E0: __cmd_record.constprop.0 (in /usr/bin/perf)
+ ==45136== by 0x15A845: cmd_record (in /usr/bin/perf)
+ ==45136== by 0x201B7E: run_builtin (in /usr/bin/perf)
+ ==45136== by 0x142D76: main (in /usr/bin/perf)
+ ==45136==
+ -----
+
+Closes: https://lore.kernel.org/linux-perf-users/23879991.0LEYPuXRzz@milian-workstation/
+Reported-by: Milian Wolff <milian.wolff@kdab.com>
+Tested-by: Milian Wolff <milian.wolff@kdab.com>
+Cc: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Jiri Olsa <jolsa@kernel.org>
+Cc: Kan Liang <kan.liang@linux.intel.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: stable@kernel.org # 6.8+
+Link: https://lore.kernel.org/lkml/Zl9ksOlHJHnKM70p@x1
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/perf/builtin-record.c | 6 ++----
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+--- a/tools/perf/builtin-record.c
++++ b/tools/perf/builtin-record.c
+@@ -1956,8 +1956,7 @@ static void record__read_lost_samples(st
+
+ if (count.lost) {
+ if (!lost) {
+- lost = zalloc(sizeof(*lost) +
+- session->machines.host.id_hdr_size);
++ lost = zalloc(PERF_SAMPLE_MAX_SIZE);
+ if (!lost) {
+ pr_debug("Memory allocation failed\n");
+ return;
+@@ -1973,8 +1972,7 @@ static void record__read_lost_samples(st
+ lost_count = perf_bpf_filter__lost_count(evsel);
+ if (lost_count) {
+ if (!lost) {
+- lost = zalloc(sizeof(*lost) +
+- session->machines.host.id_hdr_size);
++ lost = zalloc(PERF_SAMPLE_MAX_SIZE);
+ if (!lost) {
+ pr_debug("Memory allocation failed\n");
+ return;
--- /dev/null
+From 03e38d315f3c5258270ad50f2ae784b6372e87c3 Mon Sep 17 00:00:00 2001
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+Date: Tue, 4 Jun 2024 14:29:26 +0200
+Subject: Revert "xsk: Document ability to redirect to any socket bound to the same umem"
+
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+
+commit 03e38d315f3c5258270ad50f2ae784b6372e87c3 upstream.
+
+This reverts commit 968595a93669b6b4f6d1fcf80cf2d97956b6868f.
+
+Reported-by: Yuval El-Hanany <YuvalE@radware.com>
+Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Link: https://lore.kernel.org/xdp-newbies/8100DBDC-0B7C-49DB-9995-6027F6E63147@radware.com
+Link: https://lore.kernel.org/bpf/20240604122927.29080-3-magnus.karlsson@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/networking/af_xdp.rst | 31 ++++++++++++-----------------
+ 1 file changed, 13 insertions(+), 18 deletions(-)
+
+diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst
+index 72da7057e4cf..dceeb0d763aa 100644
+--- a/Documentation/networking/af_xdp.rst
++++ b/Documentation/networking/af_xdp.rst
+@@ -329,24 +329,23 @@ XDP_SHARED_UMEM option and provide the initial socket's fd in the
+ sxdp_shared_umem_fd field as you registered the UMEM on that
+ socket. These two sockets will now share one and the same UMEM.
+
+-In this case, it is possible to use the NIC's packet steering
+-capabilities to steer the packets to the right queue. This is not
+-possible in the previous example as there is only one queue shared
+-among sockets, so the NIC cannot do this steering as it can only steer
+-between queues.
++There is no need to supply an XDP program like the one in the previous
++case where sockets were bound to the same queue id and
++device. Instead, use the NIC's packet steering capabilities to steer
++the packets to the right queue. In the previous example, there is only
++one queue shared among sockets, so the NIC cannot do this steering. It
++can only steer between queues.
+
+-In libxdp (or libbpf prior to version 1.0), you need to use the
+-xsk_socket__create_shared() API as it takes a reference to a FILL ring
+-and a COMPLETION ring that will be created for you and bound to the
+-shared UMEM. You can use this function for all the sockets you create,
+-or you can use it for the second and following ones and use
+-xsk_socket__create() for the first one. Both methods yield the same
+-result.
++In libbpf, you need to use the xsk_socket__create_shared() API as it
++takes a reference to a FILL ring and a COMPLETION ring that will be
++created for you and bound to the shared UMEM. You can use this
++function for all the sockets you create, or you can use it for the
++second and following ones and use xsk_socket__create() for the first
++one. Both methods yield the same result.
+
+ Note that a UMEM can be shared between sockets on the same queue id
+ and device, as well as between queues on the same device and between
+-devices at the same time. It is also possible to redirect to any
+-socket as long as it is bound to the same umem with XDP_SHARED_UMEM.
++devices at the same time.
+
+ XDP_USE_NEED_WAKEUP bind flag
+ -----------------------------
+@@ -823,10 +822,6 @@ A: The short answer is no, that is not supported at the moment. The
+ switch, or other distribution mechanism, in your NIC to direct
+ traffic to the correct queue id and socket.
+
+- Note that if you are using the XDP_SHARED_UMEM option, it is
+- possible to switch traffic between any socket bound to the same
+- umem.
+-
+ Q: My packets are sometimes corrupted. What is wrong?
+
+ A: Care has to be taken not to feed the same buffer in the UMEM into
+--
+2.45.2
+
--- /dev/null
+From 7fcf26b315bbb728036da0862de6b335da83dff2 Mon Sep 17 00:00:00 2001
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+Date: Tue, 4 Jun 2024 14:29:25 +0200
+Subject: Revert "xsk: Support redirect to any socket bound to the same umem"
+
+From: Magnus Karlsson <magnus.karlsson@intel.com>
+
+commit 7fcf26b315bbb728036da0862de6b335da83dff2 upstream.
+
+This reverts commit 2863d665ea41282379f108e4da6c8a2366ba66db.
+
+This patch introduced a potential kernel crash when multiple napi instances
+redirect to the same AF_XDP socket. By removing the queue_index check, it is
+possible for multiple napi instances to access the Rx ring at the same time,
+which will result in a corrupted ring state which can lead to a crash when
+flushing the rings in __xsk_flush(). This can happen when the linked list of
+sockets to flush gets corrupted by concurrent accesses. A quick and small fix
+is not possible, so let us revert this for now.
+
+Reported-by: Yuval El-Hanany <YuvalE@radware.com>
+Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Link: https://lore.kernel.org/xdp-newbies/8100DBDC-0B7C-49DB-9995-6027F6E63147@radware.com
+Link: https://lore.kernel.org/bpf/20240604122927.29080-2-magnus.karlsson@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/xdp/xsk.c | 5 +----
+ 1 file changed, 1 insertion(+), 4 deletions(-)
+
+diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
+index 727aa20be4bd..7d1c0986f9bb 100644
+--- a/net/xdp/xsk.c
++++ b/net/xdp/xsk.c
+@@ -313,13 +313,10 @@ static bool xsk_is_bound(struct xdp_sock *xs)
+
+ static int xsk_rcv_check(struct xdp_sock *xs, struct xdp_buff *xdp, u32 len)
+ {
+- struct net_device *dev = xdp->rxq->dev;
+- u32 qid = xdp->rxq->queue_index;
+-
+ if (!xsk_is_bound(xs))
+ return -ENXIO;
+
+- if (!dev->_rx[qid].pool || xs->umem != dev->_rx[qid].pool->umem)
++ if (xs->dev != xdp->rxq->dev || xs->queue_id != xdp->rxq->queue_index)
+ return -EINVAL;
+
+ if (len > xsk_pool_get_rx_frame_size(xs->pool) && !xs->sg) {
+--
+2.45.2
+
--- /dev/null
+From 01b05fc0e5f3aec443a9a8ffa0022cbca2fd3608 Mon Sep 17 00:00:00 2001
+From: John Kacur <jkacur@redhat.com>
+Date: Fri, 10 May 2024 15:03:18 -0400
+Subject: rtla/timerlat: Fix histogram report when a cpu count is 0
+
+From: John Kacur <jkacur@redhat.com>
+
+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 <bristot@kernel.org>
+Signed-off-by: John Kacur <jkacur@redhat.com>
+Signed-off-by: Daniel Bristot de Oliveira <bristot@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -324,17 +324,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");
+
+@@ -384,17 +396,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);
--- /dev/null
+From d09c05aa35909adb7d29f92f0cd79fdcd1338ef0 Mon Sep 17 00:00:00 2001
+From: "Martin K. Petersen" <martin.petersen@oracle.com>
+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 <martin.petersen@oracle.com>
+
+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 <pschneider1968@googlemail.com>
+Closes: https://lore.kernel.org/all/eec6ebbf-061b-4a7b-96dc-ea748aa4d035@googlemail.com/
+Tested-by: Peter Schneider <pschneider1968@googlemail.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From d4202e66a4b1fe6968f17f9f09bbc30d08f028a1 Mon Sep 17 00:00:00 2001
+From: Dev Jain <dev.jain@arm.com>
+Date: Tue, 21 May 2024 13:13:56 +0530
+Subject: selftests/mm: compaction_test: fix bogus test success on Aarch64
+
+From: Dev Jain <dev.jain@arm.com>
+
+commit d4202e66a4b1fe6968f17f9f09bbc30d08f028a1 upstream.
+
+Patch series "Fixes for compaction_test", v2.
+
+The compaction_test memory selftest introduces fragmentation in memory
+and then tries to allocate as many hugepages as possible. This series
+addresses some problems.
+
+On Aarch64, if nr_hugepages == 0, then the test trivially succeeds since
+compaction_index becomes 0, which is less than 3, due to no division by
+zero exception being raised. We fix that by checking for division by
+zero.
+
+Secondly, correctly set the number of hugepages to zero before trying
+to set a large number of them.
+
+Now, consider a situation in which, at the start of the test, a non-zero
+number of hugepages have been already set (while running the entire
+selftests/mm suite, or manually by the admin). The test operates on 80%
+of memory to avoid OOM-killer invocation, and because some memory is
+already blocked by hugepages, it would increase the chance of OOM-killing.
+Also, since mem_free used in check_compaction() is the value before we
+set nr_hugepages to zero, the chance that the compaction_index will
+be small is very high if the preset nr_hugepages was high, leading to a
+bogus test success.
+
+
+This patch (of 3):
+
+Currently, if at runtime we are not able to allocate a huge page, the test
+will trivially pass on Aarch64 due to no exception being raised on
+division by zero while computing compaction_index. Fix that by checking
+for nr_hugepages == 0. Anyways, in general, avoid a division by zero by
+exiting the program beforehand. While at it, fix a typo, and handle the
+case where the number of hugepages may overflow an integer.
+
+Link: https://lkml.kernel.org/r/20240521074358.675031-1-dev.jain@arm.com
+Link: https://lkml.kernel.org/r/20240521074358.675031-2-dev.jain@arm.com
+Fixes: bd67d5c15cc1 ("Test compaction of mlocked memory")
+Signed-off-by: Dev Jain <dev.jain@arm.com>
+Cc: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: Sri Jayaramappa <sjayaram@akamai.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/mm/compaction_test.c | 20 +++++++++++++-------
+ 1 file changed, 13 insertions(+), 7 deletions(-)
+
+--- a/tools/testing/selftests/mm/compaction_test.c
++++ b/tools/testing/selftests/mm/compaction_test.c
+@@ -82,12 +82,13 @@ int prereq(void)
+ return -1;
+ }
+
+-int check_compaction(unsigned long mem_free, unsigned int hugepage_size)
++int check_compaction(unsigned long mem_free, unsigned long hugepage_size)
+ {
++ unsigned long nr_hugepages_ul;
+ int fd, ret = -1;
+ int compaction_index = 0;
+- char initial_nr_hugepages[10] = {0};
+- char nr_hugepages[10] = {0};
++ char initial_nr_hugepages[20] = {0};
++ char nr_hugepages[20] = {0};
+
+ /* We want to test with 80% of available memory. Else, OOM killer comes
+ in to play */
+@@ -136,7 +137,12 @@ int check_compaction(unsigned long mem_f
+
+ /* We should have been able to request at least 1/3 rd of the memory in
+ huge pages */
+- compaction_index = mem_free/(atoi(nr_hugepages) * hugepage_size);
++ nr_hugepages_ul = strtoul(nr_hugepages, NULL, 10);
++ if (!nr_hugepages_ul) {
++ ksft_print_msg("ERROR: No memory is available as huge pages\n");
++ goto close_fd;
++ }
++ compaction_index = mem_free/(nr_hugepages_ul * hugepage_size);
+
+ lseek(fd, 0, SEEK_SET);
+
+@@ -147,11 +153,11 @@ int check_compaction(unsigned long mem_f
+ goto close_fd;
+ }
+
+- ksft_print_msg("Number of huge pages allocated = %d\n",
+- atoi(nr_hugepages));
++ ksft_print_msg("Number of huge pages allocated = %lu\n",
++ nr_hugepages_ul);
+
+ if (compaction_index > 3) {
+- ksft_print_msg("ERROR: Less that 1/%d of memory is available\n"
++ ksft_print_msg("ERROR: Less than 1/%d of memory is available\n"
+ "as huge pages\n", compaction_index);
+ goto close_fd;
+ }
--- /dev/null
+From 9ad665ef55eaad1ead1406a58a34f615a7c18b5e Mon Sep 17 00:00:00 2001
+From: Dev Jain <dev.jain@arm.com>
+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 <dev.jain@arm.com>
+
+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 <dev.jain@arm.com>
+Cc: <stable@vger.kernel.org>
+Cc: Anshuman Khandual <anshuman.khandual@arm.com>
+Cc: Shuah Khan <shuah@kernel.org>
+Cc: Sri Jayaramappa <sjayaram@akamai.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -107,6 +107,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)) {
+ ksft_print_msg("Failed to write 0 to /proc/sys/vm/nr_hugepages: %s\n",
--- /dev/null
+From 1901472fa880e5706f90926cd85a268d2d16bf84 Mon Sep 17 00:00:00 2001
+From: Michael Ellerman <mpe@ellerman.id.au>
+Date: Tue, 21 May 2024 13:02:19 +1000
+Subject: selftests/mm: fix build warnings on ppc64
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+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 <mpe@ellerman.id.au>
+Cc: Shuah Khan <skhan@linuxfoundation.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <fcntl.h>
+ #include <errno.h>
+ #include <stdio.h>
+--- 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 <stdio.h>
+ #include <errno.h>
+ #include <unistd.h>
--- /dev/null
+From 79322174bcc780b99795cb89d237b26006a8b94b Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Wed, 5 Jun 2024 11:21:17 +0200
+Subject: selftests: net: lib: avoid error removing empty netns name
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit 79322174bcc780b99795cb89d237b26006a8b94b upstream.
+
+If there is an error to create the first netns with 'setup_ns()',
+'cleanup_ns()' will be called with an empty string as first parameter.
+
+The consequences is that 'cleanup_ns()' will try to delete an invalid
+netns, and wait 20 seconds if the netns list is empty.
+
+Instead of just checking if the name is not empty, convert the string
+separated by spaces to an array. Manipulating the array is cleaner, and
+calling 'cleanup_ns()' with an empty array will be a no-op.
+
+Fixes: 25ae948b4478 ("selftests/net: add lib.sh")
+Cc: stable@vger.kernel.org
+Acked-by: Geliang Tang <geliang@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Reviewed-by: Petr Machata <petrm@nvidia.com>
+Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
+Link: https://lore.kernel.org/r/20240605-upstream-net-20240605-selftests-net-lib-fixes-v1-2-b3afadd368c9@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/lib.sh | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/tools/testing/selftests/net/lib.sh
++++ b/tools/testing/selftests/net/lib.sh
+@@ -10,7 +10,7 @@ BUSYWAIT_TIMEOUT=$((WAIT_TIMEOUT * 1000)
+ # Kselftest framework requirement - SKIP code is 4.
+ ksft_skip=4
+ # namespace list created by setup_ns
+-NS_LIST=""
++NS_LIST=()
+
+ ##############################################################################
+ # Helpers
+@@ -133,6 +133,7 @@ cleanup_ns()
+ fi
+
+ for ns in "$@"; do
++ [ -z "${ns}" ] && continue
+ ip netns delete "${ns}" &> /dev/null
+ if ! busywait $BUSYWAIT_TIMEOUT ip netns list \| grep -vq "^$ns$" &> /dev/null; then
+ echo "Warn: Failed to remove namespace $ns"
+@@ -146,7 +147,7 @@ cleanup_ns()
+
+ cleanup_all_ns()
+ {
+- cleanup_ns $NS_LIST
++ cleanup_ns "${NS_LIST[@]}"
+ }
+
+ # setup netns with given names as prefix. e.g
+@@ -155,7 +156,7 @@ setup_ns()
+ {
+ local ns=""
+ local ns_name=""
+- local ns_list=""
++ local ns_list=()
+ local ns_exist=
+ for ns_name in "$@"; do
+ # Some test may setup/remove same netns multi times
+@@ -171,13 +172,13 @@ setup_ns()
+
+ if ! ip netns add "$ns"; then
+ echo "Failed to create namespace $ns_name"
+- cleanup_ns "$ns_list"
++ cleanup_ns "${ns_list[@]}"
+ return $ksft_skip
+ fi
+ ip -n "$ns" link set lo up
+- ! $ns_exist && ns_list="$ns_list $ns"
++ ! $ns_exist && ns_list+=("$ns")
+ done
+- NS_LIST="$NS_LIST $ns_list"
++ NS_LIST+=("${ns_list[@]}")
+ }
+
+ tc_rule_stats_get()
--- /dev/null
+From 41b02ea4c0adfcc6761fbfed42c3ce6b6412d881 Mon Sep 17 00:00:00 2001
+From: "Matthieu Baerts (NGI0)" <matttbe@kernel.org>
+Date: Wed, 5 Jun 2024 11:21:16 +0200
+Subject: selftests: net: lib: support errexit with busywait
+
+From: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+
+commit 41b02ea4c0adfcc6761fbfed42c3ce6b6412d881 upstream.
+
+If errexit is enabled ('set -e'), loopy_wait -- or busywait and others
+using it -- will stop after the first failure.
+
+Note that if the returned status of loopy_wait is checked, and even if
+errexit is enabled, Bash will not stop at the first error.
+
+Fixes: 25ae948b4478 ("selftests/net: add lib.sh")
+Cc: stable@vger.kernel.org
+Acked-by: Geliang Tang <geliang@kernel.org>
+Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
+Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
+Link: https://lore.kernel.org/r/20240605-upstream-net-20240605-selftests-net-lib-fixes-v1-1-b3afadd368c9@kernel.org
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ tools/testing/selftests/net/lib.sh | 4 +---
+ 1 file changed, 1 insertion(+), 3 deletions(-)
+
+--- a/tools/testing/selftests/net/lib.sh
++++ b/tools/testing/selftests/net/lib.sh
+@@ -63,9 +63,7 @@ loopy_wait()
+ while true
+ do
+ local out
+- out=$("$@")
+- local ret=$?
+- if ((!ret)); then
++ if out=$("$@"); then
+ echo -n "$out"
+ return 0
+ fi
filemap-add-helper-mapping_max_folio_size.patch
iomap-fault-in-smaller-chunks-for-non-large-folio-mappings.patch
acpi-apei-einj-fix-einj_dev-release-leak.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
+net-tcp-don-t-consider-tcp_close-in-tcp_ao_established.patch
+selftests-net-lib-support-errexit-with-busywait.patch
+selftests-net-lib-avoid-error-removing-empty-netns-name.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-hugetlb-do-not-call-vma_add_reservation-upon-enomem.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-memory-failure-fix-handling-of-dissolved-but-not-taken-off-from-buddy-pages.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
+selftests-mm-compaction_test-fix-bogus-test-success-on-aarch64.patch
+watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch
+bonding-fix-oops-during-rmmod.patch
+irqchip-riscv-intc-prevent-memory-leak-when-riscv_intc_init_common-fails.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
+revert-xsk-support-redirect-to-any-socket-bound-to-the-same-umem.patch
+revert-xsk-document-ability-to-redirect-to-any-socket-bound-to-the-same-umem.patch
+revert-perf-record-reduce-memory-for-recording-perf_record_lost_samples-event.patch
--- /dev/null
+From 98937707fea8375e8acea0aaa0b68a956dd52719 Mon Sep 17 00:00:00 2001
+From: Sam Ravnborg <sam@ravnborg.org>
+Date: Sat, 30 Mar 2024 10:57:45 +0100
+Subject: sparc64: Fix number of online CPUs
+
+From: Sam Ravnborg <sam@ravnborg.org>
+
+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 <atish.patra@oracle.com>
+ 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 <sam@ravnborg.org>
+Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set")
+Reported-by: Nick Bowler <nbowler@draconx.ca>
+Tested-by: Nick Bowler <nbowler@draconx.ca>
+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 <andreas@gaisler.com>
+Cc: David S. Miller <davem@davemloft.net>
+Cc: Atish Patra <atish.patra@oracle.com>
+Cc: Bob Picco <bob.picco@oracle.com>
+Cc: Vijay Kumar <vijay.ac.kumar@oracle.com>
+Cc: David S. Miller <davem@davemloft.net>
+Reviewed-by: Andreas Larsson <andreas@gaisler.com>
+Acked-by: Arnd Bergmann <arnd@arndb.de>
+Link: https://lore.kernel.org/r/20240330-sparc64-warnings-v1-9-37201023ee2f@ravnborg.org
+Signed-off-by: Andreas Larsson <andreas@gaisler.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -671,7 +671,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
+@@ -1216,20 +1216,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;
--- /dev/null
+From 0ea00e249ca992adee54dc71a526ee70ef109e40 Mon Sep 17 00:00:00 2001
+From: Jan Beulich <jbeulich@suse.com>
+Date: Wed, 29 May 2024 15:23:25 +0300
+Subject: tpm_tis: Do *not* flush uninitialized work
+
+From: Jan Beulich <jbeulich@suse.com>
+
+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 <jbeulich@suse.com>
+Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/tpm/tpm_tis_core.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- 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 *chi
+ 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);
+
--- /dev/null
+From cae58516534e110f4a8558d48aa4435e15519121 Mon Sep 17 00:00:00 2001
+From: Judith Mendez <jm@ti.com>
+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 <jm@ti.com>
+
+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 <jm@ti.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Link: https://lore.kernel.org/r/20240417205700.3947408-1-jm@ti.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
--- /dev/null
+From 21ae74e1bf18331ae5e279bd96304b3630828009 Mon Sep 17 00:00:00 2001
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+Date: Fri, 17 May 2024 10:00:28 +0300
+Subject: wifi: ath10k: fix QCOM_RPROC_COMMON dependency
+
+From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
+
+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 <dmitry.baryshkov@linaro.org>
+Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
+Link: https://msgid.link/20240511-ath10k-snoc-dep-v1-1-9666e3af5c27@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
projects / thirdparty / kernel / stable-queue.git / commitdiff
