On 20/07/18(Fri) 14:32, Theo de Raadt wrote: > Martin Pieuchot <[email protected]> wrote: > > > On 20/07/18(Fri) 03:12, Mike Larkin wrote: > > > On Wed, Jul 18, 2018 at 11:34:41PM +0000, Romain wrote: > > > > > I'm wondering if this is due to the fact that we detach usb(4) > > > > > devices on > > > > > suspend. Looks like this may be trying to process a timeout that > > > > > corresponds > > > > > to a device that is no longer attached. Maybe the urtwn(4)? > > > > Well the device is detaching just after re-attaching. So it must be > > something different. But I agree with your assumption that it is > > related to urtwn(4). > > > > The problem seems to be a use-after-free of a timeout. The question is > > which timeout? Is it in urtwn(4)? In ic/rtwn.c? In the wireless stack? > > In the network stack? > > > > Our timeout_add(9) interface is simple but doesn't help to debug such > > issue. > > Is it a timeout not removed during detach?
That might be that or a timeout re-attached after being removed because there's a race somewhere... That's not the only place where we have such problem. If somebody has an idea or a floating diff to ease timeout debugging, that's the moment to speak (:
