Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

pivot_root solved by patch to 2.4.22-pre7

0 views
Skip to first unread message

Rene Mayrhofer

unread,
Aug 6, 2003, 2:30:19 AM8/6/03
to
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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Marcelo Tosatti

unread,
Aug 6, 2003, 3:40:11 PM8/6/03
to

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.

Herbert Pötzl

unread,
Aug 6, 2003, 4:00:14 PM8/6/03
to
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

Andreas Haumer

unread,
Aug 7, 2003, 5:40:13 AM8/7/03
to
-----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: 3F267FD7...@xss.co.at) and in more detail
on July 30th, (Message-ID: 3F2795DE...@xss.co.at)

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:and...@xss.co.at
*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-----

Rene Mayrhofer

unread,
Aug 7, 2003, 6:40:11 AM8/7/03
to
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

Alan Cox

unread,
Aug 7, 2003, 8:10:07 AM8/7/03
to
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)

Jason Baron

unread,
Aug 7, 2003, 11:40:12 AM8/7/03
to

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

Alan Cox

unread,
Aug 7, 2003, 12:10:10 PM8/7/03
to
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.

Jason Baron

unread,
Aug 7, 2003, 12:50:13 PM8/7/03
to

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?

Jason Lunz

unread,
Aug 15, 2003, 2:20:19 PM8/15/03
to
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

0 new messages