From: Chih Kai Hsu <hsu.chih.kai@realtek.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
"kuba@kernel.org" <kuba@kernel.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
nic_swsd <nic_swsd@realtek.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"edumazet@google.com" <edumazet@google.com>,
"bjorn@mork.no" <bjorn@mork.no>,
"pabeni@redhat.com" <pabeni@redhat.com>
Subject: RE: [PATCH net-next] r8152: use GFP_NOIO during system suspend
Date: Tue, 11 Aug 2026 05:25:10 +0000 [thread overview]
Message-ID: <c2cabf10d22145bbb6a527e702b14b6d@realtek.com> (raw)
In-Reply-To: <918676ef-efcc-4524-a779-62eb2c3eb608@lunn.ch>
On Mon, Aug 11, 2026 at 02:03 AM +0800, Andrew Lunn wrote:
> 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?
>
It is theoretical.
> > @@ -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?
I found https://elixir.bootlin.com/linux/v7.2-rc6/source/drivers/base/power/main.c#L2343
in the Linux source code.
pm_restrict_gfp_mask() is called before dpm_suspend(state). It removes __GFP_IO
and __GFP_FS from the global gfp_t gfp_allowed_mask. Therefore, I think the driver
can use GFP_KERNEL safely. Is this correct? Could you please provide any advice?
>
> Andrew
Best,
Chih-Kai
prev parent reply other threads:[~2026-08-11 5:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-10 6:57 [PATCH net-next] r8152: use GFP_NOIO during system suspend Chih Kai Hsu
2026-08-10 18:03 ` Andrew Lunn
2026-08-11 5:25 ` Chih Kai Hsu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c2cabf10d22145bbb6a527e702b14b6d@realtek.com \
--to=hsu.chih.kai@realtek.com \
--cc=andrew@lunn.ch \
--cc=bjorn@mork.no \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox