Lock of a process group, session, sigio and file descriptor

Patches and results of build test

• Latest: 01 Sep 2001 15:00 UTC

  • Notice
    • Alfred Perlstein has ripped off the filedesc part of the patch. For now, I am providing only the process group and session part of the patch.
  • Patch (gzipped)
  • Build test

    Architecture and build log (gzipped)	Kernel configuration	Machine	Test results
    			Compilation	Linking	Running
    i386	LINT	IBM ThinkPad 600E (i386)	OK	OK	Not tested
    i386	GENERIC		OK	OK	OK
    pc98	GENERIC		NG	NG	Not tested
    alpha	Not tested due to version mismatch of config(8) on beast.FreeBSD.org and -current.

• Old patches and test results

Works and issues on which my patch depends

• Ktrace(2) attempts to sleep with mutexes locked
  Spotted by: Alfred Perlstein
  A process calls ktrpsig() and ktrcsw() with some mutexes locked. As those functions call ktrwrite() which may sleep, use of ktrace(2) ends up with kenrel panic by WITNESS.
  BSD/OS solves this problem by a queue of ktrace data and a helper kernel thread. A ktrace queue of BSD/OS, namely struct ktrace_control, is per vnode of a trace file, allocated dynamically. A record of trace data, also dynamically allocated, attaches to the queue of a trace file first. A kernel thread forked in ktrace(2) pulls records out of the queue, followed by writing them to the vnode of the trace file.
  The queue also holds free records of ktrace data so that a process holding mutexes can call ktrace_*(),
  The solution of BSD/OS looks promising in general. The only one issue is that they do not allocate free records until the first call of ktrace_getxheader(). That would be fatal if a process holding mutexes records the first trace data for the queue. Since we only call ktrpsig() and ktrcsw() with holding mutexes, it should be sufficient to preallocate a certain number of KTR_PSIG and KTR_CSW records in ktrace(2).
  Update (16 Jul 2001): Jake Burkholder is now working on this task.
• Getvnode() should hold the vnode of a file descriptor.
  Spotted by: Alfred Perlstein
  In cases where we work on not a file descriptor but its vnode, we should hold the vnode to avoid bogus reference to the file descriptor.

Future works

• Lock of a tty
  A tty often interacts with a process group or a session to manage job control and login session. Namely, TIOCGPGRP, TIOCSPGRP, TIOCNOTTY and TIOCSCTTY ioctl(2)s read or modify the states of a process group or a session, thusly calling for locking both a terminal and a process group or a session.
  The interaction between a tty and a process group is mostly job control by sending a signal to a process group and switching the foreground process group, initiated by a tty. Hence a tty should be locked prior to a process group.
  We often read or modify a tty via a session to reach a foreground process group, to implement iBCS2 ioctl(2)s and so on. On the other hand, loss of carrier is the only one situation to read or modify a session via a tty. We should thus lock a session prior to a tty. Although this method seems somewhat kludge to attach or detach a controlling terminal to or from a session, we have a simple solution; ttioctl() firstly locks the session involved into the invoked ioctl(2) operation, followed by locking a tty.
  If a part of the kernel excepts to lock a tty and a process group or a session not in the order discussed above, it may be ecessary to add another lock like p_pgrpmtx to not break the lock order.
  
  
• New architectures
  How do I test my patch on powerpc?