Re: In-kernel process exit hooks?

[Paul Goyette <paul%whooppee.com@localhost>]

On Fri, 8 Jan 2016, Paul Goyette wrote:

> The saga continues!   :)
>
> <snip>
>
> Next, I'm going to have a look at fd_getfile2()/fclose() and see if that
> is a viable approach.

Hmmm.  The comments in kern/kern_descrip.c for fd_getfile2() require 
that the process is not allowed to fork or exit "across this call" 
(which I assume means "until the reference to the struct file is 
released").

I'm not sure how to prevent this.  I could probably re-use the exithook 
mechanism from the previous approach to handle the exit case, but how to 
prevent fork() is another beast entirely (I think).  And to make things 
worse, the example code in the filemon(4) man page explicitly calls 
fork().

I'm quickly running out of ideas here...  I'm strongly leaning towards 
leaving the code alone, and more clearly documenting the conditions 
under which the hang occurs (ie, closure of the activity-log fd prior to 
disassociated the activity-log from the /dev/filemon fd, whether the 
close is done explicitly or as part of the sequential close that occurs 
at process exit).

Someone (Martin@, I think) earlier suggested modifying things to use 
cv_timedwait() in fd_close(), and modifying fd_free() to retry.  This 
might help in the process exit scenario, but doesn't address the case 
where the application process explicitly closes the file with the extra 
reference.

It might also be possible to modify fd_close() to have a 
filemon-specific close routine, similar to what is currently being done 
for knote_fdclose().  But this seems rather heavy-handed for something 
that has such a limited use-case as filemon(4).

The only other approach I can think of is to modify filemon(4) so it 
does not directly write any data to the activity log.  Rather than 
having the application provide a log fd (on which the extra reference 
needs to be taken), the application would read(2) from the filemon fd 
and handle the "logging" itself.  This would mean two additional trips 
across the kernel/userland boundary for every event, which feels like a 
rather costly approach.  It would also mean modifying make(1) (the only 
"production" use-case for filemon(4)).


Any other suggestions would be appreciated.


+------------------+--------------------------+------------------------+
| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:      |
| (Retired)        | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com   |
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
+------------------+--------------------------+------------------------+