Date: Wed, 17 Aug 2005 04:35:19 +0200 From: Max Laier <max@love2party.net> To: Luigi Rizzo <rizzo@icir.org> Cc: arch@freebsd.org, net@freebsd.org Subject: Re: duplicate read/write locks in net/pfil.c and netinet/ip_fw2.c Message-ID: <200508170435.34688.max@love2party.net> In-Reply-To: <20050816170519.A74422@xorpc.icir.org> References: <20050816170519.A74422@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart1156185.pn3pmraMmZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 17 August 2005 02:05, Luigi Rizzo wrote: > [apologies for the cross post but it belongs both to arch and net.] > > I notice that net/pfil.c and netinet/ip_fw2.c have two copies of > aisimilar but slightly different implementation of > multiple-reader/single-writer locks, which brings up the question(s): > > 1. should we rather put this code in the generic kernel code so that other > subsystems could make use of it ? E.g. the routing table is certainly > a candidate, I have asked this several time on -arch and IRC, but never found anyone=20 willing to pursue it. However, the problem is ... > and especially > > 2. should we implement it right ? > > Both implementations are subject to starvation for the writers > (which is indeed a problem here, because we might want to modify > a ruleset and be prevented from doing it because of incoming traffic > that keeps readers active). > Also the PFIL_TRY_WLOCK will in fact be blocking if a writer > is already in - i have no idea how problematic is this in the > way it is actually used. =2E.. really this. I didn't find a clean way out of the starvation issue. = What=20 I do for pfil is that I set a flag and simply stop serving[2] shared reques= ts=20 once a writer waits for the lock. If a writer can't sleep[1] then we retur= n=20 EBUSY and don't. However, for pfil it's almost ever safe to assume that a= =20 write may sleep (as it is for most instances of this kind of sx-lock where= =20 you have BIGNUMxreads:1xwrite). [1] Note that there is a *big* difference between blocking and sleeping. =20 These two are usually confused. While it is almost always okay to block it= =20 is seldom okay to sleep. The existing sx(9) api has the problem that it=20 *sleeps* in the shared path which renders it unusable for this usecase (as = we=20 might be holding other locks and must not sleep in the shared path). =20 However, sleeping in the shared path is one (?the only?) way out of the=20 starvation problem - other than a problem specific as done for pfil. [2] See pfil(9) BUGS. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart1156185.pn3pmraMmZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDAqJ2XyyEoT62BG0RAgM9AJ4kzFxHhG6gUCKDFwfaxNL4NeprdACfSzoW X33PNJnt6EzhMiEntWkt79A= =Ce2y -----END PGP SIGNATURE----- --nextPart1156185.pn3pmraMmZ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200508170435.34688.max>