Re: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop

[Al Viro]

On Tue, Dec 16, 2014 at 06:46:10AM -0800, Jeremiah Mahler wrote:
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1026,16 +1026,17 @@ static noinline void __init kernel_init_freeable(void)
>         if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
>                 ramdisk_execute_command = NULL;
>                 prepare_namespace();
> -               {
> -               /* HACK */
> -                       struct path old, new;
> -                       get_fs_root(current->fs, &new);
> -                       get_fs_root(&init_fs, &old);
> -                       chroot_fs_refs(&old, &new);
> -                       path_put(&old);
> -                       path_put(&new);
> -               }
>         }
> +       {
> +       /* HACK */
> +               struct path old, new;
> +               get_fs_root(current->fs, &new);
> +               get_fs_root(&init_fs, &old);
> +               chroot_fs_refs(&old, &new);
> +               path_put(&old);
> +               path_put(&new);
> +       }
> +
>  
>         /*
>          * Ok, we have completed the initial bootup, and
> 
> 
> And it still behaves the same.  Below is the dmesg output.

> [    2.281438] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000g2a-6.ucode failed with error -2
> [    2.281451] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000g2a-5.ucode failed with error -2
> [    2.281453] iwlwifi 0000:03:00.0: request for firmware file 'iwlwifi-6000g2a-5.ucode' failed.
> [    2.281521] iwlwifi 0000:03:00.0: no suitable firmware found!

No such errors happen on the normal boot, presumably?

> [    2.392117] EXT4-fs (sda5): mounting ext2 file system using the ext4 subsystem
> [    2.393920] EXT4-fs (sda5): mounted filesystem without journal. Opts: (null)

Wait a minute. So that happens _before_ /dev/sda5 mount?  Could you post dmesg
from the normal boot (e.g. just prior to the buggy commit)?

I really don't get it - there's nothing for init_fs.root to point to other
than initramfs by that point, CLONE_FS or no CLONE_FS.  We simply don't
have anything else mounted yet.  Do you get another failing bunch of
request_firmware later?  And what does dmesg look like on the working
kernel - either you have that firmware on initramfs image (in which case
it ought to have been picked by both kernels), or you do not, in which case
neither kernel would've managed to load it until after mounting the real
root...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/