[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

sbruno added a comment. Should this be closed? REVISION DETAIL https://reviews.freebsd.org/D1777 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: rrs, imp, gnn, rwatson, lstewart, kib, adrian, jhb, bz, sbruno Cc: ae, bz, freebsd-net-list, emaste, hiren, ju

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

hiren added a comment. It all started with: https://lists.freebsd.org/pipermail/freebsd-net/2014-September/039730.html Last (conclusive) email in that thread: https://lists.freebsd.org/pipermail/freebsd-net/2015-January/040895.html That issue was fixed by: https://reviews.freebsd.org/D1438 i.e.

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

hiren added a comment. >>! In D1777#16, @bz wrote: > Hiren, it only took us 4 years to trigger this? Can people actually > easily/reliably reproduce it? Heh, I am not sure about "people" but we @llnw can see this very reliably. Do you have any other theories/patches that we can try? It'd be he

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

hiren added a comment. Update from llnw world: Things have been pretty stable here without any panics for 24+ hours with Stable10+D1711+D1777. Thanks a lot, Randall! REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

rrs added a comment. Jhb/Others So lets go through your scenario with code in arp: a) softclock dequeues callout to run -- Which calls softclock_call_cc We make it to line:676 and see that "yes" the user (arp) init'd with a rw_mtx and run the next line 677 (to get the lock). b) othe

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

rrs added a comment. Adrian: I know he said callout_drain, but just like in TCP that is *not* always possible. In the case of the arp/nd6 code lock are held (same as TCP) so you can't do a callout_drain. Thats why the original author put ref-counting in with the idea that the timer would kill

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

rrs added a comment. Hmm thinking about your comment jhb, we could easily add the callout_drain_async to the current callout code. If you think its worth while maybe we should add that to D1711 Jhb, if you think its worth doing add that to D1711 and I will work on it ;-) REVISION DETAIL http

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

adrian added a comment. .. except he said callout_drain(). What happens if that's put in as part of the teardown process? REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, bz, jhb Cc: bz, emaste, hiren, julian, hselasky, freebsd

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

rrs added a comment. JHB: The scenario you outline is *exactly* the panic that was seen by sbruno. I guess my description was unclear. The existing code in that other thread right now does a callout_stop and tests the return code. If its one its one (which says I canceled a callout) then it l

[Differential] [Commented On] D1777: Associated fix for arp/nd6 timer usage.

rrs added a comment. I don't think this is a refcnt issue bz, the base of this is a hole in the way the callout code works. Basically there is a window when a) The callout_wheel is executing, it sees that a "lock" has been configured, so it goes to release the callout wheel lock and then lo