All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.