Fabien, On Wed, Nov 25, 2015 at 02:45:44PM +0000, Fabien Thomas wrote: F> Author: fabient F> Date: Wed Nov 25 14:45:43 2015 F> New Revision: 291301 F> URL: https://svnweb.freebsd.org/changeset/base/291301 F> F> Log: F> The r241129 description was wrong that the scenario is possible F> only for read locks on pcbs. The same race can happen with write F> lock semantics as well. F> F> The race scenario: F> F> - Two threads (1 and 2) locate pcb with writer semantics (INPLOOKUP_WLOCKPCB) F> and do in_pcbref() on it. F> - 1 and 2 both drop the inp hash lock. F> - Another thread (3) grabs the inp hash lock. Then it runs in_pcbfree(), F> which wlocks the pcb. They must happen faster than 1 or 2 come INP_WLOCK()! F> - 1 and 2 congest in INP_WLOCK(). F> - 3 does in_pcbremlists(), drops hash lock, and runs in_pcbrele_wlocked(), F> which doesn't free the pcb due to two references on it. F> Then it unlocks the pcb. F> - 1 (or 2) gets wlock on the pcb, runs in_pcbrele_wlocked(), which doesn't F> report inp as freed, due to 2 (or 1) still helding extra reference on it. F> The thread tries to do smth with a disconnected pcb and crashes. F> F> Submitted by: emeric.pou...@stormshield.eu F> Reviewed by: gleb@
Note that g...@freebsd.org and gleb...@freebsd.org are two different persons. -- Totus tuus, Glebius. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"