Date: Thu, 26 Nov 2015 01:23:44 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Fabien Thomas <fabient@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r291301 - head/sys/netinet Message-ID: <20151125222344.GP44598@FreeBSD.org> In-Reply-To: <201511251445.tAPEjilx016268@repo.freebsd.org> References: <201511251445.tAPEjilx016268@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.poupon@stormshield.eu F> Reviewed by: gleb@ Note that gleb@FreeBSD.org and glebius@FreeBSD.org are two different persons. -- Totus tuus, Glebius.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151125222344.GP44598>