Date: Fri, 8 Jan 2016 09:00:03 +0800 (PHT) From: Paul Goyette <p...@whooppee.com> Message-ID: <pine.neb.4.64.1601080819110.25...@pokey.whooppee.com>
| Any other suggestions would be appreciated. Another possibility would be to detach the logged-to file from the process when logging is enabled (making the ioctl that attaches it also be notionally a close from the process point of view). But keeping the reference in kernel. When logging is disabled (for whatever reason) do the kernel fd_close() at that point). Do this, and the process can no longer do an explicit close to cause a hang, and exit() won't close it in the normal sequence either, only closing the log (or detaching it from the fd) would close that file. That's also a change of filemon semantics, but I can't imagine that the application (make) really wants to be accessing the file while filemon is writing to it, does it? And if it did, it could always just explicitly open it again (though I haven't really thought through the effects of a dup() at this point - perhaps forbid ioctl'ing to a file that has a ref count > 1, so we know the fd is the only reference to it, once the ioctl "closes" it, a dup can't happen, obviously. Accessing the file via an independent open (before or after the ioctl) should not have any of these problems, that's a different struct file. kre