Will the hang occur if make dies due to a signal (control-C, or kill -9, for example)?
--Terry > -----Original Message----- > From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On > Behalf Of Paul Goyette > Sent: Thursday, January 7, 2016 17:00 > To: Taylor R Campbell <campbell+netbsd-tech-k...@mumble.net> > Cc: tech-kern@netbsd.org > Subject: Re: In-kernel process exit hooks? > > 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 | > +------------------+--------------------------+------------------------+