On 1/7/16, Paul Goyette <p...@whooppee.com> 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 | > +------------------+--------------------------+------------------------+ >