On Wed, 23 Jul 2003, Rene Mayrhofer wrote:
> Alan Cox wrote:
> > On Maw, 2003-07-22 at 23:14, Mika Penttilä wrote:
> >
> >>/sbin/init used to start up with files->count > 1 and does
> >>close(0);close(1);close(2); -> kernel thread fds close.
> >>
> >>Now with unshare_files() and init's files->count ==1 the kernel threads
> >>/dev/console fds remain open. But one could ask of course so what :)
> The problem with this behaviour is that the old root fs can not be
> unmounted in this case, which basically means that the machine will be
> unable to switch off its harddisk. And that, at least in my case, is
> annoying :)
>
>
> > In other words the kernel side got caught out because it assumed
> > the bogus thread behaviour and needs some close() calls adding. That
> > would make sense.
> I have to admin that I don't really know the internals and thus don't
> completely understand. What would need to be done to fix it ? Change
> init's re-exec routines ?
right. so the semantics of how file tables are shared has changed a bit. I
would think that for at least 'init', it'd be nice to preserve the
original behavior, for situations such as you described. Something like
the following would probably work, although i havent' tried the test
script.
--- linux/kernel/fork.c.orig 2003-07-23 21:34:59.000000000 -0400
+++ linux/kernel/fork.c 2003-07-23 21:35:45.000000000 -0400
@@ -558,7 +558,7 @@ int unshare_files(void)
/* This can race but the race causes us to copy when we don't
need to and drop the copy */
- if(atomic_read(&files->count) == 1)
+ if(atomic_read(&files->count) == 1 || (current->pid == 1))
{
atomic_inc(&files->count);
return 0;
-
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/
This archive was generated by hypermail 2b29 : Wed Jul 23 2003 - 22:00:51 EST