Netdev List
 help / color / mirror / Atom feed
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

      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