On Mon, 7 Jul 2008, David Schultz wrote:

Does this happen even for non-last closes of all file types? Pipes are too simple :-).

Under FreeBSD, ordinary revoke(2) needs to do wake up all readers and synchronize with them (preferably without waiting for them), but it has never done this. The kernel has no mechanism for finding threads sleeping or doing i/o on an fd short of what fstat does (searching half of kmem for hints). Only a small amount of progress has been made in fixing this in the 20 years that revoke() has existed. Most of the necessary wakeups don't occur. A few occur accidentally. So it is normal for threads to be left active after revoke() completes, and the progress is mainly that the devfs and conf layers try harder to prevent deallocation of active data structures for devices in this state. The active threads may do some damage when they wake up with a closed or a new generation of open device, but usually don't. Tty drivers use a generation count to prevent some uses of new generations of opens, but don't check it in enough places. I haven't noticed any other class of drivers doing even this much. Since revoke() is used mainly on tty devices and the generation count almost works for these, these bugs are rarely noticed.

Bruce