On 05/10/2017 01:17 PM, Timur Tabi wrote: > On 05/09/2017 02:06 PM, Florian Fainelli wrote: >> On 05/09/2017 11:51 AM, Timur Tabi wrote: > >>> Is it possible that the network stack detects a kexec and automatically >>> stops all network devices? >> >> No. why would it? However the device driver model does call into your >> driver's remove function and that one does a right job already because >> it does an network device unregister, and so on. > > I ran some more tests. When I launch kexec, the driver's > net_device_ops.ndo_stop function is called, which already stops the interface. > > So it looks to me as if the network stack does close the interface during a > kexec. With the interface closed, there's no point in having a shutdown > function, is there?
AFAIR kexec takes care of shutting down network devices explicitly (unless instructed otherwise with -x/--no-ifdown) so this may be where this is coming from. Reading through drivers/base/core.c it does not appear that ->remove() is called and then ->shutdown() gets called, only ->shutdown() gets called from device_shutdown() called from kernel/reboot.c. It seems to me like if you want to be on the safe side you would want to implement a shutdown function that is identical to what your remove function does. > >>> My in-house driver stops the RX and TX queues. I'm guessing that's good >>> enough, but I don't have a failing test case to prove it. >>> >> >> That's probably good enough, yes. > > Except that it turns out that the queues are already stopped by then because > the emac_close() function has already been called. -- Florian
