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> > H> > What are the old paths impacted? H> H> Hi, H> H> I'll dig into the matter aswell and give some comments. Thanks for the H> analysis, Gleb. H> 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.Received on Mon Jun 20 2016 - 08:30:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC