From owner-freebsd-current  Thu Apr 25 23:13:53 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA12012
          for current-outgoing; Thu, 25 Apr 1996 23:13:53 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id XAA12004
          for <current@freebsd.org>; Thu, 25 Apr 1996 23:13:41 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id QAA28569 for current@freebsd.org; Fri, 26 Apr 1996 16:10:45 +1000
Date: Fri, 26 Apr 1996 16:10:45 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199604260610.QAA28569@godzilla.zeta.org.au>
To: current@freebsd.org
Subject: fixing FSETOWN/SIGIO
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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