Hi all,
The problem with pivot_root that appeared in 2.4.21-ac4 and the
2.4.22-pre kernels is now solved (at least for my case) by applying the
trvial patch sent by Jason Baron.
Jason Baron wrote:
> 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;
>
I tried that on my system and it works as expected. The kernel processes
close their fds and the old root fs can thus be unmounted after
pivot_root. Thanks for the hint !
So the problem is solved for me and it would be wonderful to get it into
2.4.22.
best regards,
Rene
What is your problem with pivot_root?
Sorry but I've searched the list archives and found nothing but this email
and this patch, which seems a bit hackish.
On Wed, 6 Aug 2003, Rene Mayrhofer wrote:
> Hi all,
>
> The problem with pivot_root that appeared in 2.4.21-ac4 and the
> 2.4.22-pre kernels is now solved (at least for my case) by applying the
> trvial patch sent by Jason Baron.
>
> Jason Baron wrote:
> > 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;
> >
>
>
>
> I tried that on my system and it works as expected. The kernel processes
> close their fds and the old root fs can thus be unmounted after
> pivot_root. Thanks for the hint !
> So the problem is solved for me and it would be wonderful to get it into
> 2.4.22.
>
> best regards,
> Rene
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Wed, Aug 06, 2003 at 04:33:52PM -0300, Marcelo Tosatti wrote:
>
> What is your problem with pivot_root?
>
> Sorry but I've searched the list archives and found nothing but this email
> and this patch, which seems a bit hackish.
Jul 21 Rene Mayrhofer 82 pivot_root seems to be broken in 2.4.21-a1716
Jul 22 Denis Vlasenko 103 >
Jul 22 Rene Mayrhofer 54 >
Jul 22 Jason Baron 18 >
Jul 22 Alan Cox 22 >
Jul 22 Rene Mayrhofer 25 >
Jul 22 Alan Cox 17 >
Jul 22 Rene Mayrhofer 154 >
Jul 23 Mika Penttil? 40 >
Jul 22 Mika Penttil? 41 >
HTH,
Herbert
> On Wed, 6 Aug 2003, Rene Mayrhofer wrote:
>
> > Hi all,
> >
> > The problem with pivot_root that appeared in 2.4.21-ac4 and the
> > 2.4.22-pre kernels is now solved (at least for my case) by applying the
> > trvial patch sent by Jason Baron.
> >
> > Jason Baron wrote:
> > > 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;
> > >
> >
> >
> >
> > I tried that on my system and it works as expected. The kernel processes
> > close their fds and the old root fs can thus be unmounted after
> > pivot_root. Thanks for the hint !
> > So the problem is solved for me and it would be wonderful to get it into
> > 2.4.22.
> >
> > best regards,
> > Rene
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to [email protected]
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at http://www.tux.org/lkml/
> >
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi!
Herbert P?tzl wrote:
> On Wed, Aug 06, 2003 at 04:33:52PM -0300, Marcelo Tosatti wrote:
>
>>What is your problem with pivot_root?
>>
>>Sorry but I've searched the list archives and found nothing but this email
>>and this patch, which seems a bit hackish.
>
>
> Jul 21 Rene Mayrhofer 82 pivot_root seems to be broken in 2.4.21-a1716
> Jul 22 Denis Vlasenko 103 >
> Jul 22 Rene Mayrhofer 54 >
> Jul 22 Jason Baron 18 >
> Jul 22 Alan Cox 22 >
> Jul 22 Rene Mayrhofer 25 >
> Jul 22 Alan Cox 17 >
> Jul 22 Rene Mayrhofer 154 >
> Jul 23 Mika Penttil? 40 >
> Jul 22 Mika Penttil? 41 >
>
This patch also solves my problem as reported on Jul. 29th
(Subject: "2.4.22-pre4: devfs on initrd stays busy after pivot_root"
Message-ID: [email protected]) and in more detail
on July 30th, (Message-ID: [email protected])
I just tried it with 2.4.22-rc1, and with this patch I am
able to umount /initrd/dev and /initrd after pivot_root
again!
Don't know yet if it has any ill side effects, though.
HTH
- - andreas
- --
Andreas Haumer | mailto:[email protected]
*x Software + Systeme | http://www.xss.co.at/
Karmarschgasse 51/2/20 | Tel: +43-1-6060114-0
A-1100 Vienna, Austria | Fax: +43-1-6060114-71
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/Mh0/xJmyeGcXPhERAmbLAKCUrXFUA44ggJvOBMlwvA4GKFsWdwCeNIid
4bWSyQ2OFqwXnNdU8t/bJsw=
=sdiS
-----END PGP SIGNATURE-----
Andreas Haumer wrote:
> I just tried it with 2.4.22-rc1, and with this patch I am
> able to umount /initrd/dev and /initrd after pivot_root
> again!
Same for me. With this patch, all the 2.4.21-ac*, 2.4.22-pre*-ac* and
2.4.22-rc1 kernels I tried work again.
> Don't know yet if it has any ill side effects, though.
Doesn't seem to have, but IANAKG (I am not a kernel guru) ;)
- Rene
On Mer, 2003-08-06 at 07:27, Rene Mayrhofer wrote:
> Hi all,
>
> The problem with pivot_root that appeared in 2.4.21-ac4 and the
> 2.4.22-pre kernels is now solved (at least for my case) by applying the
> trvial patch sent by Jason Baron.
The patch shouldnt be needed or make any difference. I have to
understand why its fixing the problem and fix it properly yet (or
someone does)
On 7 Aug 2003, Alan Cox wrote:
> On Mer, 2003-08-06 at 07:27, Rene Mayrhofer wrote:
> > Hi all,
> >
> > The problem with pivot_root that appeared in 2.4.21-ac4 and the
> > 2.4.22-pre kernels is now solved (at least for my case) by applying the
> > trvial patch sent by Jason Baron.
>
> The patch shouldnt be needed or make any difference. I have to
> understand why its fixing the problem and fix it properly yet (or
> someone does)
>
>
it clearly makes a difference.
the unshare_files change causes init to no longer share the same fd table
with the other kernel threads. thus, when init closes or opens fds it does
not affect the other kernel threads. this patch allows init to continue to
share the same fd table with the other kernel threads as before the
unshare_files change. it does not compromise the intention of the
unshare_files change afaik.
-Jason
On Iau, 2003-08-07 at 16:26, Jason Baron wrote:
> it clearly makes a difference.
>
> the unshare_files change causes init to no longer share the same fd table
> with the other kernel threads. thus, when init closes or opens fds it does
Ah yes.. because of do_basic_setup. Having /sbin/init sharing with
kernel threads doesn't actually strike me as too clever anyway although
none of them should be using fd stuff.
In which case I guess we should call unshare_files directly before we
open /dev/console in init/main.c.
On 7 Aug 2003, Alan Cox wrote:
> On Iau, 2003-08-07 at 16:26, Jason Baron wrote:
> > it clearly makes a difference.
> >
> > the unshare_files change causes init to no longer share the same fd table
> > with the other kernel threads. thus, when init closes or opens fds it does
>
> Ah yes.. because of do_basic_setup. Having /sbin/init sharing with
> kernel threads doesn't actually strike me as too clever anyway although
> none of them should be using fd stuff.
>
> In which case I guess we should call unshare_files directly before we
> open /dev/console in init/main.c.
>
ok, but what if we re-exec init a couple of times?
In gmane.linux.kernel, you wrote:
>> the unshare_files change causes init to no longer share the same fd table
>> with the other kernel threads. thus, when init closes or opens fds it does
>
> Ah yes.. because of do_basic_setup. Having /sbin/init sharing with
> kernel threads doesn't actually strike me as too clever anyway although
> none of them should be using fd stuff.
>
> In which case I guess we should call unshare_files directly before we
> open /dev/console in init/main.c.
Is this going to be fixed for 2.4.22? In -rc2, I still get this after
pivot_root (I'm using pivot_root, but not initrd):
halfoat:0:~ # umount /mnt
umount: /mnt: device is busy
halfoat:1:~ # lsof /mnt
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
keventd 2 root 0u CHR 5,1 21 /mnt/dev/console
keventd 2 root 1u CHR 5,1 21 /mnt/dev/console
keventd 2 root 2u CHR 5,1 21 /mnt/dev/console
ksoftirqd 3 root 0u CHR 5,1 21 /mnt/dev/console
ksoftirqd 3 root 1u CHR 5,1 21 /mnt/dev/console
ksoftirqd 3 root 2u CHR 5,1 21 /mnt/dev/console
ksoftirqd 4 root 0u CHR 5,1 21 /mnt/dev/console
ksoftirqd 4 root 1u CHR 5,1 21 /mnt/dev/console
ksoftirqd 4 root 2u CHR 5,1 21 /mnt/dev/console
kswapd 5 root 0u CHR 5,1 21 /mnt/dev/console
kswapd 5 root 1u CHR 5,1 21 /mnt/dev/console
kswapd 5 root 2u CHR 5,1 21 /mnt/dev/console
bdflush 6 root 0u CHR 5,1 21 /mnt/dev/console
bdflush 6 root 1u CHR 5,1 21 /mnt/dev/console
bdflush 6 root 2u CHR 5,1 21 /mnt/dev/console
kupdated 7 root 0u CHR 5,1 21 /mnt/dev/console
kupdated 7 root 1u CHR 5,1 21 /mnt/dev/console
kupdated 7 root 2u CHR 5,1 21 /mnt/dev/console
kjournald 64 root 0u CHR 5,1 21 /mnt/dev/console
kjournald 64 root 1u CHR 5,1 21 /mnt/dev/console
kjournald 64 root 2u CHR 5,1 21 /mnt/dev/console
Jason