so_rcv_sx, deadlkres, SIGSTOP

[Attilio Rao]

2010/4/8 Attilio Rao <attilio at freebsd.org>:
> 2010/4/4 Jilles Tjoelker <jilles at stack.nl>:
>> The SX locks so_snd_sx and so_rcv_sx can be legitimately held for
>> arbitrary amounts of time, while waiting until a send or recv is
>> possible. Any other threads wanting to send/recv on the socket will
>> sleep interruptibly on the corresponding SX. If deadlkres is activated,
>> it may detect a deadlock even though there is no problem.
>>
>> If a SIGSTOP or similar comes in while waiting until send/recv is
>> possible, the SX is held across the suspension and noone will be able to
>> send/recv on the socket until the process is resumed. On the other hand
>> a thread waiting for the SX can be suspended without harm. Adding PBDRY
>> to various sleeps may help but may also introduce other problems
>> (SIGSTOP disturbing the functioning of the process more, possibly with
>> stuff like SO_RCVTIMEO).
>>
>> Example (using the fact that fifos are implemented using sockets):
>>
>> term1% mkfifo testfifo
>> term1% cat >testfifo
>>
>> term2% cat testfifo
>>
>> term3% cat testfifo
>>
>> Letting this sit for half an hour will trigger deadlkres.
>
> Jilles,
> may you please try this patch?:
> http://www.freebsd.org/~attilio/Sandvine/deadlkres/deadlkres-blessed.diff
>
> It does introduce a blessed list where the sx_lock can be whitelisted.
> It also fixes, for long sleeps, the wrap-up of ticks object.
> The obvious fallout is that deadlkres can't help much with deadlocks
> for whitelisted sxlock or lockmgr but that is a fair price I think.

Forgot to mention: mutex are left out from this design by purpose
because a similar problem might never happen for them by design.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein