Re: In-kernel process exit hooks?

[bch <brad.harder%gmail.com@localhost>]

On 1/7/16, Paul Goyette <paul%whooppee.com@localhost> wrote:
> 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)).

It adds a degree of complexity, but one could also have both
interfaces (i.e.: filemon(4) does the writing, or the app recv's the
data from filemon and does the writing.

> 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 |
> +------------------+--------------------------+------------------------+
>