[bisected] xfs panics when attempting to mount btrfs

[Sergei Trofimovich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 29 Dec 2012 17:29:21 -0600
Eric Sandeen <sandeen at sandeen.net> wrote:

> -----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 at sandeen.net> 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 at redhat.com>
> 
> 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 at redhat.com>

Yeah, you patch is nicer. xfs_mount_validate_sb does the similar thing.
Thanks!

Tested-by: Sergei Trofimovich <slyfox at gentoo.org>

> - ---
> 
> 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-----
> 


- -- 

  Sergei
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlDgCMIACgkQcaHudmEf86q5eQCcDLq+olOGGyKNuax8VHjX1Vag
FaQAn1/qAZoOVYH4U8NMtmiDrqv6gjSN
=aHrQ
-----END PGP SIGNATURE-----