Date: Tue, 1 Oct 2002 00:30:04 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: jmallett@FreeBSD.ORG Cc: freebsd-current@FreeBSD.ORG Subject: Re: World broken at libkvm Message-ID: <200210010730.g917U4vU012350@gw.catspoiler.org> In-Reply-To: <20020930224942.A73940@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 Sep, Juli Mallett wrote: > * De: Don Lewis <dl-freebsd@catspoiler.org> [ 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200210010730.g917U4vU012350>