[bisected] xfs panics when attempting to mount btrfs

[Eric Sandeen]

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

On 12/29/12 4:52 AM, Sergei Trofimovich wrote:
> Sorry for not providing exact logs,
> I have got a problem at boot.
> 
> The problem is the following:
> 
> I have a / as btrfs filesystem and have quite a few
> filesystems built-in to kernel [1]
> 
> Thus when root is mounted each filesystem is probed.
> After 3.8-rc1 my box stopped booting showing kernel panic.
> Panic said there is no valid filesystem on my devices
> 
> 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?

- -Eric

> Bisection shown the following commit 98021821a502db347bd9c7671beeee6e8ce07ea6 [2].
> 
>> xfs: verify superblocks as they are read from disk
> 
> which looks very likely to cause troubles.
> 
> I think it's easy to reproduce problems
> by trying to mount something non-xfs as xfs
> (didn't try but will do if you like).
> 
>     mount -t xfs -oloop /some/btrfs.image
> 
> Thanks!
> 
> [1]:
> $ cat /proc/filesystems  | grep -v nodev
>         reiserfs
>         ext3
>         ext2
>         ext4
>         vfat
>         msdos
>         iso9660
>         udf
>         jfs
>         xfs
>         btrfs
>         fuseblk
> 
> [2]:
> 
> 98021821a502db347bd9c7671beeee6e8ce07ea6 is the first bad commit
> commit 98021821a502db347bd9c7671beeee6e8ce07ea6
> Author: Dave Chinner <dchinner at redhat.com>
> Date:   Mon Nov 12 22:54:03 2012 +1100
> 
>     xfs: verify superblocks as they are read from disk
>     
>     Add a superblock verify callback function and pass it into the
>     buffer read functions. Remove the now redundant verification code
>     that is currently in use.
>     
>     Adding verification shows that secondary superblocks never have
>     their "sb_inprogress" flag cleared by mkfs.xfs, so when validating
>     the secondary superblocks during a grow operation we have to avoid
>     checking this field. Even if we fix mkfs, we will still have to
>     ignore this field for verification purposes unless a version of mkfs
>     that does not have this bug was used.
>     
>     Signed-off-by: Dave Chinner <dchinner at redhat.com>
>     Reviewed-by: Phil White <pwhite at sgi.com>
>     Signed-off-by: Ben Myers <bpm at sgi.com>
> 
> :040000 040000 56723c8ba61cafeaf85782b3f378b3248afab7e1
> cfba7b784fa9016de85017952fd1c5960e4655ce M      fs
> 
> 
> 
> _______________________________________________
> xfs mailing list
> xfs at oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
> 

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

iQIcBAEBAgAGBQJQ31CMAAoJECCuFpLhPd7g6OoP/A5J8oOLADy/Smk/y31SLmto
Eqz32PAqJRr9vl4e7olibjHd1hUFxTBEsDpRV1g/TVkVVodOIpsReiZo26ltVYK8
iva/JM5/uZbCI5WQYV+LZbn5svD+ycbiTveO/46qc5L5XgllsIt43JEDcwlyJlOi
lMysTIDtnGZa5HUDajh8xLssV0jrc4UkpVzGXzVfHwdWXtcx60cCxv1a4c980nNm
2oTwRVewBuWLOJmTE20jvjGA3XEmfpCkxUOpaU6xLdRKP6DjXrlUES9o2lowit4s
b1Z6fK4tyOKjNDZXWOJ8d2NRSNdMvLIH+uqdCPwt3jSGX14t8nHBjoyg67TeIwIq
HWCYMrvZSElTgFk5FAAUvGjd8H2ncoIQ8A7ZY+tNJgRuLJMAoHdNw7KosyDbz2tp
lQG2qGBNKiEC7Aa5WxJ2XaK6m07RjYR+UKXmG/Xek0NCamKuwErKyyFPLSkYa2Zt
sBK+fCaAoGiFj9MlyCbSd5i2nHQ9O92ozaP9w5OzONiMiJ15yGEGZyuPal0g0YGz
fJHbpYP1Fd9d0I9mNCub/hepjiJLSUCiQetOr4OXuAXXnSfa7uwuKHxb4WoMMY1Q
fxSyH7kPIKChTuo9Q3/Mo8z6EIygBRWD2DvzCzD2v5Z1tt2DFZK4KzN09VqBce5F
wHgfd6InDSn0vpzkzl4V
=O0r1
-----END PGP SIGNATURE-----