From: hendriks@lanl.gov
To: linux-kernel@vger.kernel.org
Subject: 2.4.21 -> 2.4.22 kernel thread oddities
Date: Tue, 9 Sep 2003 13:29:13 -0600 [thread overview]
Message-ID: <20030909192913.GE10623@lanl.gov> (raw)
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
next reply other threads:[~2003-09-09 19:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-09 19:29 hendriks [this message]
2003-09-09 21:25 ` 2.4.21 -> 2.4.22 kernel thread oddities Alan Cox
2003-09-10 10:40 ` kernel panic linux-2.4.22 joe patiani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030909192913.GE10623@lanl.gov \
--to=hendriks@lanl.gov \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox