Re: Witness warning with SCTP

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_at_freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier_at_EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News