Messages in this thread | | | Date | Tue, 9 Sep 2003 13:29:13 -0600 | From | hendriks@lanl ... | Subject | 2.4.21 -> 2.4.22 kernel thread oddities |
| |
The "unshare_files" addition to execve() is having some unexpected side effects for a funky init() program that I use on our clusters. Basically the problem is that standard-equipment type kernel threads (e.g. kupdated, bdflush) are ending up with open file descriptors on a file system that I wish to unmount.
As far as I can tell the following is going on:
Those kernel threads are started from process 1 before starting init. They are started with CLONE_FILES so they share a file table with init.
Right before init is started, the kernel does open("/dev/console"). The kernel threads end up with this in their file table because of the CLONE_FILES.
On Linux 2.4.22, execve("/sbin/init") causes the file table to be unshared which leaves no way of closing those file descriptors. This in turn, means I have no way to unmount the file system.
On Linux 2.4.21, the file table was still shared so closing the file descriptors in init, closed them for the threads as well and everything was fine.
A quick one line hack around this would be to "unshare_files" right before doing the open("/dev/console"). This doesn't strike me as being a particularly good answer.
It seems like kernel_threads should be responsible for cleaning up what they don't need with __exit_files() and so on.
- Erik
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |