On 30 Sep, Juli Mallett wrote:
> * De: Don Lewis <[EMAIL PROTECTED]> [ Data: 2002-09-30 ]
>> I suggest looking especially closely at the sigio stuff. Even the old
>> code has a lock order reversal problem when I/O to a pipe wants to
>> signal the process at the other end of the pipe. I thought a lot about
>> that problem and never found a clean fix.
>>
>> The sigio stuff could be even nastier if you need to allocate memory in
>> the signal code because the sigio can be invoked by the reception of a
>> packet from the network, which is not handled in a process context ...
>
> No locks except for the lock of the process being signalled should be
> held when sending signals, IMHO, though I am mostly ignorant of the SIGIO
> locking.
As I recall, the sigio code needs to hold a lock to prevent the sigio
structure from being ripped out from underneath it while it is sending a
signal to the target process or process group by any of:
An explicit fcntl(fd, F_SETOWN, ...) by the recpient process or a
member of its process group, or some other process that shares the
associated descriptor.
An implicit fcntl(fd, F_SETOWN, 0) caused by the descriptor being
closed.
The target process exiting.
The target process group disappearing because its last member is
exiting.
The pipe I/O code can call pgsigio() in various places while holding the
pipe lock. It looks to me like dropping the pipe lock could introduce
some race condition problems in the SMP case. In particular if we
dropped the lock to send the signal before calling msleep() to wait for
the process at the other end of the pipe to do some I/O, the I/O could
happen after we dropped the lock but before we went to sleep and we'd
never get woken up.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
