xfs
[Top] [All Lists]

Re: [bisected] xfs panics when attempting to mount btrfs

To: Sergei Trofimovich <slyfox@xxxxxxxxxx>
Subject: Re: [bisected] xfs panics when attempting to mount btrfs
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Sat, 29 Dec 2012 17:29:21 -0600
Cc: Dave Chinner <dchinner@xxxxxxxxxx>, Phil White <pwhite@xxxxxxx>, Ben Myers <bpm@xxxxxxx>, Alex Elder <elder@xxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20121230015109.1219d01f@sf>
References: <20121229135229.4ea4615a@xxxxxxxxxxxxx> <50DF508D.2010105@xxxxxxxxxxx> <20121230015109.1219d01f@sf>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/29/12 4:51 PM, Sergei Trofimovich wrote:
> On Sat, 29 Dec 2012 14:20:29 -0600
> Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
> 
>>> Panic showed all my drives and partitions which means
>>> they were detected correctly.
> 
>> Was it a panic, or was it simply a very verbose message which contained a 
>> backtrace?
> 
>> Can you please include what you actually saw in your logs?
> 
> Yes, it was a panic. Box did not boot (i would not bisect it otherwise).
> I won't have access to real box thus I've reproduced it in minimal
> UML:
> 
> Current usermode linux perfectly reproduces the problem as well:
> 
> $ cat ./run_ubda_fails 
> #!/bin/sh
> 
> ./vmlinux                                        \
>     ubd0=$(pwd)/1G.img                           \
>     root=/dev/ubda                               \
>     rw                                           \
>     mem=256M                                     \
>     umid=foo                                     \
>                                                  \
>     "$@"
> reset
> 
> $ cat ./run_ubda
> #!/bin/sh
> 
> ./vmlinux                                        \
>     ubd0=$(pwd)/1G.img                           \
>     root=/dev/ubda                               \
>     rw rootfstype=btrfs                          \
>     mem=256M                                     \
>     umid=foo                                     \
>                                                  \
>     "$@"
> reset
> 
> Note the rootfstype in the workign case. I've included only EXT4=y XFS=y and 
> BTRFS=y
> as supported FSen. The UML OOps:
> 
> [    0.170000] VFS: Cannot open root device "ubda" or unknown-block(98,0): 
> error -117

Oh, ok, so it was panicing due to inability to mount root; not xfs itself 
panicing.

Were there any messages from xfs prior to this?

Especially if there were none, this might fix it, though TBH it's just
a quick guess, I haven't really looked at how the probing works at
boot time recently.  Can you test it?

From: Eric Sandeen <sandeen@xxxxxxxxxx>

Do not return EFSCORRUPTED when filesystem probe finds no XFS magic

9802182 changed the return value from EWRONGFS (aka EINVAL)
to EFSCORRUPTED which doesn't seem to be handled properly by
the root filesystem probe.

Signed-off-by: Eric Sandeen <sandeen@xxxxxxxxxx>
- ---

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index da50846..7d6df7c 100644
- --- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -658,7 +658,7 @@ xfs_sb_quiet_read_verify(
                return;
        }
        /* quietly fail */
- -     xfs_buf_ioerror(bp, EFSCORRUPTED);
+       xfs_buf_ioerror(bp, EWRONGFS);
 }
 
 static void




> [    0.170000] Please append a correct "root=" boot option; here are the 
> available partitions:
> [    0.170000] 6200         1048576 ubda  driver: uml-blkdev
> [    0.170000] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(98,0)
> [    0.170000] Call Trace: 
> [    0.170000] 7003fd68:  [<6037c4d8>] panic+0x164/0x2c6
> [    0.170000] 7003fda0:  [<6037c374>] panic+0x0/0x2c6
> [    0.170000] 7003fdd8:  [<60385a20>] _raw_spin_lock+0x0/0x20
> [    0.170000] 7003fe48:  [<6037c63a>] printk+0x0/0xa0
> [    0.170000] 7003fe60:  [<600d9780>] sys_mount+0x0/0x120
> [    0.170000] 7003fe78:  [<60001fa5>] mount_block_root+0x33a/0x359
> [    0.170000] 7003fee8:  [<602afdd0>] strcpy+0x0/0x30
> [    0.170000] 7003ff08:  [<60002045>] mount_root+0x81/0x85
> [    0.170000] 7003ff18:  [<602b0040>] strncmp+0x0/0x60
> [    0.170000] 7003ff28:  [<6000222c>] prepare_namespace+0x1e3/0x22b
> [    0.170000] 7003ff38:  [<600d5350>] sys_dup+0x0/0x80
> [    0.170000] 7003ff48:  [<602afdd0>] strcpy+0x0/0x30
> [    0.170000] 7003ff58:  [<6037b0f5>] kernel_init+0x205/0x3d0
> [    0.170000] 7003ff60:  [<600011ae>] repair_env_string+0x0/0xbd
> [    0.170000] 7003ffd8:  [<6001cc91>] new_thread_handler+0x81/0xb0
> 
> 'Cannot open root device' is completely bogus. It can be opened if I set 
> proper
> FS type.
> 
> Thanks!
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQ33zPAAoJECCuFpLhPd7gPvgP/2ZQdpHB2YEx8qR4fgBp+/Ri
BxgVihalu/mbDo3JZGoFc+ll7+KRCeEqQoCd3T1WaBR64DCO0IM4zeDDws4zsYZA
0xQwpUHNKGoAcZdOpPhbk3Eqz3QYETHFrsGrpxrW00X1+MEVNsmtxW59Z1w9JTvH
8tfeYV9u4Z8GzGhN8pxjmGZSDymSOsYrMPdG0L2BLkB0MyAFlRSstI7ccF8CaZDP
V6zcAQH0X08FNvY4XcQ7JY4wA+M1O01CDbO063/Co99GGU/F/tmH7awvEk38MA/n
nQCotxi2TOCDAePG16Z3b82P5gH30V2CPy55lQsUpyn8lAB72WUuMqkWP1WtkL8E
KeKSGreF40VOsPdMP9tdfUkzkWg6/s6GzxMAMpnmJSWDdtYNKkNRz6gBfwK6Rqou
tVeg5q3F/MyA00BxsCoNZ5sLWRGd1JJwKppChxJfVMLx4tqaztbZ7GUchVWDFZPQ
nCxsFwxVjI07cYKcl8EeP57WKCiE/jzhacg/mvoK+MiKZ9wk3QOC5ZAYxrQ5qF8k
C8l3lU8bx9gpQ1p4w901qyPUv9nDdNCKXq70S6kljeZDSquVpzqUbqh/Mfy6Rh8G
20jTSmdRi4IhMSO/GBI6obDkeo7mdfseAjNiOXKPDa3DaWmg1vCWOWaPkTLViXXG
iX9ZN24AQ3pwoUFQdgj1
=cyIt
-----END PGP SIGNATURE-----

<Prev in Thread] Current Thread [Next in Thread>