Re: [PATCH net-next] r8152: use GFP_NOIO during system suspend
From: Andrew Lunn <andrew@lunn.ch>
Date: 2026-08-10 18:03:27
Also in:
linux-usb, lkml
On Mon, Aug 10, 2026 at 02:57:41PM +0800, Chih Kai Hsu wrote:
During system suspend, memory allocation with GFP_KERNEL can block waiting for I/O to complete. If that I/O depends on a device that is itself suspended, a deadlock results. Introduce RTL8152_SYSTEM_SUSPEND flag to track when the driver is operating in the system suspend/resume context. Set the flag at the start of rtl8152_system_suspend() and clear it at the end of rtl8152_system_resume(), following the same pattern used by SELECTIVE_SUSPEND for runtime suspend. In get_registers() and set_registers(), select GFP_NOIO when the flag is set so that the kmalloc and kmemdup calls in those paths do not trigger I/O reclaim.
Do you have a reproducer for this? Or is it theoretical?
quoted hunk ↗ jump to hunk
@@ -8693,6 +8700,9 @@ static int rtl8152_system_resume(struct r8152 *tp) usb_submit_urb(tp->intr_urb, GFP_NOIO); } + clear_bit(RTL8152_SYSTEM_SUSPEND, &tp->flags); + smp_mb__after_atomic(); + return 0; }@@ -8758,6 +8768,9 @@ static int rtl8152_system_suspend(struct r8152 *tp) { struct net_device *netdev = tp->netdev; + set_bit(RTL8152_SYSTEM_SUSPEND, &tp->flags); + smp_mb__after_atomic(); + netif_device_detach(netdev); if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
It seems odd to me that every driver needs to track if it is in
suspend/resume or not. Doesn't the struct device tell you? Is there no
global state somewhere?
Andrew