On Mon, Jun 20, 2016 at 12:14:18PM +0200, Hans Petter Selasky wrote:
H> On 06/20/16 11:58, Gleb Smirnoff wrote:
H> > The fix I am working on now is doing exactly that. callout_reset must
H> > return 0 if the callout is currently running.
H> > What are the old paths impacted?
H> I'll dig into the matter aswell and give some comments. Thanks for the
H> analysis, Gleb.
H> FYI: This class of problems wouldn't exist if the callout could be
H> associated with a mutex!
Exactly! I am convinced that all callouts should be locked, and non-locked
one should simply go away, as well as async drain.
What does prevent us from converting TCP timeouts to locked? To my
understanding it is the lock order of taking pcbinfo after pcb lock.
I'm now trying to understand Julien's conversion from pcbinfo lock
to pcbinfo + pcblist locks. It seems to me that we actually can convert
TCP timers to locked callouts.
What for do we need pcbinfo read lock in a tcp timer? The timer works
only on the pcb and doesn't modify global lists, does it?
Totus tuus, Glebius.
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"