Re: In-kernel process exit hooks?

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

   Date: Thu, 7 Jan 2016 08:08:56 +0800 (PHT)
   From: Paul Goyette <paul%vps1.whooppee.com@localhost>

   On Wed, 6 Jan 2016, Taylor R Campbell wrote:

   > Another possibility would be to change filemon(4) to do fd_getfile
   > each it needs to use the file descriptor.  This makes it a little more
   > brittle (fails if you close the descriptor), but would sidestep the
   > problem.

   Hmmm, perhaps.  Failure would not be a problem, since we would just 
   revert to the initial "output file unspecified" conditions.

   I think I like this approach.  :)  I'll give it a try.

Is it supposed to monitor file activity past a fork and exec and
recursively through all subprocesses, or is it supposed to apply only
to the current process?

If it's supposed to work across fork/exec/&c., then this won't work --
but neither will the current approach!  I think fd_putfile will just
close whatever random descriptor happens to be in that slot, which may
be unrelated if userland (perhaps in some deeply nested child) did
dup2.

   > Another possibility would be to use fd_getfile2/closef, which holds a
   > reference only on the file, instead of fd_getfile/fd_putfile, which
   > holds a reference on the file and on the descriptor.  Releasing the
   > reference to the file may not a problem, even though releasing the
   > reference to the descriptor is a problem as you found.

   Would this prevent the file descriptor from being closed behind our 
   backs?

The descriptor could be closed but the file will persist.