[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f53b1ea0c733b58a242fd18a3e6c97a7b00ed01e.camel@kernel.org>
Date: Thu, 24 Sep 2020 11:16:57 -0700
From: Saeed Mahameed <saeed@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: David Miller <davem@...emloft.net>, hkallweit1@...il.com,
geert+renesas@...der.be, f.fainelli@...il.com, andrew@...n.ch,
gaku.inami.xh@...esas.com, yoshihiro.shimoda.uh@...esas.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Revert "net: linkwatch: add check for netdevice being
present to linkwatch_do_dev"
On Thu, 2020-09-24 at 09:03 -0700, Jakub Kicinski wrote:
> On Wed, 23 Sep 2020 22:49:37 -0700 Saeed Mahameed wrote:
> > 2) Another problematic scenario which i see is repeated in many
> > drivers:
> >
> > shutdown/suspend()
> > rtnl_lock()
> > netif_device_detach()//Mark !present;
> > stop()->carrier_off()->linkwatch_event()
> > // at this point device is still IFF_UP and !present
> > // due to the early detach above..
> > rtnl_unlock();
>
> Maybe we can solve this by providing drivers with a better helper for
> the suspend use case?
>
> AFAIU netif_device_detach() is used by both IO errors and drivers
> willingly detaching the device during normal operation (e.g. for
> suspend).
>
> Since the suspend path can sleep if we have a separate helper perhaps
> we could fire off the appropriate events synchronously, and
> quiescence
> the stack properly?
I was thinking something similar, a more heavy
weight netif_device_detach(), which will be used in all drivers suspend
flows.
1) clear IFF_UP
2) ndo_stop()
3) fire events
4) mark !present
...
5) suspend device
but went and sampled some drivers and found there are many variations
for using netif_device_detach it is not going to be a simple task.
Powered by blists - more mailing lists