6.18.10-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 130/175 i40e: drop udp_tunnel_get_rx_info() call from i40e_open()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohammad Heib <[email protected]>
[ Upstream commit 40857194956dcaf3d2b66d6bd113d844c93bef54 ]
The i40e driver calls udp_tunnel_get_rx_info() during i40e_open(). This is redundant because UDP tunnel RX offload state is preserved across device down/up cycles. The udp_tunnel core handles synchronization automatically when required.
Furthermore, recent changes in the udp_tunnel infrastructure require querying RX info while holding the udp_tunnel lock. Calling it directly from the ndo_open path violates this requirement, triggering the following lockdep warning:
Call Trace: <TASK> ? __udp_tunnel_nic_assert_locked+0x39/0x40 [udp_tunnel] i40e_open+0x135/0x14f [i40e] __dev_open+0x121/0x2e0 __dev_change_flags+0x227/0x270 dev_change_flags+0x3d/0xb0 devinet_ioctl+0x56f/0x860 sock_do_ioctl+0x7b/0x130 __x64_sys_ioctl+0x91/0xd0 do_syscall_64+0x90/0x170 ... </TASK>
Remove the redundant and unsafe call to udp_tunnel_get_rx_info() from i40e_open() resolve the locking violation.
--- drivers/net/ethernet/intel/i40e/i40e_main.c | 1 - 1 file changed, 1 deletion(-)
drivers/net/ethernet/intel/i40e/i40e_main.c +0 -1
@@ -9030,7 +9030,6 @@ int i40e_open(struct net_device *netdev)TCP_FLAG_FIN | TCP_FLAG_CWR) >> 16);wr32 (&pf->hw,I40E_GLLAN_TSOMSK_L ,be32_to_cpu (TCP_FLAG_CWR ) >>16 ); -udp_tunnel_get_rx_info (netdev);return 0 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 131/175 net: sfp: Fix quirk for Ubiquiti U-Fiber Instant SFP module
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marek Behún <[email protected]>
[ Upstream commit adcbadfd8e05d3558c9cfaa783f17c645181165f ]
Commit fd580c9830316eda ("net: sfp: augment SFP parsing with phy_interface_t bitmap") did not add augumentation for the interface bitmap in the quirk for Ubiquiti U-Fiber Instant.
The subsequent commit f81fa96d8a6c7a77 ("net: phylink: use phy_interface_t bitmaps for optical modules") then changed phylink code for selection of SFP interface: instead of using link mode bitmap, the interface bitmap is used, and the fastest interface mode supported by both SFP module and MAC is chosen.
Since the interface bitmap contains also modes faster than 1000base-x, this caused a regression wherein this module stopped working out-of-the-box.
Fix this.
--- drivers/net/phy/sfp.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/phy/sfp.c +2 -0
@@ -479,6 +479,8 @@ static void sfp_quirk_ubnt_uf_instant(const struct sfp_eeprom_id *id,linkmode_zero (caps->link_modes);linkmode_set_bit (ETHTOOL_LINK_MODE_1000baseX_Full_BIT, caps->link_modes); +phy_interface_zero (caps->interfaces); +__set_bit (PHY_INTERFACE_MODE_1000BASEX , caps->interfaces); }#define SFP_QUIRK (_v, _p, _s, _f) \
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 132/175 macvlan: fix error recovery in macvlan_common_newlink()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit f8db6475a83649689c087a8f52486fcc53e627e9 ]
valis provided a nice repro to crash the kernel:
ip link add p1 type veth peer p2
ip link set address 00:00:00:00:00:20 dev p1
ip link set up dev p1
ip link set up dev p2
ip link add mv0 link p2 type macvlan mode source
ip link add invalid% link p2 type macvlan mode source macaddr add 00:00:00:00:00:20
ping -c1 -I p1 1.2.3.4
He also gave a very detailed analysis:
<quote valis>
The issue is triggered when a new macvlan link is created with MACVLAN_MODE_SOURCE mode and MACVLAN_MACADDR_ADD (or MACVLAN_MACADDR_SET) parameter, lower device already has a macvlan port and register_netdevice() called from macvlan_common_newlink() fails (e.g. because of the invalid link name).
In this case macvlan_hash_add_source is called from macvlan_change_sources() / macvlan_common_newlink():
This adds a reference to vlan to the port's vlan_source_hash using macvlan_source_entry.
vlan is a pointer to the priv data of the link that is being created.
When register_netdevice() fails, the error is returned from macvlan_newlink() to rtnl_newlink_create():
if (ops->newlink)
err = ops->newlink(dev, ¶ms, extack);
else
err = register_netdevice(dev);
if (err < 0) {
free_netdev(dev);
goto out;
}and free_netdev() is called, causing a kvfree() on the struct net_device that is still referenced in the source entry attached to the lower device's macvlan port.
Now all packets sent on the macvlan port with a matching source mac address will trigger a use-after-free in macvlan_forward_source().
</quote valis>
With all that, my fix is to make sure we call macvlan_flush_sources() regardless of @create value whenever "goto destroy_macvlan_port;" path is taken.
Many thanks to valis for following up on this issue.
--- drivers/net/macvlan.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/macvlan.c +3 -2
@@ -1567,9 +1567,10 @@ int macvlan_common_newlink(struct net_device *dev,/* the macvlan port may be freed by macvlan_uninit when fail to register. * so we destroy the macvlan port only when it's valid. */ -if (create &&macvlan_port_get_rtnl (lowerdev)) { +if (macvlan_port_get_rtnl (lowerdev)) {macvlan_flush_sources (port, vlan); -macvlan_port_destroy (port->dev); +if (create) +macvlan_port_destroy (port->dev); }return err; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 133/175 net: usb: r8152: fix resume reset deadlock
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Senozhatsky <[email protected]>
[ Upstream commit 6d06bc83a5ae8777a5f7a81c32dd75b8d9b2fe04 ]
rtl8152 can trigger device reset during reset which potentially can result in a deadlock:
**** DPM device timeout after 10 seconds; 15 seconds until panic ****
Call Trace: <TASK> schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470 __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110
The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.
Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutex_lock() deadlock.
--- drivers/net/usb/r8152.c | 29 +++++++++++++++-------------- 1 file changed, 15 insertions(+), 14 deletions(-)
drivers/net/usb/r8152.c +15 -14
@@ -8535,19 +8535,6 @@ static int rtl8152_system_resume(struct r8152 *tp)usb_submit_urb (tp->intr_urb,GFP_NOIO ); } -/* If the device is RTL8152_INACCESSIBLE here then we should do a -* reset. This is important because the usb_lock_device_for_reset() -* that happens as a result of usb_queue_reset_device() will silently -* fail if the device was suspended or if too much time passed. -* -* NOTE: The device is locked here so we can directly do the reset. -* We don't need usb_lock_device_for_reset() because that's just a -* wrapper over device_lock() and device_resume() (which calls us) -* does that for us. -*/ -if (test_bit (RTL8152_INACCESSIBLE , &tp->flags)) -usb_reset_device (tp->udev); -return 0 ; }
@@ -8658,19 +8645,33 @@ static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)static int rtl8152_resume (struct usb_interface *intf) {struct r8152 *tp =usb_get_intfdata (intf); +bool runtime_resume =test_bit (SELECTIVE_SUSPEND , &tp->flags);int ret;mutex_lock (&tp->control);rtl_reset_ocp_base (tp); -if (test_bit (SELECTIVE_SUSPEND , &tp->flags)) +if (runtime_resume) ret =rtl8152_runtime_resume (tp);else ret =rtl8152_system_resume (tp);mutex_unlock (&tp->control); +/* If the device is RTL8152_INACCESSIBLE here then we should do a +* reset. This is important because the usb_lock_device_for_reset() +* that happens as a result of usb_queue_reset_device() will silently +* fail if the device was suspended or if too much time passed. +* +* NOTE: The device is locked here so we can directly do the reset. +* We don't need usb_lock_device_for_reset() because that's just a +* wrapper over device_lock() and device_resume() (which calls us) +* does that for us. +*/ +if (!runtime_resume &&test_bit (RTL8152_INACCESSIBLE , &tp->flags)) +usb_reset_device (tp->udev); +return ret; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 134/175 hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit 615901b57b7ef8eb655f71358f7e956e42bcd16b ]
The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal.
Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective.
The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them.
In addition, notice that hwmon_device_register_with_info() may fail in which case resource->hwmon_dev will become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case to acpi_power_meter_notify() and acpi_power_meter_remove().
--- drivers/hwmon/acpi_power_meter.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
drivers/hwmon/acpi_power_meter.c +14 -3
@@ -47,6 +47,8 @@static int cap_in_hardware;static bool force_cap_on; +static DEFINE_MUTEX (acpi_notify_lock); +static int can_cap_in_hardware (void ) {return force_cap_on || cap_in_hardware;
@@ -823,18 +825,26 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) resource =acpi_driver_data (device); +guard (mutex)(&acpi_notify_lock); +switch (event) {case METER_NOTIFY_CONFIG : +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev); +mutex_lock (&resource->lock); +free_capabilities (resource);remove_domain_devices (resource); -hwmon_device_unregister (resource->hwmon_dev); res =read_capabilities (resource);if (res)dev_err_once (&device->dev,"read capabilities failed.\n" ); res =read_domain_devices (resource);if (res && res != -ENODEV )dev_err_once (&device->dev,"read domain devices failed.\n" ); + +mutex_unlock (&resource->lock); + resource->hwmon_dev = hwmon_device_register_with_info(&device->dev, ACPI_POWER_METER_NAME,
@@ -843,7 +853,7 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) power_extra_groups);if (IS_ERR (resource->hwmon_dev))dev_err_once (&device->dev,"register hwmon device failed.\n" ); -mutex_unlock (&resource->lock); +break ;case METER_NOTIFY_TRIP :sysfs_notify (&device->dev.kobj,NULL ,POWER_AVERAGE_NAME );
@@ -953,7 +963,8 @@ static void acpi_power_meter_remove(struct acpi_device *device)return ; resource =acpi_driver_data (device); -hwmon_device_unregister (resource->hwmon_dev); +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev);remove_domain_devices (resource);free_capabilities (resource);
Signature · 1 line
2.51.0
Re: [PATCH 6.18 134/175] hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()
Quoted 111 lines
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit
615901b57b7ef8eb655f71358f7e956e42bcd16b]The
acpi_power_meterdriver's .notify() callback function,acpi_power_meter_notify(), callshwmon_device_unregister()under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal.Address this by moving the hwmon device removal in
acpi_power_meter_notify()outside the lock in question, but notice that doing it alone is not sufficient because two concurrentMETER_NOTIFY_CONFIGnotifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement inacpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective.The new lock also allows the
hwmon_device_register_with_info()inacpi_power_meter_notify()to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages fromacpi_power_meter_notify()is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them.In addition, notice that
hwmon_device_register_with_info()may fail in which caseresource->hwmon_devwill become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case toacpi_power_meter_notify()andacpi_power_meter_remove().Fixes 16746ce8adfe ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register")Closes https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ open hereReported-by Jaroslav Pulchart <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>Signed-off-by Guenter Roeck <[email protected]>Signed-off-by Sasha Levin <[email protected]>--- drivers/hwmon/acpi_power_meter.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)drivers/hwmon/acpi_power_meter.c +14
-4@@ -47,6 +47,8 @@static int cap_in_hardware;static bool force_cap_on; +static DEFINE_MUTEX (acpi_notify_lock); +static int can_cap_in_hardware (void ) {return force_cap_on || cap_in_hardware;@@ -823,18 +825,26 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) resource =acpi_driver_data (device); +guard (mutex)(&acpi_notify_lock); +switch (event) {case METER_NOTIFY_CONFIG : +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev); +mutex_lock (&resource->lock); +free_capabilities (resource);remove_domain_devices (resource); -hwmon_device_unregister (resource->hwmon_dev); res =read_capabilities (resource);if (res)dev_err_once (&device->dev,"read capabilities failed.\n" ); res =read_domain_devices (resource);if (res && res != -ENODEV )dev_err_once (&device->dev,"read domain devices failed.\n" ); + +mutex_unlock (&resource->lock); + resource->hwmon_dev = hwmon_device_register_with_info(&device->dev, ACPI_POWER_METER_NAME,@@ -843,7 +853,7 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) power_extra_groups);if (IS_ERR (resource->hwmon_dev))dev_err_once (&device->dev,"register hwmon device failed.\n" ); -mutex_unlock (&resource->lock); +break ;case METER_NOTIFY_TRIP :sysfs_notify (&device->dev.kobj,NULL ,POWER_AVERAGE_NAME );@@ -953,7 +963,8 @@ static void acpi_power_meter_remove(struct acpi_device *device)return ; resource =acpi_driver_data (device); -hwmon_device_unregister (resource->hwmon_dev); +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev);remove_domain_devices (resource);free_capabilities (resource); --
Quoted 4 lines
2.51.0
Hello, I tested this patch, but unfortunately it does not resolve the reported issue on our systems the deadlock is still reproducible with the same iDRAC reset reproducer.
Jaroslav Pulchart
Greg Kroah-Hartman
maintainerRe: [PATCH 6.18 134/175] hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()
Quoted 108 lines · Jaroslav Pulchart
Quoted 108 lines
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit
615901b57b7ef8eb655f71358f7e956e42bcd16b]The
acpi_power_meterdriver's .notify() callback function,acpi_power_meter_notify(), callshwmon_device_unregister()under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal.Address this by moving the hwmon device removal in
acpi_power_meter_notify()outside the lock in question, but notice that doing it alone is not sufficient because two concurrentMETER_NOTIFY_CONFIGnotifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement inacpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective.The new lock also allows the
hwmon_device_register_with_info()inacpi_power_meter_notify()to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages fromacpi_power_meter_notify()is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them.In addition, notice that
hwmon_device_register_with_info()may fail in which caseresource->hwmon_devwill become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case toacpi_power_meter_notify()andacpi_power_meter_remove().Fixes 16746ce8adfe ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register")Closes https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ open hereReported-by Jaroslav Pulchart <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>Signed-off-by Guenter Roeck <[email protected]>Signed-off-by Sasha Levin <[email protected]>--- drivers/hwmon/acpi_power_meter.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)drivers/hwmon/acpi_power_meter.c +14
-3@@ -47,6 +47,8 @@static int cap_in_hardware;static bool force_cap_on; +static DEFINE_MUTEX (acpi_notify_lock); +static int can_cap_in_hardware (void ) {return force_cap_on || cap_in_hardware;@@ -823,18 +825,26 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) resource =acpi_driver_data (device); +guard (mutex)(&acpi_notify_lock); +switch (event) {case METER_NOTIFY_CONFIG : +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev); +mutex_lock (&resource->lock); +free_capabilities (resource);remove_domain_devices (resource); -hwmon_device_unregister (resource->hwmon_dev); res =read_capabilities (resource);if (res)dev_err_once (&device->dev,"read capabilities failed.\n" ); res =read_domain_devices (resource);if (res && res != -ENODEV )dev_err_once (&device->dev,"read domain devices failed.\n" ); + +mutex_unlock (&resource->lock); + resource->hwmon_dev = hwmon_device_register_with_info(&device->dev, ACPI_POWER_METER_NAME,@@ -843,7 +853,7 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) power_extra_groups);if (IS_ERR (resource->hwmon_dev))dev_err_once (&device->dev,"register hwmon device failed.\n" ); -mutex_unlock (&resource->lock); +break ;case METER_NOTIFY_TRIP :sysfs_notify (&device->dev.kobj,NULL ,POWER_AVERAGE_NAME );@@ -953,7 +963,8 @@ static void acpi_power_meter_remove(struct acpi_device *device)return ; resource =acpi_driver_data (device); -hwmon_device_unregister (resource->hwmon_dev); +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev);
Quoted 11 lines
Quoted 7 lines
drivers/hwmon/acpi_power_meter.c +0
-1remove_domain_devices (resource);free_capabilities (resource); --2.51.0
Hello, I tested this patch, but unfortunately it does not resolve the reported issue on our systems the deadlock is still reproducible with the same iDRAC reset reproducer.
Is 6.19 also a problem here, or does it work properly on that release?
thanks,
greg k-h
Re: [PATCH 6.18 134/175] hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()
Quoted 118 lines · Greg Kroah-Hartman
Quoted 107 lines · Jaroslav Pulchart
Quoted 107 lines
6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rafael J. Wysocki <[email protected]>
[ Upstream commit
615901b57b7ef8eb655f71358f7e956e42bcd16b]The
acpi_power_meterdriver's .notify() callback function,acpi_power_meter_notify(), callshwmon_device_unregister()under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal.Address this by moving the hwmon device removal in
acpi_power_meter_notify()outside the lock in question, but notice that doing it alone is not sufficient because two concurrentMETER_NOTIFY_CONFIGnotifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement inacpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective.The new lock also allows the
hwmon_device_register_with_info()inacpi_power_meter_notify()to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages fromacpi_power_meter_notify()is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them.In addition, notice that
hwmon_device_register_with_info()may fail in which caseresource->hwmon_devwill become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case toacpi_power_meter_notify()andacpi_power_meter_remove().Fixes 16746ce8adfe ("hwmon: (acpi_power_meter) Replace the deprecated hwmon_device_register")Closes https://lore.kernel.org/linux-hwmon/CAK8fFZ58fidGUCHi5WFX0uoTPzveUUDzT=k=AAm4yWo3bAuCFg@mail.gmail.com/ open hereReported-by Jaroslav Pulchart <[email protected]>Signed-off-by Rafael J. Wysocki <[email protected]>Signed-off-by Guenter Roeck <[email protected]>Signed-off-by Sasha Levin <[email protected]>--- drivers/hwmon/acpi_power_meter.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)drivers/hwmon/acpi_power_meter.c +14
-3@@ -47,6 +47,8 @@static int cap_in_hardware;static bool force_cap_on; +static DEFINE_MUTEX (acpi_notify_lock); +static int can_cap_in_hardware (void ) {return force_cap_on || cap_in_hardware;@@ -823,18 +825,26 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) resource =acpi_driver_data (device); +guard (mutex)(&acpi_notify_lock); +switch (event) {case METER_NOTIFY_CONFIG : +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev); +mutex_lock (&resource->lock); +free_capabilities (resource);remove_domain_devices (resource); -hwmon_device_unregister (resource->hwmon_dev); res =read_capabilities (resource);if (res)dev_err_once (&device->dev,"read capabilities failed.\n" ); res =read_domain_devices (resource);if (res && res != -ENODEV )dev_err_once (&device->dev,"read domain devices failed.\n" ); + +mutex_unlock (&resource->lock); + resource->hwmon_dev = hwmon_device_register_with_info(&device->dev, ACPI_POWER_METER_NAME,@@ -843,7 +853,7 @@ static void acpi_power_meter_notify(struct acpi_device *device, u32 event) power_extra_groups);if (IS_ERR (resource->hwmon_dev))dev_err_once (&device->dev,"register hwmon device failed.\n" ); -mutex_unlock (&resource->lock); +break ;case METER_NOTIFY_TRIP :sysfs_notify (&device->dev.kobj,NULL ,POWER_AVERAGE_NAME );@@ -953,7 +963,8 @@ static void acpi_power_meter_remove(struct acpi_device *device)return ; resource =acpi_driver_data (device); -hwmon_device_unregister (resource->hwmon_dev); +if (!IS_ERR (resource->hwmon_dev)) +hwmon_device_unregister (resource->hwmon_dev);Quoted 10 lines
Quoted 7 lines
drivers/hwmon/acpi_power_meter.c +0
-1remove_domain_devices (resource);free_capabilities (resource); --2.51.0
Hello, I tested this patch, but unfortunately it does not resolve the reported issue on our systems the deadlock is still reproducible with the same iDRAC reset reproducer.
Quoted 1 line
Is 6.19 also a problem here, or does it work properly on that release?
To be precise, the patch does fix a problem, but it is not sufficient to make the reported observed symptoms go away, so the Closes: tag of it is inaccurate.
An IPMI fix is needed in addition to it to really close the bug report, please see:
Greg Kroah-Hartman
maintainerPATCH 135/175 net: dont touch dev->stats in BPF redirect paths
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit fdf3f6800be36377e045e2448087f12132b88d2f ]
Gal reports that BPF redirect increments dev->stats.tx_errors on failure. This is not correct, most modern drivers completely ignore dev->stats so these drops will be invisible to the user. Core code should use the dedicated core stats which are folded into device stats in dev_get_stats().
Note that we're switching from tx_errors to tx_dropped. Core only has tx_dropped, hence presumably users already expect that counter to increment for "stack" Tx issues.
--- net/core/filter.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
net/core/filter.c +4 -4
@@ -2289,12 +2289,12 @@ static int __bpf_redirect_neigh_v6(struct sk_buff *skb, struct net_device *dev, err =bpf_out_neigh_v6 (net, skb, dev, nh);if (unlikely (net_xmit_eval (err))) -DEV_STATS_INC (dev, tx_errors); +dev_core_stats_tx_dropped_inc (dev);else ret =NET_XMIT_SUCCESS ; goto out_xmit; out_drop: -DEV_STATS_INC (dev, tx_errors); +dev_core_stats_tx_dropped_inc (dev);kfree_skb (skb); out_xmit:return ret;
@@ -2396,12 +2396,12 @@ static int __bpf_redirect_neigh_v4(struct sk_buff *skb, struct net_device *dev, err =bpf_out_neigh_v4 (net, skb, dev, nh);if (unlikely (net_xmit_eval (err))) -DEV_STATS_INC (dev, tx_errors); +dev_core_stats_tx_dropped_inc (dev);else ret =NET_XMIT_SUCCESS ; goto out_xmit; out_drop: -DEV_STATS_INC (dev, tx_errors); +dev_core_stats_tx_dropped_inc (dev);kfree_skb (skb); out_xmit:return ret;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 136/175 io_uring/zcrx: fix page array leak
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Pavel Begunkov <[email protected]>
[ Upstream commit 0ae91d8ab70922fb74c22c20bedcb69459579b1c ]
d9f595b9a65e ("io_uring/zcrx: fix leaking pages on sg init fail") fixed a page leakage but didn't free the page array, release it as well.
--- io_uring/zcrx.c | 1 + 1 file changed, 1 insertion(+)
io_uring/zcrx.c +1 -0
@@ -196,6 +196,7 @@ static int io_import_umem(struct io_zcrx_ifq *ifq, GFP_KERNEL_ACCOUNT);if (ret) {unpin_user_pages (pages, nr_pages); +kvfree (pages);return ret; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 137/175 linkwatch: use __dev_put() in callers to prevent UAF
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiayuan Chen <[email protected]>
[ Upstream commit 83b67cc9be9223183caf91826d9c194d7fb128fa ]
After linkwatch_do_dev() calls __dev_put() to release the linkwatch reference, the device refcount may drop to 1. At this point, netdev_run_todo() can proceed (since linkwatch_sync_dev() sees an empty list and returns without blocking), wait for the refcount to become 1 via netdev_wait_allrefs_any(), and then free the device via kobject_put().
This creates a use-after-free when __linkwatch_run_queue() tries to call netdev_unlock_ops() on the already-freed device.
Note that adding netdev_lock_ops()/netdev_unlock_ops() pair in netdev_run_todo() before kobject_put() would not work, because netdev_lock_ops() is conditional - it only locks when netdev_need_ops_lock() returns true. If the device doesn't require ops_lock, linkwatch won't hold any lock, and netdev_run_todo() acquiring the lock won't provide synchronization.
Fix this by moving __dev_put() from linkwatch_do_dev() to its callers. The device reference logically pairs with de-listing the device, so it's reasonable for the caller that did the de-listing to release it. This allows placing __dev_put() after all device accesses are complete, preventing UAF.
The bug can be reproduced by adding mdelay(2000) after linkwatch_do_dev() in __linkwatch_run_queue(), then running:
ip tuntap add mode tun name tun_test
ip link set tun_test up
ip link set tun_test carrier off
ip link set tun_test carrier on
sleep 0.5
ip tuntap del mode tun name tun_test
KASAN report:
==================================================================
BUG: KASAN: use-after-free in netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] BUG: KASAN: use-after-free in netdev_unlock_ops include/net/netdev_lock.h:47 [inline] BUG: KASAN: use-after-free in __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 Read of size 8 at addr ffff88804de5c008 by task kworker/u32:10/8123 CPU: 0 UID: 0 PID: 8123 Comm: kworker/u32:10 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: events_unbound linkwatch_event Call Trace: <TASK> __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x156/0x4c9 mm/kasan/report.c:482 kasan_report+0xdf/0x1a0 mm/kasan/report.c:595 netdev_need_ops_lock include/net/netdev_lock.h:33 [inline] netdev_unlock_ops include/net/netdev_lock.h:47 [inline] __linkwatch_run_queue+0x865/0x8a0 net/core/link_watch.c:245 linkwatch_event+0x8f/0xc0 net/core/link_watch.c:304 process_one_work+0x9c2/0x1840 kernel/workqueue.c:3257 process_scheduled_works kernel/workqueue.c:3340 [inline] worker_thread+0x5da/0xe40 kernel/workqueue.c:3421 kthread+0x3b3/0x730 kernel/kthread.c:463 ret_from_fork+0x754/0xaf0 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246 </TASK> ==================================================================
--- net/core/link_watch.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-)
net/core/link_watch.c +15 -5
@@ -185,10 +185,6 @@ static void linkwatch_do_dev(struct net_device *dev)netif_state_change (dev); } -/* Note: our callers are responsible for calling netdev_tracker_free(). -* This is the reason we use __dev_put() instead of dev_put(). -*/ -__dev_put (dev); }static void __linkwatch_run_queue (int urgent_only)
@@ -243,6 +239,11 @@ static void __linkwatch_run_queue(int urgent_only)netdev_lock_ops (dev);linkwatch_do_dev (dev);netdev_unlock_ops (dev); +/* Use __dev_put() because netdev_tracker_free() was already +* called above. Must be after netdev_unlock_ops() to prevent +* netdev_run_todo() from freeing the device while still in use. +*/ +__dev_put (dev); do_dev--;spin_lock_irq (&lweventlist_lock); }
@@ -278,8 +279,13 @@ void __linkwatch_sync_dev(struct net_device *dev) {netdev_ops_assert_locked (dev); -if (linkwatch_clean_dev (dev)) +if (linkwatch_clean_dev (dev)) {linkwatch_do_dev (dev); +/* Use __dev_put() because netdev_tracker_free() was already +* called inside linkwatch_clean_dev(). +*/ +__dev_put (dev); + } }void linkwatch_sync_dev (struct net_device *dev)
@@ -288,6 +294,10 @@ void linkwatch_sync_dev(struct net_device *dev)netdev_lock_ops (dev);linkwatch_do_dev (dev);netdev_unlock_ops (dev); +/* Use __dev_put() because netdev_tracker_free() was already +* called inside linkwatch_clean_dev(). +*/ +__dev_put (dev); } }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 138/175 net: rss: fix reporting RXH_XFRM_NO_CHANGE as input_xfrm for contexts
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jakub Kicinski <[email protected]>
[ Upstream commit 1c172febdf065375359b2b95156e476bfee30b60 ]
Initializing input_xfrm to RXH_XFRM_NO_CHANGE in RSS contexts is problematic. I think I did this to make it clear that the context does not have its own settings applied. But unlike ETH_RSS_HASH_NO_CHANGE which is zero, RXH_XFRM_NO_CHANGE is 0xff. We need to be careful when reading the value back, and remember to treat 0xff as 0.
Remove the initialization and switch to storing 0. This lets us also remove the workaround in ethnl_rss_set(). Get side does not need any adjustments and context get no longer reports:
RSS input transformation:
symmetric-xor: on
symmetric-or-xor: on
Unknown bits in RSS input transformation: 0xfcfor NICs which don't support input_xfrm.
Remove the init of hfunc to ETH_RSS_HASH_NO_CHANGE while at it. As already mentioned this is a noop since ETH_RSS_HASH_NO_CHANGE is 0 and struct is zalloc'd. But as this fix exemplifies storing NO_CHANGE as state is fragile.
This issue is implicitly caught by running our selftests because YNL in selftests errors out on unknown bits.
--- net/ethtool/common.c | 3 --- net/ethtool/rss.c | 9 ++------- 2 files changed, 2 insertions(+), 10 deletions(-)
net/ethtool/common.c +0 -3
@@ -854,9 +854,6 @@ ethtool_rxfh_ctx_alloc(const struct ethtool_ops *ops, ctx->key_off = key_off; ctx->priv_size = ops->rxfh_priv_size; - ctx->hfunc =ETH_RSS_HASH_NO_CHANGE ; - ctx->input_xfrm =RXH_XFRM_NO_CHANGE ; -return ctx; }
net/ethtool/rss.c +2 -7
@@ -824,8 +824,8 @@ rss_set_ctx_update(struct ethtool_rxfh_context *ctx, struct nlattr **tb,static int ethnl_rss_set (struct ethnl_req_info *req_info,struct genl_info *info) { -bool indir_reset = false, indir_mod, xfrm_sym = false;struct rss_req_info *request =RSS_REQINFO (req_info); +bool indir_reset = false, indir_mod, xfrm_sym;struct ethtool_rxfh_context *ctx =NULL ;struct net_device *dev = req_info->dev;bool mod = false, fields_mod = false;
@@ -860,12 +860,7 @@ ethnl_rss_set(struct ethnl_req_info *req_info, struct genl_info *info) rxfh.input_xfrm = data.input_xfrm;ethnl_update_u8 (&rxfh.input_xfrm, tb[ETHTOOL_A_RSS_INPUT_XFRM ], &mod); -/* For drivers which don't support input_xfrm it will be set to 0xff -* in the RSS context info. In all other case input_xfrm != 0 means -* symmetric hashing is requested. -*/ -if (!request->rss_context || ops->rxfh_per_ctx_key) - xfrm_sym = rxfh.input_xfrm || data.input_xfrm; + xfrm_sym = rxfh.input_xfrm || data.input_xfrm;if (rxfh.input_xfrm == data.input_xfrm) rxfh.input_xfrm =RXH_XFRM_NO_CHANGE ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 139/175 tipc: use kfree_sensitive() for session key material
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Hodges <[email protected]>
[ Upstream commit 74d9391e8849e70ded5309222d09b0ed0edbd039 ]
The rx->skey field contains a struct tipc_aead_key with GCM-AES encryption keys used for TIPC cluster communication. Using plain kfree() leaves this sensitive key material in freed memory pages where it could potentially be recovered.
Switch to kfree_sensitive() to ensure the key material is zeroed before the memory is freed.
--- net/tipc/crypto.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/tipc/crypto.c +2 -2
@@ -1219,7 +1219,7 @@ void tipc_crypto_key_flush(struct tipc_crypto *c) rx = c; tx =tipc_net (rx->net)->crypto_tx;if (cancel_delayed_work (&rx->work)) { -kfree (rx->skey); +kfree_sensitive (rx->skey); rx->skey =NULL ;atomic_xchg (&rx->key_distr,0 );tipc_node_put (rx->node);
@@ -2394,7 +2394,7 @@ static void tipc_crypto_work_rx(struct work_struct *work)break ;default :synchronize_rcu (); -kfree (rx->skey); +kfree_sensitive (rx->skey); rx->skey =NULL ;break ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 140/175 net: enetc: Remove SI/BDR cacheability AXI settings for ENETC v4
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Claudiu Manoil <[email protected]>
[ Upstream commit a69c17230cab07bd156f894fdc82bd78b43ea72f ]
For ENETC v4 these settings are controlled by the global ENETC message and buffer cache attribute registers (EnBCAR and EnMCAR), from the IERB register block.
The hardcoded cacheability settings were inherited from LS1028A, and should be removed from the ENETC v4 driver as they conflict with the global IERB settings.
--- drivers/net/ethernet/freescale/enetc/enetc.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc.c +7 -4
@@ -2503,10 +2503,13 @@ int enetc_configure_si(struct enetc_ndev_priv *priv)struct enetc_hw *hw = &si->hw;int err; -/* set SI cache attributes */ -enetc_wr (hw,ENETC_SICAR0 , -ENETC_SICAR_RD_COHERENT |ENETC_SICAR_WR_COHERENT ); -enetc_wr (hw,ENETC_SICAR1 ,ENETC_SICAR_MSI ); +if (is_enetc_rev1 (si)) { +/* set SI cache attributes */ +enetc_wr (hw,ENETC_SICAR0 , +ENETC_SICAR_RD_COHERENT |ENETC_SICAR_WR_COHERENT ); +enetc_wr (hw,ENETC_SICAR1 ,ENETC_SICAR_MSI ); + } +/* enable SI */ enetc_wr (hw,ENETC_SIMR ,ENETC_SIMR_EN );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 141/175 net: enetc: Remove CBDR cacheability AXI settings for ENETC v4
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Claudiu Manoil <[email protected]>
[ Upstream commit 9ae13b2e64fcd2ca00a76b7d60fc4641a6b9209d ]
For ENETC v4 these settings are controlled by the global ENETC command cache attribute registers (EnCAR), from the IERB register block.
The hardcoded CDBR cacheability settings were inherited from LS1028A, and should be removed from the ENETC v4 driver as they conflict with the global IERB settings.
--- drivers/net/ethernet/freescale/enetc/enetc_cbdr.c | 4 ---- 1 file changed, 4 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc_cbdr.c +0 -4
@@ -74,10 +74,6 @@ int enetc4_setup_cbdr(struct enetc_si *si)if (!user->ring)return -ENOMEM ; -/* set CBDR cache attributes */ -enetc_wr (hw,ENETC_SICAR2 , -ENETC_SICAR_RD_COHERENT |ENETC_SICAR_WR_COHERENT ); - regs.pir = hw->reg +ENETC_SICBDRPIR ; regs.cir = hw->reg +ENETC_SICBDRCIR ; regs.mr = hw->reg +ENETC_SICBDRMR ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 142/175 net: enetc: Convert 16-bit register writes to 32-bit for ENETC v4
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Claudiu Manoil <[email protected]>
[ Upstream commit 21d0fc95b5920ae8e69a2c0394bef82b8392bcc9 ]
For ENETC v4, which is integrated into more complex SoCs (compared to v1), 16‑bit register writes are blocked in the SoC interconnect on some chips.
To be fair, it is not recommended to access 32‑bit registers of this IP using lower‑width accessors (i.e. 16‑bit), and the only exception to this rule was introduced by me in the initial ENETC v1 driver for the PMAR1 register, which holds the lower 16 bits of the primary MAC address of an SI. Meanwhile, this exception has been replicated for v4 as well.
Since LS1028 (the only SoC with ENETC v1) is not affected by this issue, the current patch fixes the 16‑bit writes to PMAR1 starting with ENETC v4.
--- drivers/net/ethernet/freescale/enetc/enetc4_pf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc4_pf.c +2 -2
@@ -49,10 +49,10 @@ static void enetc4_pf_set_si_primary_mac(struct enetc_hw *hw, int si,if (si !=0 ) {__raw_writel (upper, hw->port +ENETC4_PSIPMAR0 (si)); -__raw_writew (lower, hw->port +ENETC4_PSIPMAR1 (si)); +__raw_writel (lower, hw->port +ENETC4_PSIPMAR1 (si)); }else {__raw_writel (upper, hw->port +ENETC4_PMAR0 ); -__raw_writew (lower, hw->port +ENETC4_PMAR1 ); +__raw_writel (lower, hw->port +ENETC4_PMAR1 ); } }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 143/175 net: enetc: Convert 16-bit register reads to 32-bit for ENETC v4
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Claudiu Manoil <[email protected]>
[ Upstream commit c28d765ec5da160d3a48d0928528084cef97bf19 ]
It is not recommended to access the 32‑bit registers of this hardware IP using lower‑width accessors (i.e. 16‑bit), and the only exception to this rule was introduced in the initial ENETC v1 driver for the PMAR1 register, which holds the lower 16 bits of the primary MAC address of an SI. Meanwhile, this exception has been replicated in the v4 driver code as well.
Since LS1028 (the only SoC with ENETC v1) is not affected by this issue, the current patch converts the 16‑bit reads from PMAR1 starting with ENETC v4.
--- .../net/ethernet/freescale/enetc/enetc4_pf.c | 2 +- drivers/net/ethernet/freescale/enetc/enetc_hw.h | 17 ++++++++++++++--- 2 files changed, 15 insertions(+), 4 deletions(-)
drivers/net/ethernet/freescale/enetc/enetc4_pf.c +1 -1
@@ -63,7 +63,7 @@ static void enetc4_pf_get_si_primary_mac(struct enetc_hw *hw, int si,u16 lower; upper =__raw_readl (hw->port +ENETC4_PSIPMAR0 (si)); - lower =__raw_readw (hw->port +ENETC4_PSIPMAR1 (si)); + lower =__raw_readl (hw->port +ENETC4_PSIPMAR1 (si));put_unaligned_le32 (upper, addr);put_unaligned_le16 (lower, addr +4 );
drivers/net/ethernet/freescale/enetc/enetc_hw.h +14 -3
@@ -707,13 +707,24 @@ struct enetc_cmd_rfse {#define ENETC_RFSE_EN BIT(15)#define ENETC_RFSE_MODE_BD 2 +static inline void enetc_get_primary_mac_addr (struct enetc_hw *hw,u8 *addr) +{ +u32 upper; +u16 lower; + + upper =__raw_readl (hw->reg +ENETC_SIPMAR0 ); + lower =__raw_readl (hw->reg +ENETC_SIPMAR1 ); + +put_unaligned_le32 (upper, addr); +put_unaligned_le16 (lower, addr +4 ); +} +static inline void enetc_load_primary_mac_addr (struct enetc_hw *hw,struct net_device *ndev) { -u8 addr[ETH_ALEN ]__aligned(4) ; +u8 addr[ETH_ALEN ]; - *(u32 *)addr =__raw_readl (hw->reg +ENETC_SIPMAR0 ); - *(u16 *)(addr +4 ) =__raw_readw (hw->reg +ENETC_SIPMAR1 ); +enetc_get_primary_mac_addr (hw, addr);eth_hw_addr_set (ndev, addr); }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 144/175 wifi: iwlwifi: mld: cancel mlo_scan_start_wk
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miri Korenblit <[email protected]>
[ Upstream commit 5ff641011ab7fb63ea101251087745d9826e8ef5 ]
mlo_scan_start_wk is not canceled on disconnection. In fact, it is not canceled anywhere except in the restart cleanup, where we don't really have to.
This can cause an init-after-queue issue: if, for example, the work was queued and then drv_change_interface got executed.
This can also cause use-after-free: if the work is executed after the vif is freed.
--- drivers/net/wireless/intel/iwlwifi/mld/iface.c | 2 -- drivers/net/wireless/intel/iwlwifi/mld/mac80211.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-)
drivers/net/wireless/intel/iwlwifi/mld/iface.c +0 -2
@@ -55,8 +55,6 @@ void iwl_mld_cleanup_vif(void *data, u8 *mac, struct ieee80211_vif *vif)ieee80211_iter_keys (mld->hw, vif, iwl_mld_cleanup_keys_iter,NULL ); -wiphy_delayed_work_cancel (mld->wiphy, &mld_vif->mlo_scan_start_wk); -CLEANUP_STRUCT (mld_vif); }
drivers/net/wireless/intel/iwlwifi/mld/mac80211.c +2 -0
@@ -1755,6 +1755,8 @@ static int iwl_mld_move_sta_state_down(struct iwl_mld *mld,wiphy_work_cancel (mld->wiphy, &mld_vif->emlsr.unblock_tpt_wk);wiphy_delayed_work_cancel (mld->wiphy, &mld_vif->emlsr.check_tpt_wk); +wiphy_delayed_work_cancel (mld->wiphy, + &mld_vif->mlo_scan_start_wk);iwl_mld_reset_cca_40mhz_workaround (mld, vif);iwl_mld_smps_workaround (mld, vif, true);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 145/175 wifi: iwlwifi: mvm: pause TCM on fast resume
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Miri Korenblit <[email protected]>
[ Upstream commit fb7f54aa2a99b07945911152c5d3d4a6eb39f797 ]
Not pausing it means that we can have the TCM work queued into a non-freezable workqueue, which, in resume, is re-activated before the driver's resume is called.
The TCM work might send commands to the FW before we resumed the device, leading to an assert.
--- drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/net/wireless/intel/iwlwifi/mvm/d3.c +5 -1
@@ -1,6 +1,6 @@// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause /* -* Copyright (C) 2012-2014, 2018-2025 Intel Corporation +* Copyright (C) 2012-2014, 2018-2026 Intel Corporation * Copyright (C) 2013-2015 Intel Mobile Communications GmbH * Copyright (C) 2016-2017 Intel Deutschland GmbH */
@@ -3239,6 +3239,8 @@ void iwl_mvm_fast_suspend(struct iwl_mvm *mvm)IWL_DEBUG_WOWLAN (mvm,"Starting fast suspend flow\n" ); +iwl_mvm_pause_tcm (mvm, true); + mvm->fast_resume = true;set_bit (IWL_MVM_STATUS_IN_D3 , &mvm->status);
@@ -3295,6 +3297,8 @@ int iwl_mvm_fast_resume(struct iwl_mvm *mvm) mvm->trans->state =IWL_TRANS_NO_FW ; } +iwl_mvm_resume_tcm (mvm); + out:clear_bit (IWL_MVM_STATUS_IN_D3 , &mvm->status); mvm->fast_resume = false;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 146/175 drm/amd/display: fix wrong color value mapping on MCM shaper LUT
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Melissa Wen <[email protected]>
[ Upstream commit 8f959d37c1f2efec6dac55915ee82302e98101fb ]
Some shimmer/colorful points appears when using the steamOS color pipeline for HDR on gaming with DCN32. These points look like black values being wrongly mapped to red/blue/green values. It was caused because the number of hw points in regular LUTs and in a shaper LUT was treated as the same.
DCN3+ regular LUTs have 257 bases and implicit deltas (i.e. HW calculates them), but shaper LUT is a special case: it has 256 bases and 256 deltas, as in DCN1-2 regular LUTs, and outputs 14-bit values.
Fix that by setting by decreasing in 1 the number of HW points computed in the LUT segmentation so that shaper LUT (i.e. fixpoint == true) keeps the same DCN10 CM logic and regular LUTs go with hw_points + 1.
--- drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn30/dcn30_cm_common.c +5 -2
@@ -163,6 +163,11 @@ bool cm3_helper_translate_curve_to_hw_format( hw_points += (1 << seg_distr[k]); } +// DCN3+ have 257 pts in lieu of no separate slope registers +// Prior HW had 256 base+slope pairs +// Shaper LUT (i.e. fixpoint == true) is still 256 bases and 256 deltas + hw_points = fixpoint ? (hw_points -1 ) : hw_points; + j =0 ;for (k =0 ; k < (region_end - region_start); k++) { increment =NUMBER_SW_SEGMENTS / (1 << seg_distr[k]);
@@ -223,8 +228,6 @@ bool cm3_helper_translate_curve_to_hw_format( corner_points[1 ].green.slope = dc_fixpt_zero; corner_points[1 ].blue.slope = dc_fixpt_zero; -// DCN3+ have 257 pts in lieu of no separate slope registers -// Prior HW had 256 base+slope pairs lut_params->hw_points_num = hw_points +1 ; k =0 ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 147/175 net: ethernet: adi: adin1110: Check return value of devm_gpiod_get_optional() in adin1110_check_spi()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ni <[email protected]>
[ Upstream commit 78211543d2e44f84093049b4ef5f5bfa535f4645 ]
The devm_gpiod_get_optional() function may return an ERR_PTR in case of genuine GPIO acquisition errors, not just NULL which indicates the legitimate absence of an optional GPIO.
Add an IS_ERR() check after the call in adin1110_check_spi(). On error, return the error code to ensure proper failure handling rather than proceeding with invalid pointers.
--- drivers/net/ethernet/adi/adin1110.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/adi/adin1110.c +3 -0
@@ -1089,6 +1089,9 @@ static int adin1110_check_spi(struct adin1110_priv *priv) reset_gpio =devm_gpiod_get_optional (&priv->spidev->dev,"reset" ,GPIOD_OUT_LOW ); +if (IS_ERR (reset_gpio)) +return dev_err_probe (&priv->spidev->dev,PTR_ERR (reset_gpio), +"failed to get reset gpio\n" );if (reset_gpio) {/* MISO pin is used for internal configuration, can't have * anyone else disturbing the SDO line.
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 148/175 net: add proper RCU protection to /proc/net/ptype
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit f613e8b4afea0cd17c7168e8b00e25bc8d33175d ]
Yin Fengwei reported an RCU stall in ptype_seq_show() and provided a patch.
Real issue is that ptype_seq_next() and ptype_seq_show() violate RCU rules.
ptype_seq_show() runs under rcu_read_lock(), and reads pt->dev to get device name without any barrier.
At the same time, concurrent writers can remove a packet_type structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.
Define ptype_iter_state to carry a dev pointer along seq_net_private:
struct ptype_iter_state {
struct seq_net_private p;
struct net_device *dev; // added in this patch
};We need to record the device pointer in ptype_get_idx() and ptype_seq_next() so that ptype_seq_show() is safe against concurrent pt->dev changes.
We also need to add full RCU protection in ptype_seq_next(). (Missing READ_ONCE() when reading list.next values)
Many thanks to Dong Chenchen for providing a repro.
--- net/core/net-procfs.c | 50 +++++++++++++++++++++++++++++-------------- 1 file changed, 34 insertions(+), 16 deletions(-)
net/core/net-procfs.c +34 -16
@@ -170,8 +170,14 @@ static const struct seq_operations softnet_seq_ops = { .show = softnet_seq_show, }; +struct ptype_iter_state { +struct seq_net_private p; +struct net_device *dev; +}; +static void *ptype_get_idx (struct seq_file *seq,loff_t pos) { +struct ptype_iter_state *iter = seq->private;struct list_head *ptype_list =NULL ;struct packet_type *pt =NULL ;struct net_device *dev;
@@ -181,12 +187,16 @@ static void *ptype_get_idx(struct seq_file *seq, loff_t pos)for_each_netdev_rcu (seq_file_net (seq), dev) { ptype_list = &dev->ptype_all;list_for_each_entry_rcu (pt, ptype_list, list) { -if (i == pos) +if (i == pos) { + iter->dev = dev;return pt; + } ++i; } } + iter->dev =NULL ; +list_for_each_entry_rcu (pt, &seq_file_net (seq)->ptype_all, list) {if (i == pos)return pt;
@@ -218,6 +228,7 @@ static void *ptype_seq_start(struct seq_file *seq, loff_t *pos)static void *ptype_seq_next (struct seq_file *seq,void *v,loff_t *pos) { +struct ptype_iter_state *iter = seq->private;struct net *net =seq_file_net (seq);struct net_device *dev;struct packet_type *pt;
@@ -229,19 +240,21 @@ static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos)return ptype_get_idx (seq,0 ); pt = v; - nxt = pt->list.next; -if (pt->dev) { -if (nxt != &pt->dev->ptype_all) + nxt =READ_ONCE (pt->list.next); + dev = iter->dev; +if (dev) { +if (nxt != &dev->ptype_all) goto found; - dev = pt->dev;for_each_netdev_continue_rcu (seq_file_net (seq), dev) { -if (!list_empty (&dev->ptype_all)) { - nxt = dev->ptype_all.next; + nxt =READ_ONCE (dev->ptype_all.next); +if (nxt != &dev->ptype_all) { + iter->dev = dev; goto found; } } - nxt = net->ptype_all.next; + iter->dev =NULL ; + nxt =READ_ONCE (net->ptype_all.next); goto net_ptype_all; }
@@ -252,20 +265,20 @@ static void *ptype_seq_next(struct seq_file *seq, void *v, loff_t *pos)if (nxt == &net->ptype_all) {/* continue with ->ptype_specific if it's not empty */ - nxt = net->ptype_specific.next; + nxt =READ_ONCE (net->ptype_specific.next);if (nxt != &net->ptype_specific) goto found; } hash =0 ; - nxt = ptype_base[0 ].next; + nxt =READ_ONCE (ptype_base[0 ].next); }else hash =ntohs (pt->type) &PTYPE_HASH_MASK ;while (nxt == &ptype_base[hash]) {if (++hash >=PTYPE_HASH_SIZE )return NULL ; - nxt = ptype_base[hash].next; + nxt =READ_ONCE (ptype_base[hash].next); } found: return list_entry(nxt, struct packet_type, list);
@@ -279,19 +292,24 @@ static void ptype_seq_stop(struct seq_file *seq, void *v)static int ptype_seq_show (struct seq_file *seq,void *v) { +struct ptype_iter_state *iter = seq->private;struct packet_type *pt = v; +struct net_device *dev; -if (v ==SEQ_START_TOKEN ) +if (v ==SEQ_START_TOKEN ) {seq_puts (seq,"Type Device Function\n" ); -else if ((!pt->af_packet_net ||net_eq (pt->af_packet_net,seq_file_net (seq))) && - (!pt->dev ||net_eq (dev_net (pt->dev),seq_file_net (seq)))) { +return 0 ; + } + dev = iter->dev; +if ((!pt->af_packet_net ||net_eq (pt->af_packet_net,seq_file_net (seq))) && + (!dev ||net_eq (dev_net (dev),seq_file_net (seq)))) {if (pt->type ==htons (ETH_P_ALL ))seq_puts (seq,"ALL " );else seq_printf (seq,"%04x" ,ntohs (pt->type));seq_printf (seq," %-8s %ps\n" , - pt->dev ? pt->dev->name :"" , pt->func); + dev ? dev->name :"" , pt->func); }return 0 ;
@@ -315,7 +333,7 @@ static int __net_init dev_proc_net_init(struct net *net) &softnet_seq_ops)) goto out_dev;if (!proc_create_net ("ptype" ,0444 , net->proc_net, &ptype_seq_ops, -sizeof (struct seq_net_private ))) +sizeof (struct ptype_iter_state ))) goto out_softnet;if (wext_proc_init (net))
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 149/175 net: gro: fix outer network offset
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paolo Abeni <[email protected]>
[ Upstream commit 5c2c3c38be396257a6a2e55bd601a12bb9781507 ]
The udp GRO complete stage assumes that all the packets inserted the RX have the encapsulation flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup.
Due to the above, in the problematic scenarios, udp4_gro_complete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing.
Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udp_gro_complete().
--- net/core/gro.c | 2 ++ 1 file changed, 2 insertions(+)
net/core/gro.c +2 -0
@@ -265,6 +265,8 @@ static void gro_complete(struct gro_node *gro, struct sk_buff *skb) goto out; } +/* NICs can feed encapsulated packets into GRO */ + skb->encapsulation =0 ;rcu_read_lock ();list_for_each_entry_rcu (ptype, head, list) {if (ptype->type != type || !ptype->callbacks.gro_complete)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 150/175 drm/mgag200: fix mgag200_bmc_stop_scanout()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jacob Keller <[email protected]>
[ Upstream commit 0e0c8f4d16de92520623aa1ea485cadbf64e6929 ]
The mgag200_bmc_stop_scanout() function is called by the .atomic_disable() handler for the MGA G200 VGA BMC encoder. This function performs a few register writes to inform the BMC of an upcoming mode change, and then polls to wait until the BMC actually stops.
The polling is implemented using a busy loop with udelay() and an iteration timeout of 300, resulting in the function blocking for 300 milliseconds.
The function gets called ultimately by the output_poll_execute work thread for the DRM output change polling thread of the mgag200 driver:
kworker/0:0-mm_ 3528 [000] 4555.315364:
ffffffffaa0e25b3 delay_halt.part.0+0x33
ffffffffc03f6188 mgag200_bmc_stop_scanout+0x178
ffffffffc087ae7a disable_outputs+0x12a
ffffffffc087c12a drm_atomic_helper_commit_tail+0x1a
ffffffffc03fa7b6 mgag200_mode_config_helper_atomic_commit_tail+0x26
ffffffffc087c9c1 commit_tail+0x91
ffffffffc087d51b drm_atomic_helper_commit+0x11b
ffffffffc0509694 drm_atomic_commit+0xa4
ffffffffc05105e8 drm_client_modeset_commit_atomic+0x1e8
ffffffffc0510ce6 drm_client_modeset_commit_locked+0x56
ffffffffc0510e24 drm_client_modeset_commit+0x24
ffffffffc088a743 __drm_fb_helper_restore_fbdev_mode_unlocked+0x93
ffffffffc088a683 drm_fb_helper_hotplug_event+0xe3
ffffffffc050f8aa drm_client_dev_hotplug+0x9a
ffffffffc088555a output_poll_execute+0x29a
ffffffffa9b35924 process_one_work+0x194
ffffffffa9b364ee worker_thread+0x2fe
ffffffffa9b3ecad kthread+0xdd
ffffffffa9a08549 ret_from_fork+0x29On a server running ptp4l with the mgag200 driver loaded, we found that ptp4l would sometimes get blocked from execution because of this busy waiting loop.
Every so often, approximately once every 20 minutes -- though with large variance -- the output_poll_execute() thread would detect some sort of change that required performing a hotplug event which results in attempting to stop the BMC scanout, resulting in a 300msec delay on one CPU.
On this system, ptp4l was pinned to a single CPU. When the output_poll_execute() thread ran on that CPU, it blocked ptp4l from executing for its 300 millisecond duration.
This resulted in PTP service disruptions such as failure to send a SYNC message on time, failure to handle ANNOUNCE messages on time, and clock check warnings from the application. All of this despite the application being configured with FIFO_RT and a higher priority than the background workqueue tasks. (However, note that the kernel did not use CONFIG_PREEMPT...)
It is unclear if the event is due to a faulty VGA connection, another bug, or actual events causing a change in the connection. At least on the system under test it is not a one-time event and consistently causes disruption to the time sensitive applications.
The function has some helpful comments explaining what steps it is attempting to take. In particular, step 3a and 3b are explained as such:
3a - The third step is to verify if there is an active scan. We are
waiting on a 0 on remhsyncsts (<XSPAREREG<0>.
3b - This step occurs only if the remove is actually scanning. We are
waiting for the end of the frame which is a 1 on remvsyncsts (<XSPAREREG<1>).
The actual steps 3a and 3b are implemented as while loops with a non-sleeping udelay(). The first step iterates while the tmp value at position 0 is *not* set. That is, it keeps iterating as long as the bit is zero. If the bit is already 0 (because there is no active scan), it will iterate the entire 300 attempts which wastes 300 milliseconds in total. This is opposite of what the description claims.
The step 3b logic only executes if we do not iterate over the entire 300 attempts in the first loop. If it does trigger, it is trying to check and wait for a 1 on the remvsyncsts. However, again the condition is actually inverted and it will loop as long as the bit is 1, stopping once it hits zero (rather than the explained attempt to wait until we see a 1).
Worse, both loops are implemented using non-sleeping waits which spin instead of allowing the scheduler to run other processes. If the kernel is not configured to allow arbitrary preemption, it will waste valuable CPU time doing nothing.
There does not appear to be any documentation for the BMC register interface, beyond what is in the comments here. It seems more probable that the comment here is correct and the implementation accidentally got inverted from the intended logic.
Reading through other DRM driver implementations, it does not appear that the .atomic_enable or .atomic_disable handlers need to delay instead of sleep. For example, the ast_astdp_encoder_helper_atomic_disable() function calls ast_dp_set_phy_sleep() which uses msleep(). The "atomic" in the name is referring to the atomic modesetting support, which is the support to enable atomic configuration from userspace, and not to the "atomic context" of the kernel. There is no reason to use udelay() here if a sleep would be sufficient.
Replace the while loops with a read_poll_timeout() based implementation that will sleep between iterations, and which stops polling once the condition is met (instead of looping as long as the condition is met). This aligns with the commented behavior and avoids blocking on the CPU while doing nothing.
Note the RREG_DAC is implemented using a statement expression to allow working properly with the read_poll_timeout family of functions. The other RREG_<TYPE> macros ought to be cleaned up to have better semantics, and several places in the mgag200 driver could make use of RREG_DAC or similar RREG_* macros should likely be cleaned up for better semantics as well, but that task has been left as a future cleanup for a non-bugfix.
--- drivers/gpu/drm/mgag200/mgag200_bmc.c | 31 +++++++++++---------------- drivers/gpu/drm/mgag200/mgag200_drv.h | 6 ++++++ 2 files changed, 18 insertions(+), 19 deletions(-)
drivers/gpu/drm/mgag200/mgag200_bmc.c +12 -19
@@ -1,6 +1,7 @@// SPDX-License-Identifier: GPL-2.0-only #include <linux/delay.h> +#include <linux/iopoll.h> #include <drm/drm_atomic_helper.h> #include <drm/drm_edid.h>
@@ -12,7 +13,7 @@void mgag200_bmc_stop_scanout (struct mga_device *mdev) {u8 tmp; -int iter_max; +int ret;/* * 1 - The first step is to inform the BMC of an upcoming mode
@@ -42,30 +43,22 @@ void mgag200_bmc_stop_scanout(struct mga_device *mdev)/* * 3a- The third step is to verify if there is an active scan. -* We are waiting for a 0 on remhsyncsts <XSPAREREG<0>). +* We are waiting for a 0 on remhsyncsts (<XSPAREREG<0>). */ - iter_max =300 ; -while (!(tmp &0x1 ) && iter_max) { -WREG8 (DAC_INDEX ,MGA1064_SPAREREG ); - tmp =RREG8 (DAC_DATA ); -udelay (1000 ); - iter_max--; - } + ret =read_poll_timeout (RREG_DAC , tmp, !(tmp &0x1 ), +1000 ,300000 , false, +MGA1064_SPAREREG ); +if (ret == -ETIMEDOUT ) +return ;/* -* 3b- This step occurs only if the remove is actually +* 3b- This step occurs only if the remote BMC is actually * scanning. We are waiting for the end of the frame which is * a 1 on remvsyncsts (XSPAREREG<1>) */ -if (iter_max) { - iter_max =300 ; -while ((tmp &0x2 ) && iter_max) { -WREG8 (DAC_INDEX ,MGA1064_SPAREREG ); - tmp =RREG8 (DAC_DATA ); -udelay (1000 ); - iter_max--; - } - } + (void )read_poll_timeout (RREG_DAC , tmp, (tmp &0x2 ), +1000 ,300000 , false, +MGA1064_SPAREREG ); }void mgag200_bmc_start_scanout (struct mga_device *mdev)
drivers/gpu/drm/mgag200/mgag200_drv.h +6 -0
@@ -111,6 +111,12 @@#define DAC_INDEX 0x3c00#define DAC_DATA 0x3c0a +#define RREG_DAC (reg) \ + ({ \ + WREG8(DAC_INDEX, reg); \ + RREG8(DAC_DATA); \ + }) \ +#define WREG_DAC (reg, v) \ do { \ WREG8(DAC_INDEX, reg); \
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 151/175 drm/xe/query: Fix topology query pointer advance
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shuicheng Lin <[email protected]>
[ Upstream commit 7ee9b3e091c63da71e15c72003f1f07e467f5158 ]
The topology query helper advanced the user pointer by the size of the pointer, not the size of the structure. This can misalign the output blob and corrupt the following mask. Fix the increment to use sizeof(*topo).
There is no issue currently, as sizeof(*topo) happens to be equal to sizeof(topo) on 64-bit systems (both evaluate to 8 bytes).
--- drivers/gpu/drm/xe/xe_query.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/xe/xe_query.c +1 -1
@@ -491,7 +491,7 @@ static int copy_mask(void __user **ptr,if (copy_to_user (*ptr, topo,sizeof (*topo)))return -EFAULT ; - *ptr +=sizeof (topo); + *ptr +=sizeof (*topo);if (copy_to_user (*ptr, mask, mask_size))return -EFAULT ;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 152/175 drm/xe/pm: Disable D3Cold for BMG only on specific platforms
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Karthik Poosa <[email protected]>
[ Upstream commit bb36170d959fad7f663f91eb9c32a84dd86bef2b ]
Restrict D3Cold disablement for BMG to unsupported NUC platforms, instead of disabling it on all platforms.
--- drivers/gpu/drm/xe/xe_pm.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
drivers/gpu/drm/xe/xe_pm.c +10 -3
@@ -8,6 +8,7 @@#include <linux/fault-inject.h> #include <linux/pm_runtime.h> #include <linux/suspend.h> +#include <linux/dmi.h> #include <drm/drm_managed.h> #include <drm/ttm/ttm_placement.h>
@@ -300,9 +301,15 @@ ALLOW_ERROR_INJECTION(xe_pm_init_early, ERRNO); /* See xe_pci_probe() */static u32 vram_threshold_value (struct xe_device *xe) { -/* FIXME: D3Cold temporarily disabled by default on BMG */ -if (xe->info.platform ==XE_BATTLEMAGE ) -return 0 ; +if (xe->info.platform ==XE_BATTLEMAGE ) { +const char *product_name; + + product_name =dmi_get_system_info (DMI_PRODUCT_NAME ); +if (product_name &&strstr (product_name,"NUC13RNG" )) { +drm_warn (&xe->drm,"BMG + D3Cold not supported on this platform\n" ); +return 0 ; + } + }return DEFAULT_VRAM_THRESHOLD ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 153/175 hwmon: (occ) Mark occ_init_attribute() as __printf
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit 831a2b27914cc880130ffe8fb8d1e65a5324d07f ]
This is a printf-style function, which gcc -Werror=suggest-attribute=format correctly points out:
drivers/hwmon/occ/common.c: In function 'occ_init_attribute':drivers/hwmon/occ/common.c:761:9: error: function 'occ_init_attribute' might be a candidate for 'gnu_printf' format attribute [-Werror=suggest-attribute=format]
Add the attribute to avoid this warning and ensure any incorrect format strings are detected here.
--- drivers/hwmon/occ/common.c | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/occ/common.c +1 -0
@@ -749,6 +749,7 @@ static ssize_t occ_show_extended(struct device *dev,* are dynamically allocated, we cannot use the existing kernel macros which * stringify the name argument. */ +__printf(7, 8) static void occ_init_attribute(struct occ_attribute *attr, int mode, ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf), ssize_t (*store)(struct device *dev, struct device_attribute *attr,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 154/175 netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Fasano <[email protected]>
[ Upstream commit f41c5d151078c5348271ffaf8e7410d96f2d82f8 ]
nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required.
nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones.
Compare the non-catchall activate callback, which is correct:
nft_mapelem_activate():
if (nft_set_elem_active(ext, iter->genmask))
return 0; /* skip active, process inactive */
With the buggy catchall version:
nft_map_catchall_activate():
if (!nft_set_elem_active(ext, genmask))
continue; /* skip inactive, process active */
The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free.
This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES.
Fix by removing the negation so the check matches nft_mapelem_activate():
skip active elements, process inactive ones.
--- net/netfilter/nf_tables_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/nf_tables_api.c +1 -1
@@ -5917,7 +5917,7 @@ static void nft_map_catchall_activate(const struct nft_ctx *ctx,list_for_each_entry (catchall, &set->catchall_list, list) { ext =nft_set_elem_ext (set, catchall->elem); -if (!nft_set_elem_active (ext, genmask)) +if (nft_set_elem_active (ext, genmask))continue ;nft_clear (ctx->net, ext);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 155/175 drm/xe/guc: Fix CFI violation in debugfs access.
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniele Ceraolo Spurio <[email protected]>
[ Upstream commit 4cb1b327135dddf3d0ec2544ea36ed05ba2252bc ]
xe_guc_print_info is void-returning, but the function pointer it is assigned to expects an int-returning function, leading to the following CFI error:
[ 206.873690] CFI failure at guc_debugfs_show+0xa1/0xf0 [xe]
(target: xe_guc_print_info+0x0/0x370 [xe]; expected type: 0xbe3bc66a)
Fix this by updating xe_guc_print_info to return an integer.
--- drivers/gpu/drm/xe/xe_guc.c | 6 ++++-- drivers/gpu/drm/xe/xe_guc.h | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-)
drivers/gpu/drm/xe/xe_guc.c +4 -2
@@ -1632,7 +1632,7 @@ int xe_guc_start(struct xe_guc *guc)return xe_guc_submit_start (guc); } -void xe_guc_print_info (struct xe_guc *guc,struct drm_printer *p) +int xe_guc_print_info (struct xe_guc *guc,struct drm_printer *p) {struct xe_gt *gt =guc_to_gt (guc);unsigned int fw_ref;
@@ -1644,7 +1644,7 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)if (!IS_SRIOV_VF (gt_to_xe (gt))) { fw_ref =xe_force_wake_get (gt_to_fw (gt),XE_FW_GT );if (!fw_ref) -return ; +return -EIO ; status =xe_mmio_read32 (>->mmio,GUC_STATUS );
@@ -1672,6 +1672,8 @@ void xe_guc_print_info(struct xe_guc *guc, struct drm_printer *p)drm_puts (p,"\n" );xe_guc_submit_print (guc, p); + +return 0 ; }/**
drivers/gpu/drm/xe/xe_guc.h +1 -1
@@ -45,7 +45,7 @@ int xe_guc_self_cfg32(struct xe_guc *guc, u16 key, u32 val);int xe_guc_self_cfg64 (struct xe_guc *guc,u16 key,u64 val);void xe_guc_irq_handler (struct xe_guc *guc,const u16 iir);void xe_guc_sanitize (struct xe_guc *guc); -void xe_guc_print_info (struct xe_guc *guc,struct drm_printer *p); +int xe_guc_print_info (struct xe_guc *guc,struct drm_printer *p);int xe_guc_reset_prepare (struct xe_guc *guc);void xe_guc_reset_wait (struct xe_guc *guc);void xe_guc_stop_prepare (struct xe_guc *guc);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 156/175 nvme-pci: handle changing device dma map requirements
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Keith Busch <[email protected]>
[ Upstream commit 071be3b0b6575d45be9df9c5b612f5882bfc5e88 ]
The initial state of dma_needs_unmap may be false, but change to true while mapping the data iterator. Enabling swiotlb is one such case that can change the result. The nvme driver needs to save the mapped dma vectors to be unmapped later, so allocate as needed during iteration rather than assume it was always allocated at the beginning. This fixes a NULL dereference from accessing an uninitialized dma_vecs when the device dma unmapping requirements change mid-iteration.
--- drivers/nvme/host/pci.c | 45 +++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 15 deletions(-)
drivers/nvme/host/pci.c +30 -15
@@ -771,6 +771,32 @@ static void nvme_unmap_data(struct request *req)nvme_free_descriptors (req); } +static bool nvme_pci_prp_save_mapping (struct request *req, +struct device *dma_dev, +struct blk_dma_iter *iter) +{ +struct nvme_iod *iod =blk_mq_rq_to_pdu (req); + +if (dma_use_iova (&iod->dma_state) || !dma_need_unmap (dma_dev)) +return true; + +if (!iod->nr_dma_vecs) { +struct nvme_queue *nvmeq = req->mq_hctx->driver_data; + + iod->dma_vecs =mempool_alloc (nvmeq->dev->dmavec_mempool, +GFP_ATOMIC ); +if (!iod->dma_vecs) { + iter->status =BLK_STS_RESOURCE ; +return false; + } + } + + iod->dma_vecs[iod->nr_dma_vecs].addr = iter->addr; + iod->dma_vecs[iod->nr_dma_vecs].len = iter->len; + iod->nr_dma_vecs++; +return true; +} +static bool nvme_pci_prp_iter_next (struct request *req,struct device *dma_dev,struct blk_dma_iter *iter) {
@@ -780,12 +806,7 @@ static bool nvme_pci_prp_iter_next(struct request *req, struct device *dma_dev,return true;if (!blk_rq_dma_map_iter_next (req, dma_dev, &iod->dma_state, iter))return false; -if (!dma_use_iova (&iod->dma_state) &&dma_need_unmap (dma_dev)) { - iod->dma_vecs[iod->nr_dma_vecs].addr = iter->addr; - iod->dma_vecs[iod->nr_dma_vecs].len = iter->len; - iod->nr_dma_vecs++; - } -return true; +return nvme_pci_prp_save_mapping (req, dma_dev, iter); } static blk_status_t nvme_pci_setup_data_prp(struct request *req,
@@ -798,15 +819,8 @@ static blk_status_t nvme_pci_setup_data_prp(struct request *req,unsigned int prp_len, i;__le64 *prp_list; -if (!dma_use_iova (&iod->dma_state) &&dma_need_unmap (nvmeq->dev->dev)) { - iod->dma_vecs =mempool_alloc (nvmeq->dev->dmavec_mempool, -GFP_ATOMIC ); -if (!iod->dma_vecs) -return BLK_STS_RESOURCE ; - iod->dma_vecs[0 ].addr = iter->addr; - iod->dma_vecs[0 ].len = iter->len; - iod->nr_dma_vecs =1 ; - } +if (!nvme_pci_prp_save_mapping (req, nvmeq->dev->dev, iter)) +return iter->status;/* * PRP1 always points to the start of the DMA transfers.
@@ -1148,6 +1162,7 @@ static blk_status_t nvme_prep_rq(struct request *req) iod->nr_descriptors =0 ; iod->total_len =0 ; iod->meta_total_len =0 ; + iod->nr_dma_vecs =0 ; ret =nvme_setup_cmd (req->q->queuedata, req);if (ret)
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 157/175 ipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit bbf4a17ad9ffc4e3d7ec13d73ecd59dea149ed25 ]
syzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6 route. [0]
Commit f72514b3c569 ("ipv6: clear RA flags when adding a static route") introduced logic to clear RTF_ADDRCONF from existing routes when a static route with the same nexthop is added. However, this causes a problem when the existing route has a gateway.
When RTF_ADDRCONF is cleared from a route that has a gateway, that route becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns true. The issue is that this route was never added to the fib6_siblings list.
This leads to a mismatch between the following counts:
- The sibling count computed by iterating fib6_next chain, which includes the newly ECMP-eligible route
- The actual siblings in fib6_siblings list, which does not include that route
When a subsequent ECMP route is added, fib6_add_rt2node() hits BUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings) because the counts don't match.
Fix this by only clearing RTF_ADDRCONF when the existing route does not have a gateway. Routes without a gateway cannot qualify for ECMP anyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing RTF_ADDRCONF on them is safe and matches the original intent of the commit.
[0]:
kernel BUG at net/ipv6/ip6_fib.c:1217!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025 RIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217 [...] Call Trace: <TASK> fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532 __ip6_ins_rt net/ipv6/route.c:1351 [inline] ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946 ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571 inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577 sock_do_ioctl+0xdc/0x300 net/socket.c:1245 sock_ioctl+0x576/0x790 net/socket.c:1366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f
--- net/ipv6/ip6_fib.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/ipv6/ip6_fib.c +2 -1
@@ -1138,7 +1138,8 @@ static int fib6_add_rt2node(struct fib6_node *fn, struct fib6_info *rt,fib6_set_expires (iter, rt->expires);fib6_add_gc_list (iter); } -if (!(rt->fib6_flags & (RTF_ADDRCONF |RTF_PREFIX_RT ))) { +if (!(rt->fib6_flags & (RTF_ADDRCONF |RTF_PREFIX_RT )) && + !iter->fib6_nh->fib_nh_gw_family) { iter->fib6_flags &= ~RTF_ADDRCONF ; iter->fib6_flags &= ~RTF_PREFIX_RT ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 158/175 firmware: cs_dsp: Factor out common debugfs string read
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit 78cfd833bc04c0398ca4cfc64704350aebe4d4c2 ]
cs_dsp_debugfs_wmfw_read() and cs_dsp_debugfs_bin_read() were identical except for which struct member they printed. Move all this duplicated code into a common function cs_dsp_debugfs_string_read().
The check for dsp->booted has been removed because this is redundant. The two strings are set when the DSP is booted and cleared when the DSP is powered-down.
Access to the string char * must be protected by the pwr_lock mutex. The string is passed into cs_dsp_debugfs_string_read() as a pointer to the char * so that the mutex lock can also be factored out into cs_dsp_debugfs_string_read().
wmfw_file_name and bin_file_name members of struct cs_dsp have been changed to const char *. It makes for a better API to pass a const pointer into cs_dsp_debugfs_string_read().
Stable-dep-of: 10db9f6899dd ("firmware: cs_dsp: rate-limit log messages in KUnit builds")
--- drivers/firmware/cirrus/cs_dsp.c | 45 ++++++++++++-------------- include/linux/firmware/cirrus/cs_dsp.h | 4 +-- 2 files changed, 23 insertions(+), 26 deletions(-)
drivers/firmware/cirrus/cs_dsp.c +21 -24
@@ -9,6 +9,7 @@* Cirrus Logic International Semiconductor Ltd. */ +#include <linux/cleanup.h> #include <linux/ctype.h> #include <linux/debugfs.h> #include <linux/delay.h>
@@ -410,24 +411,30 @@ static void cs_dsp_debugfs_clear(struct cs_dsp *dsp) dsp->bin_file_name =NULL ; } +static ssize_t cs_dsp_debugfs_string_read (struct cs_dsp *dsp, +char __user *user_buf, +size_t count,loff_t *ppos, +const char **pstr) +{ +const char *str; + + scoped_guard(mutex, &dsp->pwr_lock) { + str = *pstr; +if (!str) +return 0 ; + +return simple_read_from_buffer (user_buf, count, ppos, str,strlen (str)); + } +} +static ssize_t cs_dsp_debugfs_wmfw_read (struct file *file,char __user *user_buf,size_t count,loff_t *ppos) {struct cs_dsp *dsp = file->private_data; -ssize_t ret; -mutex_lock (&dsp->pwr_lock); - -if (!dsp->wmfw_file_name || !dsp->booted) - ret =0 ; -else - ret =simple_read_from_buffer (user_buf, count, ppos, - dsp->wmfw_file_name, -strlen (dsp->wmfw_file_name)); - -mutex_unlock (&dsp->pwr_lock); -return ret; +return cs_dsp_debugfs_string_read (dsp, user_buf, count, ppos, + &dsp->wmfw_file_name); } static ssize_t cs_dsp_debugfs_bin_read(struct file *file,
@@ -435,19 +442,9 @@ static ssize_t cs_dsp_debugfs_bin_read(struct file *file, size_t count, loff_t *ppos) { struct cs_dsp *dsp = file->private_data; -ssize_t ret; - -mutex_lock (&dsp->pwr_lock); -if (!dsp->bin_file_name || !dsp->booted) - ret =0 ; -else - ret =simple_read_from_buffer (user_buf, count, ppos, - dsp->bin_file_name, -strlen (dsp->bin_file_name)); - -mutex_unlock (&dsp->pwr_lock); -return ret; +return cs_dsp_debugfs_string_read (dsp, user_buf, count, ppos, + &dsp->bin_file_name); } static const struct {
include/linux/firmware/cirrus/cs_dsp.h +2 -2
@@ -188,8 +188,8 @@ struct cs_dsp {#ifdef CONFIG_DEBUG_FS struct dentry *debugfs_root; -char *wmfw_file_name; -char *bin_file_name; +const char *wmfw_file_name; +const char *bin_file_name;#endif };
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 159/175 firmware: cs_dsp: rate-limit log messages in KUnit builds
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Richard Fitzgerald <[email protected]>
[ Upstream commit 10db9f6899dd3a2dfd26efd40afd308891dc44a8 ]
Use the dev_*_ratelimit() macros if the cs_dsp KUnit tests are enabled in the build, and allow the KUnit tests to disable message output.
Some of the KUnit tests cause a very large number of log messages from cs_dsp, because the tests perform many different test cases. This could cause some lines to be dropped from the kernel log. Dropped lines can prevent the KUnit wrappers from parsing the ktap output in the dmesg log.
The KUnit builds of cs_dsp export three bools that the KUnit tests can use to entirely disable log output of err, warn and info messages. Some tests have been updated to use this, replacing the previous fudge of a usleep() in the exit handler of each test. We don't necessarily want to disable all log messages if they aren't expected to be excessive, so the rate-limiting allows leaving some logging enabled.
The rate-limited macros are not used in normal builds because it is not appropriate to rate-limit every message. That could cause important messages to be dropped, and there wouldn't be such a high rate of messages in normal operation.
--- drivers/firmware/cirrus/cs_dsp.c | 37 +++++++++++++++++++ drivers/firmware/cirrus/cs_dsp.h | 18 +++++++++ .../firmware/cirrus/test/cs_dsp_test_bin.c | 22 ++++++++++- .../cirrus/test/cs_dsp_test_bin_error.c | 24 +++++++++--- .../firmware/cirrus/test/cs_dsp_test_wmfw.c | 26 ++++++++++++- .../cirrus/test/cs_dsp_test_wmfw_error.c | 24 +++++++++--- drivers/firmware/cirrus/test/cs_dsp_tests.c | 1 + 7 files changed, 138 insertions(+), 14 deletions(-) create mode 100644 drivers/firmware/cirrus/cs_dsp.h
drivers/firmware/cirrus/cs_dsp.c +37 -0
@@ -9,6 +9,7 @@* Cirrus Logic International Semiconductor Ltd. */ +#include <kunit/visibility.h> #include <linux/cleanup.h> #include <linux/ctype.h> #include <linux/debugfs.h>
@@ -23,6 +24,41 @@#include <linux/firmware/cirrus/cs_dsp.h> #include <linux/firmware/cirrus/wmfw.h> +#include "cs_dsp.h" + +/* +* When the KUnit test is running the error-case tests will cause a lot +* of messages. Rate-limit to prevent overflowing the kernel log buffer +* during KUnit test runs. +*/ +#if IS_ENABLED (CONFIG_FW_CS_DSP_KUNIT_TEST ) +bool cs_dsp_suppress_err_messages; +EXPORT_SYMBOL_IF_KUNIT (cs_dsp_suppress_err_messages); + +bool cs_dsp_suppress_warn_messages; +EXPORT_SYMBOL_IF_KUNIT (cs_dsp_suppress_warn_messages); + +bool cs_dsp_suppress_info_messages; +EXPORT_SYMBOL_IF_KUNIT (cs_dsp_suppress_info_messages); + +#define cs_dsp_err (_dsp, fmt, ...) \ + do { \ + if (!cs_dsp_suppress_err_messages) \ + dev_err_ratelimited(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__); \ + } while (false) +#define cs_dsp_warn (_dsp, fmt, ...) \ + do { \ + if (!cs_dsp_suppress_warn_messages) \ + dev_warn_ratelimited(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__); \ + } while (false) +#define cs_dsp_info (_dsp, fmt, ...) \ + do { \ + if (!cs_dsp_suppress_info_messages) \ + dev_info_ratelimited(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__); \ + } while (false) +#define cs_dsp_dbg (_dsp, fmt, ...) \ + dev_dbg_ratelimited(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__) +#else #define cs_dsp_err (_dsp, fmt, ...) \ dev_err(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__)#define cs_dsp_warn (_dsp, fmt, ...) \
@@ -31,6 +67,7 @@ dev_info(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__)#define cs_dsp_dbg (_dsp, fmt, ...) \ dev_dbg(_dsp->dev, "%s: " fmt, _dsp->name, ##__VA_ARGS__) +#endif #define ADSP1_CONTROL_1 0x00#define ADSP1_CONTROL_2 0x02
drivers/firmware/cirrus/cs_dsp.h new file +18 -0
@@ -0,0 +1,18 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* +* cs_dsp.h -- Private header for cs_dsp driver. +* +* Copyright (C) 2026 Cirrus Logic, Inc. and +* Cirrus Logic International Semiconductor Ltd. +*/ + +#ifndef FW_CS_DSP_H +#define FW_CS_DSP_H + +#if IS_ENABLED (CONFIG_KUNIT ) +extern bool cs_dsp_suppress_err_messages; +extern bool cs_dsp_suppress_warn_messages; +extern bool cs_dsp_suppress_info_messages; +#endif + +#endif /* ifndef FW_CS_DSP_H */
drivers/firmware/cirrus/test/cs_dsp_test_bin.c +21 -1
@@ -17,6 +17,8 @@#include <linux/random.h> #include <linux/regmap.h> +#include "../cs_dsp.h" +/* * Test method is: *
@@ -2224,7 +2226,22 @@ static int cs_dsp_bin_test_common_init(struct kunit *test, struct cs_dsp *dsp)return ret;/* Automatically call cs_dsp_remove() when test case ends */ -return kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); + ret =kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); +if (ret) +return ret; + +/* +* The large number of test cases will cause an unusually large amount +* of dev_info() messages from cs_dsp, so suppress these. +*/ + cs_dsp_suppress_info_messages = true; + +return 0 ; +} + +static void cs_dsp_bin_test_exit (struct kunit *test) +{ + cs_dsp_suppress_info_messages = false; }static int cs_dsp_bin_test_halo_init (struct kunit *test)
@@ -2536,18 +2553,21 @@ static struct kunit_case cs_dsp_bin_test_cases_adsp2[] = {static struct kunit_suite cs_dsp_bin_test_halo = { .name ="cs_dsp_bin_halo" , .init = cs_dsp_bin_test_halo_init, + .exit = cs_dsp_bin_test_exit, .test_cases = cs_dsp_bin_test_cases_halo, };static struct kunit_suite cs_dsp_bin_test_adsp2_32bit = { .name ="cs_dsp_bin_adsp2_32bit" , .init = cs_dsp_bin_test_adsp2_32bit_init, + .exit = cs_dsp_bin_test_exit, .test_cases = cs_dsp_bin_test_cases_adsp2, };static struct kunit_suite cs_dsp_bin_test_adsp2_16bit = { .name ="cs_dsp_bin_adsp2_16bit" , .init = cs_dsp_bin_test_adsp2_16bit_init, + .exit = cs_dsp_bin_test_exit, .test_cases = cs_dsp_bin_test_cases_adsp2, };
drivers/firmware/cirrus/test/cs_dsp_test_bin_error.c +18 -6
@@ -18,6 +18,8 @@#include <linux/string.h> #include <linux/vmalloc.h> +#include "../cs_dsp.h" + KUNIT_DEFINE_ACTION_WRAPPER(_put_device_wrapper, put_device, struct device *); KUNIT_DEFINE_ACTION_WRAPPER(_cs_dsp_remove_wrapper, cs_dsp_remove, struct cs_dsp *);
@@ -380,11 +382,9 @@ static void bin_block_payload_len_garbage(struct kunit *test)static void cs_dsp_bin_err_test_exit (struct kunit *test) { -/* -* Testing error conditions can produce a lot of log output -* from cs_dsp error messages, so rate limit the test cases. -*/ -usleep_range (200 ,500 ); + cs_dsp_suppress_err_messages = false; + cs_dsp_suppress_warn_messages = false; + cs_dsp_suppress_info_messages = false; } static int cs_dsp_bin_err_test_common_init(struct kunit *test, struct cs_dsp *dsp,
@@ -474,7 +474,19 @@ static int cs_dsp_bin_err_test_common_init(struct kunit *test, struct cs_dsp *dsreturn ret;/* Automatically call cs_dsp_remove() when test case ends */ -return kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); + ret =kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); +if (ret) +return ret; + +/* +* Testing error conditions can produce a lot of log output +* from cs_dsp error messages, so suppress messages. +*/ + cs_dsp_suppress_err_messages = true; + cs_dsp_suppress_warn_messages = true; + cs_dsp_suppress_info_messages = true; + +return 0 ; }static int cs_dsp_bin_err_test_halo_init (struct kunit *test)
drivers/firmware/cirrus/test/cs_dsp_test_wmfw.c +25 -1
@@ -18,6 +18,8 @@#include <linux/string.h> #include <linux/vmalloc.h> +#include "../cs_dsp.h" +/* * Test method is: *
@@ -1853,7 +1855,22 @@ static int cs_dsp_wmfw_test_common_init(struct kunit *test, struct cs_dsp *dsp,return ret;/* Automatically call cs_dsp_remove() when test case ends */ -return kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); + ret =kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); +if (ret) +return ret; + +/* +* The large number of test cases will cause an unusually large amount +* of dev_info() messages from cs_dsp, so suppress these. +*/ + cs_dsp_suppress_info_messages = true; + +return 0 ; +} + +static void cs_dsp_wmfw_test_exit (struct kunit *test) +{ + cs_dsp_suppress_info_messages = false; }static int cs_dsp_wmfw_test_halo_init (struct kunit *test)
@@ -2163,42 +2180,49 @@ static struct kunit_case cs_dsp_wmfw_test_cases_adsp2[] = {static struct kunit_suite cs_dsp_wmfw_test_halo = { .name ="cs_dsp_wmfwV3_halo" , .init = cs_dsp_wmfw_test_halo_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_halo, };static struct kunit_suite cs_dsp_wmfw_test_adsp2_32bit_wmfw0 = { .name ="cs_dsp_wmfwV0_adsp2_32bit" , .init = cs_dsp_wmfw_test_adsp2_32bit_wmfw0_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_adsp2, };static struct kunit_suite cs_dsp_wmfw_test_adsp2_32bit_wmfw1 = { .name ="cs_dsp_wmfwV1_adsp2_32bit" , .init = cs_dsp_wmfw_test_adsp2_32bit_wmfw1_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_adsp2, };static struct kunit_suite cs_dsp_wmfw_test_adsp2_32bit_wmfw2 = { .name ="cs_dsp_wmfwV2_adsp2_32bit" , .init = cs_dsp_wmfw_test_adsp2_32bit_wmfw2_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_adsp2, };static struct kunit_suite cs_dsp_wmfw_test_adsp2_16bit_wmfw0 = { .name ="cs_dsp_wmfwV0_adsp2_16bit" , .init = cs_dsp_wmfw_test_adsp2_16bit_wmfw0_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_adsp2, };static struct kunit_suite cs_dsp_wmfw_test_adsp2_16bit_wmfw1 = { .name ="cs_dsp_wmfwV1_adsp2_16bit" , .init = cs_dsp_wmfw_test_adsp2_16bit_wmfw1_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_adsp2, };static struct kunit_suite cs_dsp_wmfw_test_adsp2_16bit_wmfw2 = { .name ="cs_dsp_wmfwV2_adsp2_16bit" , .init = cs_dsp_wmfw_test_adsp2_16bit_wmfw2_init, + .exit = cs_dsp_wmfw_test_exit, .test_cases = cs_dsp_wmfw_test_cases_adsp2, };
drivers/firmware/cirrus/test/cs_dsp_test_wmfw_error.c +18 -6
@@ -18,6 +18,8 @@#include <linux/string.h> #include <linux/vmalloc.h> +#include "../cs_dsp.h" + KUNIT_DEFINE_ACTION_WRAPPER(_put_device_wrapper, put_device, struct device *); KUNIT_DEFINE_ACTION_WRAPPER(_cs_dsp_remove_wrapper, cs_dsp_remove, struct cs_dsp *);
@@ -989,11 +991,9 @@ static void wmfw_v2_coeff_description_exceeds_block(struct kunit *test)static void cs_dsp_wmfw_err_test_exit (struct kunit *test) { -/* -* Testing error conditions can produce a lot of log output -* from cs_dsp error messages, so rate limit the test cases. -*/ -usleep_range (200 ,500 ); + cs_dsp_suppress_err_messages = false; + cs_dsp_suppress_warn_messages = false; + cs_dsp_suppress_info_messages = false; } static int cs_dsp_wmfw_err_test_common_init(struct kunit *test, struct cs_dsp *dsp,
@@ -1072,7 +1072,19 @@ static int cs_dsp_wmfw_err_test_common_init(struct kunit *test, struct cs_dsp *dreturn ret;/* Automatically call cs_dsp_remove() when test case ends */ -return kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); + ret =kunit_add_action_or_reset (priv->test, _cs_dsp_remove_wrapper, dsp); +if (ret) +return ret; + +/* +* Testing error conditions can produce a lot of log output +* from cs_dsp error messages, so suppress messages. +*/ + cs_dsp_suppress_err_messages = true; + cs_dsp_suppress_warn_messages = true; + cs_dsp_suppress_info_messages = true; + +return 0 ; }static int cs_dsp_wmfw_err_test_halo_init (struct kunit *test)
drivers/firmware/cirrus/test/cs_dsp_tests.c +1 -0
@@ -12,3 +12,4 @@ MODULE_AUTHOR("Richard Fitzgerald <[email protected]>");MODULE_LICENSE ("GPL" );MODULE_IMPORT_NS ("FW_CS_DSP" );MODULE_IMPORT_NS ("FW_CS_DSP_KUNIT_TEST_UTILS" ); +MODULE_IMPORT_NS ("EXPORTED_FOR_KUNIT_TESTING" );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 160/175 ALSA: usb-audio: fix broken logic in snd_audigy2nx_led_update()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sergey Shtylyov <[email protected]>
[ Upstream commit 124bdc6eccc8c5cba68fee00e01c084c116c4360 ]
When the support for the Sound Blaster X-Fi Surround 5.1 Pro was added, the existing logic for the X-Fi Surround 5.1 in snd_audigy2nx_led_put() was broken due to missing *else* before the added *if*: snd_usb_ctl_msg() became incorrectly called twice and an error from first snd_usb_ctl_msg() call ignored. As the added snd_usb_ctl_msg() call was totally identical to the existing one for the "plain" X-Fi Surround 5.1, just merge those two *if* statements while fixing the broken logic...
Found by Linux Verification Center (linuxtesting.org) with the Svace static analysis tool.
--- sound/usb/mixer_quirks.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-)
sound/usb/mixer_quirks.c +2 -7
@@ -311,13 +311,8 @@ static int snd_audigy2nx_led_update(struct usb_mixer_interface *mixer,if (pm.err <0 )return pm.err; -if (chip->usb_id ==USB_ID (0x041e ,0x3042 )) - err =snd_usb_ctl_msg (chip->dev, -usb_sndctrlpipe (chip->dev,0 ),0x24 , -USB_DIR_OUT |USB_TYPE_VENDOR |USB_RECIP_OTHER , - !value,0 ,NULL ,0 ); -/* USB X-Fi S51 Pro */ -if (chip->usb_id ==USB_ID (0x041e ,0x30df )) +if (chip->usb_id ==USB_ID (0x041e ,0x3042 ) ||/* USB X-Fi S51 */ + chip->usb_id ==USB_ID (0x041e ,0x30df ))/* USB X-Fi S51 Pro */ err = snd_usb_ctl_msg(chip->dev, usb_sndctrlpipe(chip->dev, 0), 0x24, USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_OTHER,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 161/175 ASoC: amd: fix memory leak in acp3x pdm dma ops
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Bainbridge <[email protected]>
[ Upstream commit 7f67ba5413f98d93116a756e7f17cd2c1d6c2bd6 ]
--- sound/soc/amd/renoir/acp3x-pdm-dma.c | 2 ++ 1 file changed, 2 insertions(+)
sound/soc/amd/renoir/acp3x-pdm-dma.c +2 -0
@@ -301,9 +301,11 @@ static int acp_pdm_dma_close(struct snd_soc_component *component, struct snd_pcm_substream *substream) {struct pdm_dev_data *adata =dev_get_drvdata (component->dev); +struct pdm_stream_instance *rtd = substream->runtime->private_data;disable_pdm_interrupts (adata->acp_base); adata->capture_stream =NULL ; +kfree (rtd);return 0 ; }
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 162/175 gpio: loongson-64bit: Fix incorrect NULL check after devm_kcalloc()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chen Ni <[email protected]>
[ Upstream commit e34f77b09080c86c929153e2a72da26b4f8947ff ]
Fix incorrect NULL check in loongson_gpio_init_irqchip(). The function checks chip->parent instead of chip->irq.parents.
--- drivers/gpio/gpio-loongson-64bit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpio/gpio-loongson-64bit.c +1 -1
@@ -263,7 +263,7 @@ static int loongson_gpio_init_irqchip(struct platform_device *pdev, chip->irq.num_parents = data->intr_num; chip->irq.parents =devm_kcalloc (&pdev->dev, data->intr_num,sizeof (*chip->irq.parents),GFP_KERNEL ); -if (!chip->parent) +if (!chip->irq.parents)return -ENOMEM ;for (i =0 ; i < data->intr_num; i++) {
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 163/175 i2c: imx: preserve error state in block data length handler
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: LI Qingwu <[email protected]>
commit b126097b0327437048bd045a0e4d273dea2910dd upstream.
When a block read returns an invalid length, zero or >I2C_SMBUS_BLOCK_MAX, the length handler sets the state to IMX_I2C_STATE_FAILED. However, i2c_imx_master_isr() unconditionally overwrites this with IMX_I2C_STATE_READ_CONTINUE, causing an endless read loop that overruns buffers and crashes the system.
Guard the state transition to preserve error states set by the length handler.
--- drivers/i2c/busses/i2c-imx.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/i2c/busses/i2c-imx.c +2 -1
@@ -1103,7 +1103,8 @@ static irqreturn_t i2c_imx_master_isr(stcase IMX_I2C_STATE_READ_BLOCK_DATA_LEN :i2c_imx_isr_read_block_data_len (i2c_imx); - i2c_imx->state =IMX_I2C_STATE_READ_CONTINUE ; +if (i2c_imx->state ==IMX_I2C_STATE_READ_BLOCK_DATA_LEN ) + i2c_imx->state =IMX_I2C_STATE_READ_CONTINUE ;break ;case IMX_I2C_STATE_WRITE :
Greg Kroah-Hartman
maintainerPATCH 164/175 regulator: spacemit-p1: Fix n_voltages for BUCK and LDO regulators
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Guodong Xu <[email protected]>
[ Upstream commit 41399c5d476156635c9a58de870d39318e22fa09 ]
Higher voltage settings were unusable due to incorrect n_voltages values causing registration failures. For example, setting aldo4 to 3.3V failed with -EINVAL because the required selector (123) exceeded the allowed range (n_voltages=117).
Fix by aligning n_voltages with the hardware register widths per the P1 datasheet [1]:
- BUCK: 255 (was 254), allows selectors 0-254, selector 255 is reserved
- LDO: 128 (was 117), allows selectors 0-127, selectors 0-10 are for suspend mode, valid operational range is 11-127
This enables the full voltage range supported by the hardware.
--- drivers/regulator/spacemit-p1.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/regulator/spacemit-p1.c +3 -3
@@ -87,13 +87,13 @@ static const struct linear_range p1_ldo_ranges[] = { }#define P1_BUCK_DESC (_n) \ - P1_REG_DESC(BUCK, buck, _n, "vin", 0x47, BUCK_MASK, 254, p1_buck_ranges) + P1_REG_DESC(BUCK, buck, _n, "vin", 0x47, BUCK_MASK, 255, p1_buck_ranges)#define P1_ALDO_DESC (_n) \ - P1_REG_DESC(ALDO, aldo, _n, "vin", 0x5b, LDO_MASK, 117, p1_ldo_ranges) + P1_REG_DESC(ALDO, aldo, _n, "vin", 0x5b, LDO_MASK, 128, p1_ldo_ranges)#define P1_DLDO_DESC (_n) \ - P1_REG_DESC(DLDO, dldo, _n, "buck5", 0x67, LDO_MASK, 117, p1_ldo_ranges) + P1_REG_DESC(DLDO, dldo, _n, "buck5", 0x67, LDO_MASK, 128, p1_ldo_ranges)static const struct regulator_desc p1_regulator_desc[] = {P1_BUCK_DESC (1 ),
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 165/175 spi: tegra210-quad: Return IRQ_HANDLED when timeout already processed transfer
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit aabd8ea0aa253d40cf5f20a609fc3d6f61e38299 ]
When the ISR thread wakes up late and finds that the timeout handler has already processed the transfer (curr_xfer is NULL), return IRQ_HANDLED instead of IRQ_NONE.
Use a similar approach to tegra_qspi_handle_timeout() by reading QSPI_TRANS_STATUS and checking the QSPI_RDY bit to determine if the hardware actually completed the transfer. If QSPI_RDY is set, the interrupt was legitimate and triggered by real hardware activity. The fact that the timeout path handled it first doesn't make it spurious. Returning IRQ_NONE incorrectly suggests the interrupt wasn't for this device, which can cause issues with shared interrupt lines and interrupt accounting.
--- drivers/spi/spi-tegra210-quad.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-)
drivers/spi/spi-tegra210-quad.c +17 -2
@@ -1488,15 +1488,30 @@ static irqreturn_t handle_dma_based_xfer(struct tegra_qspi *tqspi)static irqreturn_t tegra_qspi_isr_thread (int irq,void *context_data) {struct tegra_qspi *tqspi = context_data; +u32 status; + +/* +* Read transfer status to check if interrupt was triggered by transfer +* completion +*/ + status =tegra_qspi_readl (tqspi,QSPI_TRANS_STATUS );/* * Occasionally the IRQ thread takes a long time to wake up (usually * when the CPU that it's running on is excessively busy) and we have * already reached the timeout before and cleaned up the timed out * transfer. Avoid any processing in that case and bail out early. +* +* If no transfer is in progress, check if this was a real interrupt +* that the timeout handler already processed, or a spurious one. */ -if (!tqspi->curr_xfer) -return IRQ_NONE ; +if (!tqspi->curr_xfer) { +/* Spurious interrupt - transfer not ready */ +if (!(status &QSPI_RDY )) +return IRQ_NONE ; +/* Real interrupt, already handled by timeout path */ +return IRQ_HANDLED ; + } tqspi->status_reg =tegra_qspi_readl (tqspi,QSPI_FIFO_STATUS );
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 166/175 spi: tegra210-quad: Move curr_xfer read inside spinlock
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit ef13ba357656451d6371940d8414e3e271df97e3 ]
Move the assignment of the transfer pointer from curr_xfer inside the spinlock critical section in both handle_cpu_based_xfer() and handle_dma_based_xfer().
Previously, curr_xfer was read before acquiring the lock, creating a window where the timeout path could clear curr_xfer between reading it and using it. By moving the read inside the lock, the handlers are guaranteed to see a consistent value that cannot be modified by the timeout path.
--- drivers/spi/spi-tegra210-quad.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/spi/spi-tegra210-quad.c +4 -2
@@ -1376,10 +1376,11 @@ static int tegra_qspi_transfer_one_message(struct spi_controller *host,static irqreturn_t handle_cpu_based_xfer (struct tegra_qspi *tqspi) { -struct spi_transfer *t = tqspi->curr_xfer; +struct spi_transfer *t;unsigned long flags;spin_lock_irqsave (&tqspi->lock, flags); + t = tqspi->curr_xfer;if (tqspi->tx_status || tqspi->rx_status) {tegra_qspi_handle_error (tqspi);
@@ -1410,7 +1411,7 @@ static irqreturn_t handle_cpu_based_xfer(struct tegra_qspi *tqspi)static irqreturn_t handle_dma_based_xfer (struct tegra_qspi *tqspi) { -struct spi_transfer *t = tqspi->curr_xfer; +struct spi_transfer *t;unsigned int total_fifo_words;unsigned long flags;long wait_status;
@@ -1449,6 +1450,7 @@ static irqreturn_t handle_dma_based_xfer(struct tegra_qspi *tqspi) }spin_lock_irqsave (&tqspi->lock, flags); + t = tqspi->curr_xfer;if (num_errors) {tegra_qspi_dma_unmap_xfer (tqspi, t);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 167/175 spi: tegra210-quad: Protect curr_xfer assignment in tegra_qspi_setup_transfer_one
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit f5a4d7f5e32ba163cff893493ec1cbb0fd2fb0d5 ]
When the timeout handler processes a completed transfer and signals completion, the transfer thread can immediately set up the next transfer and assign curr_xfer to point to it.
If a delayed ISR from the previous transfer then runs, it checks if (!tqspi->curr_xfer) (currently without the lock also -- to be fixed soon) to detect stale interrupts, but this check passes because curr_xfer now points to the new transfer. The ISR then incorrectly processes the new transfer's context.
Protect the curr_xfer assignment with the spinlock to ensure the ISR either sees NULL (and bails out) or sees the new value only after the assignment is complete.
--- drivers/spi/spi-tegra210-quad.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/spi/spi-tegra210-quad.c +3 -0
@@ -839,6 +839,7 @@ static u32 tegra_qspi_setup_transfer_one(struct spi_device *spi, struct spi_tranu32 command1, command2, speed = t->speed_hz;u8 bits_per_word = t->bits_per_word;u32 tx_tap =0 , rx_tap =0 ; +unsigned long flags;int req_mode;if (!has_acpi_companion (tqspi->dev) && speed != tqspi->cur_speed) {
@@ -846,10 +847,12 @@ static u32 tegra_qspi_setup_transfer_one(struct spi_device *spi, struct spi_tran tqspi->cur_speed = speed; } +spin_lock_irqsave (&tqspi->lock, flags); tqspi->cur_pos =0 ; tqspi->cur_rx_pos =0 ; tqspi->cur_tx_pos =0 ; tqspi->curr_xfer = t; +spin_unlock_irqrestore (&tqspi->lock, flags);if (is_first_of_msg) {tegra_qspi_mask_clear_irq (tqspi);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 168/175 spi: tegra210-quad: Protect curr_xfer in tegra_qspi_combined_seq_xfer
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit bf4528ab28e2bf112c3a2cdef44fd13f007781cd ]
The curr_xfer field is read by the IRQ handler without holding the lock to check if a transfer is in progress. When clearing curr_xfer in the combined sequence transfer loop, protect it with the spinlock to prevent a race with the interrupt handler.
Protect the curr_xfer clearing at the exit path of tegra_qspi_combined_seq_xfer() with the spinlock to prevent a race with the interrupt handler that reads this field.
Without this protection, the IRQ handler could read a partially updated curr_xfer value, leading to NULL pointer dereference or use-after-free.
--- drivers/spi/spi-tegra210-quad.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/spi/spi-tegra210-quad.c +5 -0
@@ -1089,6 +1089,7 @@ static int tegra_qspi_combined_seq_xfer(struct tegra_qspi *tqspi,u32 address_value =0 ;u32 cmd_config =0 , addr_config =0 ;u8 cmd_value =0 , val =0 ; +unsigned long flags;/* Enable Combined sequence mode */ val =tegra_qspi_readl (tqspi,QSPI_GLOBAL_CONFIG );
@@ -1207,13 +1208,17 @@ static int tegra_qspi_combined_seq_xfer(struct tegra_qspi *tqspi,tegra_qspi_transfer_end (spi);spi_transfer_delay_exec (xfer); } +spin_lock_irqsave (&tqspi->lock, flags); tqspi->curr_xfer =NULL ; +spin_unlock_irqrestore (&tqspi->lock, flags); transfer_phase++; } ret =0 ; exit: +spin_lock_irqsave (&tqspi->lock, flags); tqspi->curr_xfer =NULL ; +spin_unlock_irqrestore (&tqspi->lock, flags); msg->status = ret;return ret;
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 169/175 spi: tegra210-quad: Protect curr_xfer clearing in tegra_qspi_non_combined_seq_xfer
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit 6d7723e8161f3c3f14125557e19dd080e9d882be ]
Protect the curr_xfer clearing in tegra_qspi_non_combined_seq_xfer() with the spinlock to prevent a race with the interrupt handler that reads this field to check if a transfer is in progress.
--- drivers/spi/spi-tegra210-quad.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/spi/spi-tegra210-quad.c +3 -0
@@ -1231,6 +1231,7 @@ static int tegra_qspi_non_combined_seq_xfer(struct tegra_qspi *tqspi,struct spi_transfer *transfer;bool is_first_msg = true;int ret =0 , val =0 ; +unsigned long flags; msg->status =0 ; msg->actual_length =0 ;
@@ -1304,7 +1305,9 @@ static int tegra_qspi_non_combined_seq_xfer(struct tegra_qspi *tqspi, msg->actual_length += xfer->len + dummy_bytes; complete_xfer: +spin_lock_irqsave (&tqspi->lock, flags); tqspi->curr_xfer =NULL ; +spin_unlock_irqrestore (&tqspi->lock, flags);if (ret <0 ) {tegra_qspi_transfer_end (spi);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 170/175 spi: tegra210-quad: Protect curr_xfer check in IRQ handler
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Breno Leitao <[email protected]>
[ Upstream commit edf9088b6e1d6d88982db7eb5e736a0e4fbcc09e ]
Now that all other accesses to curr_xfer are done under the lock, protect the curr_xfer NULL check in tegra_qspi_isr_thread() with the spinlock. Without this protection, the following race can occur:
CPU0 (ISR thread) CPU1 (timeout path)
---------------- -------------------
if (!tqspi->curr_xfer)
// sees non-NULL
spin_lock()
tqspi->curr_xfer = NULL
spin_unlock()
handle_*_xfer()
spin_lock()
t = tqspi->curr_xfer // NULL!
... t->len ... // NULL dereference!With this patch, all curr_xfer accesses are now properly synchronized.
Although all accesses to curr_xfer are done under the lock, in tegra_qspi_isr_thread() it checks for NULL, releases the lock and reacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer(). There is a potential for an update in between, which could cause a NULL pointer dereference.
To handle this, add a NULL check inside the handlers after acquiring the lock. This ensures that if the timeout path has already cleared curr_xfer, the handler will safely return without dereferencing the NULL pointer.
--- drivers/spi/spi-tegra210-quad.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
drivers/spi/spi-tegra210-quad.c +20 -0
@@ -1393,6 +1393,11 @@ static irqreturn_t handle_cpu_based_xfer(struct tegra_qspi *tqspi)spin_lock_irqsave (&tqspi->lock, flags); t = tqspi->curr_xfer; +if (!t) { +spin_unlock_irqrestore (&tqspi->lock, flags); +return IRQ_HANDLED ; + } +if (tqspi->tx_status || tqspi->rx_status) {tegra_qspi_handle_error (tqspi);complete (&tqspi->xfer_completion);
@@ -1463,6 +1468,11 @@ static irqreturn_t handle_dma_based_xfer(struct tegra_qspi *tqspi)spin_lock_irqsave (&tqspi->lock, flags); t = tqspi->curr_xfer; +if (!t) { +spin_unlock_irqrestore (&tqspi->lock, flags); +return IRQ_HANDLED ; + } +if (num_errors) {tegra_qspi_dma_unmap_xfer (tqspi, t);tegra_qspi_handle_error (tqspi);
@@ -1501,6 +1511,7 @@ static irqreturn_t handle_dma_based_xfer(struct tegra_qspi *tqspi)static irqreturn_t tegra_qspi_isr_thread (int irq,void *context_data) {struct tegra_qspi *tqspi = context_data; +unsigned long flags;u32 status;/*
@@ -1518,7 +1529,9 @@ static irqreturn_t tegra_qspi_isr_thread(int irq, void *context_data)* If no transfer is in progress, check if this was a real interrupt * that the timeout handler already processed, or a spurious one. */ +spin_lock_irqsave (&tqspi->lock, flags);if (!tqspi->curr_xfer) { +spin_unlock_irqrestore (&tqspi->lock, flags);/* Spurious interrupt - transfer not ready */ if (!(status &QSPI_RDY ))return IRQ_NONE ;
@@ -1535,7 +1548,14 @@ static irqreturn_t tegra_qspi_isr_thread(int irq, void *context_data) tqspi->rx_status = tqspi->status_reg & (QSPI_RX_FIFO_OVF |QSPI_RX_FIFO_UNF );tegra_qspi_mask_clear_irq (tqspi); +spin_unlock_irqrestore (&tqspi->lock, flags); +/* +* Lock is released here but handlers safely re-check curr_xfer under +* lock before dereferencing. +* DMA handler also needs to sleep in wait_for_completion_*(), which +* cannot be done while holding spinlock. +*/ if (!tqspi->is_curr_dma_xfer)return handle_cpu_based_xfer (tqspi);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 171/175 spi: tegra: Fix a memory leak in tegra_slink_probe()
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Felix Gu <[email protected]>
[ Upstream commit 41d9a6795b95d6ea28439ac1e9ce8c95bbca20fc ]
In tegra_slink_probe(), when platform_get_irq() fails, it directly returns from the function with an error code, which causes a memory leak.
Replace it with a goto label to ensure proper cleanup.
--- drivers/spi/spi-tegra20-slink.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/spi/spi-tegra20-slink.c +4 -2
@@ -1086,8 +1086,10 @@ static int tegra_slink_probe(struct platform_device *pdev)reset_control_deassert (tspi->rst); spi_irq =platform_get_irq (pdev,0 ); -if (spi_irq <0 ) -return spi_irq; +if (spi_irq <0 ) { + ret = spi_irq; + goto exit_pm_put; + } tspi->irq = spi_irq; ret = request_threaded_irq(tspi->irq, tegra_slink_isr, tegra_slink_isr_thread, IRQF_ONESHOT,
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 172/175 spi: tegra114: Preserve SPI mode bits in def_command1_reg
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vishwaroop A <[email protected]>
[ Upstream commit a0a75b40c919b9f6d3a0b6c978e6ccf344c1be5a ]
The COMMAND1 register bits [29:28] set the SPI mode, which controls the clock idle level. When a transfer ends, tegra_spi_transfer_end() writes def_command1_reg back to restore the default state, but this register value currently lacks the mode bits. This results in the clock always being configured as idle low, breaking devices that need it high.
Fix this by storing the mode bits in def_command1_reg during setup, to prevent this field from always being cleared.
--- drivers/spi/spi-tegra114.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/spi/spi-tegra114.c +3 -0
@@ -978,11 +978,14 @@ static int tegra_spi_setup(struct spi_device *spi)if (spi_get_csgpiod (spi,0 ))gpiod_set_value (spi_get_csgpiod (spi,0 ),0 ); +/* Update default register to include CS polarity and SPI mode */ val = tspi->def_command1_reg;if (spi->mode &SPI_CS_HIGH ) val &= ~SPI_CS_POL_INACTIVE (spi_get_chipselect (spi,0 ));else val |=SPI_CS_POL_INACTIVE (spi_get_chipselect (spi,0 )); + val &= ~SPI_CONTROL_MODE_MASK ; + val |=SPI_MODE_SEL (spi->mode &0x3 ); tspi->def_command1_reg = val;tegra_spi_writel (tspi, tspi->def_command1_reg,SPI_COMMAND1 );spin_unlock_irqrestore (&tspi->lock, flags);
Signature · 1 line
2.51.0
Greg Kroah-Hartman
maintainerPATCH 173/175 ALSA: hda/realtek: Really fix headset mic for TongFang X6AR55xU.
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Werner Sembach <[email protected]>
commit 1aaedafb21f38cb872d44f7608b4828a1e14e795 upstream.
Add a PCI quirk to enable microphone detection on the headphone jack of TongFang X6AR55xU devices.
The former quirk entry did not acomplish this and is removed.
--- sound/hda/codecs/realtek/alc269.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
sound/hda/codecs/realtek/alc269.c +1 -4
@@ -7232,6 +7232,7 @@ static const struct hda_quirk alc269_fixSND_PCI_QUIRK (0x1d05 ,0x1409 ,"TongFang GMxIXxx" ,ALC2XX_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1d05 ,0x300f ,"TongFang X6AR5xxY" ,ALC2XX_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1d05 ,0x3019 ,"TongFang X6FR5xxY" ,ALC2XX_FIXUP_HEADSET_MIC ), +SND_PCI_QUIRK (0x1d05 ,0x3031 ,"TongFang X6AR55xU" ,ALC2XX_FIXUP_HEADSET_MIC ),SND_PCI_QUIRK (0x1d17 ,0x3288 ,"Haier Boyue G42" ,ALC269VC_FIXUP_ACER_VCOPPERBOX_PINS ),SND_PCI_QUIRK (0x1d72 ,0x1602 ,"RedmiBook" ,ALC255_FIXUP_XIAOMI_HEADSET_MIC ), SND_PCI_QUIRK(0x1d72, 0x1701, "XiaomiNotebook Pro", ALC298_FIXUP_DELL1_MIC_NO_PRESENCE),
@@ -7701,10 +7702,6 @@ static const struct snd_hda_pin_quirk al {0x12, 0x90a60140}, {0x19, 0x04a11030}, {0x21, 0x04211020}), - SND_HDA_PIN_QUIRK(0x10ec0274, 0x1d05, "TongFang", ALC274_FIXUP_HP_HEADSET_MIC, - {0x17, 0x90170110}, - {0x19, 0x03a11030}, - {0x21, 0x03211020}), SND_HDA_PIN_QUIRK(0x10ec0282, 0x1025, "Acer", ALC282_FIXUP_ACER_DISABLE_LINEOUT, ALC282_STANDARD_PINS, {0x12, 0x90a609c0},
Greg Kroah-Hartman
maintainerPATCH 174/175 ALSA: usb-audio: Use the right limit for PCM OOB check
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 70b4db7d258118a7464f039112a74ddb49a95b06 upstream.
The recent fix commit for addressing the OOB access of PCM URB data buffer caused a regression on Behringer UMC2020HD device, resulting in choppy sound. The fix used ep->max_urb_frames for the upper limit check, and this is no right value to be referred.
Use the actual buffer size (ctx->buffer_size) as the upper limit instead, which also avoids the regression on the device above.
--- sound/usb/pcm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/usb/pcm.c +2 -1
@@ -1553,7 +1553,8 @@ static int prepare_playback_urb(struct sfor (i =0 ; i < ctx->packets; i++) { counts =snd_usb_endpoint_next_packet_size (ep, ctx, i, avail); -if (counts <0 || frames + counts >= ep->max_urb_frames) +if (counts <0 || + (frames + counts) * stride > ctx->buffer_size)break ;/* set up descriptor */ urb->iso_frame_desc[i].offset = frames * stride;
Greg Kroah-Hartman
maintainerPATCH 175/175 riscv: Add intermediate cast to unsigned long in __get_user_asm
In reply to Greg Kroah-Hartman6.18-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nathan Chancellor <[email protected]>
commit 841e47d56cef9b96fd2314220e3d0f1d92c719f4 upstream.
After commit bdce162f2e57 ("riscv: Use 64-bit variable for output in __get_user_asm"), there is a warning when building for 32-bit RISC-V:
In file included from include/linux/uaccess.h:13,
from include/linux/sched/task.h:13,
from include/linux/sched/signal.h:9,
from include/linux/rcuwait.h:6,
from include/linux/mm.h:36,
from include/linux/migrate.h:5,
from mm/migrate.c:16:
mm/migrate.c: In function 'do_pages_move':
arch/riscv/include/asm/uaccess.h:115:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
115 | (x) = (__typeof__(x))__tmp; \
| ^
arch/riscv/include/asm/uaccess.h:198:17: note: in expansion of macro '__get_user_asm'
198 | __get_user_asm("lb", (x), __gu_ptr, label); \
| ^~~~~~~~~~~~~~
arch/riscv/include/asm/uaccess.h:218:9: note: in expansion of macro '__get_user_nocheck'
218 | __get_user_nocheck(x, ptr, __gu_failed); \
| ^~~~~~~~~~~~~~~~~~
arch/riscv/include/asm/uaccess.h:255:9: note: in expansion of macro '__get_user_error'
255 | __get_user_error(__gu_val, __gu_ptr, __gu_err); \
| ^~~~~~~~~~~~~~~~
arch/riscv/include/asm/uaccess.h:285:17: note: in expansion of macro '__get_user'
285 | __get_user((x), __p) : \
| ^~~~~~~~~~ mm/migrate.c:2358:29: note: in expansion of macro 'get_user'
2358 | if (get_user(p, pages + i))
| ^~~~~~~~
Add an intermediate cast to 'unsigned long', which is guaranteed to be the same width as a pointer, before the cast to the type of the output variable to clear up the warning.
--- arch/riscv/include/asm/uaccess.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/riscv/include/asm/uaccess.h +1 -1
@@ -112,7 +112,7 @@ do { \ _ASM_EXTABLE_UACCESS_ERR(1b, %l2, %0) \ : "=&r" (__tmp) \ : "m" (*(ptr)) : : label); \ - (x) = (__typeof__(x))__tmp; \ + (x) = (__typeof__(x))(unsigned long)__tmp; \ } while (0) #else /* !CONFIG_CC_HAS_ASM_GOTO_OUTPUT */ #define __get_user_asm(insn, x, ptr, label) \
Hi
no regressions here on x86_64 (Intel 11th Gen. CPU)
Thanks
Luna Jernberg
Tested-byTested on: Arch Linux Machine a Dell Micro 3050 with a
model name : Intel(R) Core(TM) i5-6500T CPU @ 2.50GHz
and works as it should
Den mån 9 feb. 2026 kl 18:25 skrev Ronald Warsow <[email protected]>:
Quoted 9 lines
Hi
no regressions here on
x86_64(Intel 11th Gen. CPU)Thanks
Tested-by Ronald Warsow <[email protected]>
# Librecast Test Results
020/020 [ OK ] liblcrq
010/010 [ OK ] libmld
120/120 [ OK ] liblibrecast
CPU/kernel: Linux auntie 6.18.10-rc1-g0aa40b8da17f #1 SMP PREEMPT_DYNAMIC Mon Feb 9 17:57:43 -00 2026 x86_64 AMD Ryzen 9 9950X 16-Core Processor AuthenticAMD GNU/Linux
Am 09.02.2026 um 15:21 schrieb Greg Kroah-Hartman:
Quoted 4 lines
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Builds, boots and works on my 2-socket Ivy Bridge Xeon E5-2697 v2 server. No dmesg oddities or regressions found.
Beste Grüße,
Peter Schneider
Signature · 8 lines
Climb the mountain not to plant your flag, but to embrace the challenge, enjoy the air and behold the view. Climb it so you can see the world, not so the world can see you. -- David McCullough Jr. OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244 Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc https://keys.mailvelope.com/pks/lookup?op=get&[email protected] https://keys.mailvelope.com/pks/lookup?op=get&[email protected]
The kernel, bpf tool, perf tool, and kselftest builds fine for v6.18.10-rc1 on x86 and arm64 Azure VM.
Thanks,
Hardik
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v6.18:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
133 tests: 133 pass, 0 failLinux version: 6.18.10-rc1-g0aa40b8da17f
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra186-p3509-0000+p3636-0001, tegra194-p2972-0000,
tegra194-p3509-0000+p3668-0000, tegra20-ventana,
tegra210-p2371-2180, tegra210-p3450-0000,
tegra30-cardhu-a04Jon
Hi Greg
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
6.18.10-rc1 tested.
Build successfully completed.
Boot successfully completed.
No dmesg regressions.
Video output normal.
Sound output normal.
Lenovo ThinkPad X1 Carbon Gen10(Intel i7-1260P(x86_64) arch linux)
[ 0.000000] Linux version 6.18.10-rc1rv-g0aa40b8da17f
(takeshi@ThinkPadX1Gen10J0764) (gcc (GCC) 15.2.1 20260103, GNU ld (GNU Binutils) 2.45.1) #1 SMP PREEMPT_DYNAMIC Tue Feb 10 07:52:43 JST 2026
Thanks
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
hello
dmesg stuff's ... ------------------------error----------------------------
[ 21.307326] lp lp.0: really_probe: driver_sysfs_add failed [ 21.309030] kobject: kobject_add_internal failed for lp0 (error: -2
parent: printer) ------------------------error---------------------------- I DO NOT HAVE A PRINTER
--------------------------info----------------------------
[ 64.066312] traps: wireplumber[1335] general protection fault
ip:7fa9701d14c2 sp:7ffec89aa4f0 error:0 in libgobject-2.0.so.0.8600.3[174c2,7fa9701ca000+36000] --------------------------info------------------------------
my gnome-terminal (VT) stopped during compilation.
i forgot to get screenshot (sorry). i started a fresh new terminal
and did sync and then re-compilation continued typically normal.
--
software engineer
rajagiri school of engineering and technology-
Greg Kroah-Hartman
maintainerQuoted 9 lines · Jeffrin Thalakkottoor
hello
dmesg stuff's ... ------------------------error----------------------------
[ 21.307326] lp lp.0: really_probe: driver_sysfs_add failed [ 21.309030] kobject: kobject_add_internal failed for lp0 (error: -2parent: printer) ------------------------error---------------------------- I DO NOT HAVE A PRINTER
That's good, finding one here would mean that there was a problem :)
Why did you load/build this driver into the kernel? Any other lp messages or drivers loaded?
thanks,
greg k-h
Jeffrin Thalakkottoor
Tested-byQuoted 6 lines · Greg Kroah-Hartman
On Tue, Feb 10, 2026 at 08:34:53PM +0530, Jeffrin Thalakkottoor wrote:
That's good, finding one here would mean that there was a problem :)Why did you load/build this driver into the kernel?
i did not load it manually . May be it came through "make localmodconfig"
Quoted 1 line
Any other lp messages or drivers loaded?
---------------screenshot-------------------------- $lsmod | grep lp
lp 36864 0 parport 81920 3 parport_pc,lp,ppdev
-----------------screenshot-------------------------
--
software engineer
rajagiri school of engineering and technology-
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 15 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.
Quoted 5 lines
thanks,
greg k-h
-------------
build and boot report for Linux 6.18.10-rc1.
The kernel was built and booted successfully on both arm64 and x86_64 architectures using the defconfig. Testing was performed in virtual environments,
and the system ran as expected.
No dmesg regressions were found during testing.
Build details:
Architectures: arm64, x86_64
Kernel version: 6.18.10
Configuration: defconfig
Source: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: 0aa40b8da17f82a0c1a41b57be6e920434a2a78d
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
test_progs, test_progs-no_alu32, test_progs-cpuv4, test_maps, test_verifier in BPF selftests all passes[1] on x86_64.
1: https://github.com/shunghsiyu/libbpf/actions/runs/21880634049/job/63161819185
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.18.10-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.18.y
and the diffstat can be found below.thanks,
greg k-h
Tested on my amd64 DIY home NAS. (Also lightly tested on my ThinkPad T14 Gen 1.) Working well, no regressions observed.
Signature · 1 line
-Barry K. Nathan <[email protected]>
Quoted 8 lines · On Mon, 09 Feb 2026 15:21:13 +0100 Greg Kroah-Hartman…
This is the start of the stable review cycle for the 6.18.10 release. There are 175 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 11 Feb 2026 14:22:44 +0000. Anything received after that time might be too late.
Boot-tested under QEMU for Rust x86_64, arm64 and riscv64; built-tested for loongarch64:
Thanks!
Cheers,
Miguel