Date: Wed, 10 Jan 2007 16:24:50 +0100 (CET) From: "Max Laier" <max@love2party.net> To: "Robert Watson" <rwatson@FreeBSD.org> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, Randall Stewart <rrs@cisco.com>, freebsd-current@freebsd.org Subject: Re: Witness warning with SCTP Message-ID: <63156.141.3.136.211.1168442690.squirrel@mlaier.homeunix.org> In-Reply-To: <20070110150617.R52843@fledge.watson.org> References: <20070107171034.GA13836@crodrigues.org> <45A139CF.3090909@cisco.com> <20070107185228.W41371@fledge.watson.org> <200701091426.36740.jhb@freebsd.org> <20070110142100.G52843@fledge.watson.org> <45A4FBF9.3040806@cisco.com> <20070110150617.R52843@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am Mi, 10.01.2007, 16:07, schrieb Robert Watson: > On Wed, 10 Jan 2007, Randall Stewart wrote: > >>>> Either that or use an sx lock to close the pcb alloc race instead and >>>> don't hold mutexes while calling hashinit(). >>> >>> I think this is a good point -- I've generally been restructuring PCB >>> init >>> functions so that they perform allocation up front before acquiring >>> locks >>> in order to reduce lock contention on the table locks, which are global >>> and >>> acquired in many other paths. This tends to simplify error handling >>> also. >>> I'm not sure how well that applies in this case, however. Certainly, >>> we >>> want to optimize for successful handling, since malloc(9) failure is >>> very >>> unusual and occurs only in very exceptional (and unfortunate) cases. A >>> more likely failure is the exhaustion of the zone limit on the pcb >>> zone, >>> which gates the overall allocation of memory for the socket type, and >>> should be the first memory type allocated when setting up pcbs for this >>> reason. >> >> There are checks way up front on getting the pcb memory... >> >> I don't think I would want to convert these to sx_locks since according >> to >> the manual page : >> >> " Shared/exclusive locks are used to protect data that are read far more >> often than they are written. Mutexes are inherently more efficient than >> shared/exclusive locks, so shared/exclusive locks should be used pru- >> dently. " >> >> And the lock in question is used a lot... (protecting the pcb).. >> >> Hmm.. maybe I can restructure things to pre-alloc the memory before the >> locks.. > > As a general rule, sx locks are not appropriate for use in the "in-bound" > portions of the network stack, although the sleeping socket locks > serializing > socket I/O operations in socket consumers are functionally similar. > Normally > only mutexes and rwlocks should be used in low level bits of the stack, as > they may well be acquired in ithread or swi contexts where the unbounded > sleep > primitives used in sx locks are not appropriate. ... neither are malloc calls with M_WAITOK (which was the initial question in this thread). So in order to fix it, you can either change hashinit() to take a malloc flag, roll your own hashinit, or preallocate hash-space (though I doubt this last one is practical). -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63156.141.3.136.211.1168442690.squirrel>