Date: Fri, 26 Apr 1996 16:10:45 +1000 From: Bruce Evans <bde@zeta.org.au> To: current@freebsd.org Subject: fixing FSETOWN/SIGIO Message-ID: <199604260610.QAA28569@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
FSETOWN/SIGIO has many bugs. I knew about the following ones yesterday: 1. FSETOWN on ttys interacts badly with POSIX process groups (see an old discussion). 2. FSETOWN on sockets allows sending SIGIO to any processes. I found some more while looking at something else (stat()) for pipes: 3. FSETOWN on pipes is a no-op. The SIGIO handling got lost when pipes were reimplemented as non-sockets. 4. FSETOWN on everything except sockets only works for right for process group ids. Process ids get converted to (positive) process group ids. Negative process group ids also get converted to positive process group ids, so there is no way to tell whether the resulting pgid was for a process. 5. The conversions in (4) break /dev/klog. logwakeup() expects process group ids to be negative and attempts to support process ids. 6. /dev/bpf and /dev/tun are aware of the negations in (4) (see comments in bpf.c) but aren't aware that the process id case is too broken to recover from. 7. The pipe pgid isn't initialized. 8. The /dev/klog pgid is initialized to the process id (a state that can only be reached for process group leaders via FSETOWN, because of (4)). 9. Socket, bpf and tun pgids seem to be initialized to 0. NO_PID would be better since kernel processes have pid == pgid == 0 (this may be another bug). Some of these problems are worked around in the Linux emulator. The pipe problems are new and the Linux emulator doesn't seem to know about them. Fixes: 1. Later. 2. I can't think of anything better than checking the pid or pgid using CANSIGNAL() when FSETOWN is called. This seems obvious, so why isn't it already done? Checking the signaler's pid when the signal is about to be delivered is no good because I/O is not attached to a process - it's asynchronous. The process that requested it may be long dead. 3. Fixed by cloning some simple socket code. 4. Pass the data straight through to the TIOCSPGRP ioctl. 5. Fixed by fix for (4). 6. Remove negations. 7. Fixed by initializing pgid to NO_PID. However, perhaps it should be initialized to the process id. 8. Not a bug. 9. Same as (7). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604260610.QAA28569>