linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 2.4.21 -> 2.4.22 kernel thread oddities
@ 2003-09-09 19:29 hendriks
  2003-09-09 21:25 ` Alan Cox
  2003-09-10 10:40 ` kernel panic linux-2.4.22 joe patiani 
  0 siblings, 2 replies; 3+ messages in thread
From: hendriks @ 2003-09-09 19:29 UTC (permalink / raw)
  To: linux-kernel

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



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: 2.4.21 -> 2.4.22 kernel thread oddities
  2003-09-09 19:29 2.4.21 -> 2.4.22 kernel thread oddities hendriks
@ 2003-09-09 21:25 ` Alan Cox
  2003-09-10 10:40 ` kernel panic linux-2.4.22 joe patiani 
  1 sibling, 0 replies; 3+ messages in thread
From: Alan Cox @ 2003-09-09 21:25 UTC (permalink / raw)
  To: hendriks; +Cc: Linux Kernel Mailing List

On Maw, 2003-09-09 at 20:29, hendriks@lanl.gov wrote:
> 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.

I sent Marcelo a fix for this in 2.4.23pre/2.4.22-ac - see the change to
init/main.c



^ permalink raw reply	[flat|nested] 3+ messages in thread

* kernel panic linux-2.4.22
  2003-09-09 19:29 2.4.21 -> 2.4.22 kernel thread oddities hendriks
  2003-09-09 21:25 ` Alan Cox
@ 2003-09-10 10:40 ` joe patiani 
  1 sibling, 0 replies; 3+ messages in thread
From: joe patiani  @ 2003-09-10 10:40 UTC (permalink / raw)
  To: linux-kernel

I got problem when booting from my new kernel. I`ve 
compile linux-2.4.22 kernel, but I can`t use it correctly. 
The error says that Kernel Panic VFS cannot mount root.

Can linux-2.4.22 kernel  read the ext2 fs partition. How 
the solution to handle the problem. Please if anyone know 
about it send email to my addr. I`m a newbies, so I need a 
clear explanation  

===========================================================================================
"Instan Diskon Setiap Hari"...
Setiap hari jam 10 malam sampai jam 7 pagi 
Dan setiap Hari Libur.. 
berlaku mulai 1 September - 31 Desember 2003,
Khusus Jawa Timur...
===========================================================================================

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-09-10 10:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-09 19:29 2.4.21 -> 2.4.22 kernel thread oddities hendriks
2003-09-09 21:25 ` Alan Cox
2003-09-10 10:40 ` kernel panic linux-2.4.22 joe patiani 

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).