On 12/12/15 00:26, Randall Stewart wrote:
Hans:
After talking with Gleb he tells me part of your test is to kldunload a module.
Now I think that is the source of the problem.
Probably the cleanup code failed to stop the timer and did the remove.. thus
when the timer expires it blows up.
This is not a callout issue.. I think you need to start looking at the cleanup
if you
want to pursue this.
Randall:
Our driver uses a pause of hz ticks to ensure resources are not used any
more, which on a fast machine might give exactly hz ticks between
ifattach and ifdetach. Is this a problem? What about tunX and tapX devices?
In think the right way to ensure races go away is to use Glebs initial
approach, because then there is no need to have a check for LLE_LINKED,
hence the callback is protected by a mutex, and will be atomically
stopped? And use callout_async_drain() when when freeing lle's. Like you
write in your previous e-mail, the value of callout_pending() can change
during the execution of the arptimer function, and even after the last
unlock in arptimer.
--HPS
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
