geom_uzip, panic: bio_length in mdstart_vnode()

[Paolo Pinto]

Hi list!

My kernel is compiled with option INVARIANTS and I get a reproducible
kernel panic when trying to read data from a GEOM based compressed
memory disk:

Unread portion of the kernel message buffer:
panic: bio_length 140288
cpuid = 3
KDB: stack backtrace:
#0 0xffffffff80909726 at kdb_backtrace+0x66
#1 0xffffffff808d0fa8 at panic+0x1d8
#2 0xffffffff80595949 at mdstart_vnode+0x619
#3 0xffffffff80594053 at md_kthread+0x143
#4 0xffffffff808a3145 at fork_exit+0x135
#5 0xffffffff80c6fabe at fork_trampoline+0xe
Uptime: 16m21s
Dumping 367 out of 6113 MB:..5%..14%..22%..31%..44%..53%..61%..74%..83%..92%

Loaded symbols for /boot/kernel/geom_uzip.ko
#0  doadump (textdump=<value optimized out>) at pcpu.h:234
234     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=<value optimized out>) at pcpu.h:234
#1  0xffffffff808d1552 in kern_reboot (howto=260)
    at /data/usr/home/fabient/fabient-freebsd/sys/kern/kern_shutdown.c:449
#2  0xffffffff808d0f79 in panic (fmt=0x1 <Address 0x1 out of bounds>)
    at /data/usr/home/fabient/fabient-freebsd/sys/kern/kern_shutdown.c:637
#3  0xffffffff80595949 in mdstart_vnode (sc=0xfffffe00070e5000,
    bp=0xfffffe0059bf38b8)
    at /data/usr/home/fabient/fabient-freebsd/sys/dev/md/md.c:742
#4  0xffffffff80594053 in md_kthread (arg=<value optimized out>)
    at /data/usr/home/fabient/fabient-freebsd/sys/dev/md/md.c:945
#5  0xffffffff808a3145 in fork_exit (callout=0xffffffff80593f10
<md_kthread>,
    arg=0xfffffe00070e5000, frame=0xffffff81bdc34c40)
    at /data/usr/home/fabient/fabient-freebsd/sys/kern/kern_fork.c:992
#6  0xffffffff80c6fabe in fork_trampoline ()
    at
/data/usr/home/fabient/fabient-freebsd/sys/amd64/amd64/exception.S:606
#7  0x0000000000000000 in ?? ()
(kgdb)

Panic is coming from a KASSERT :

KASSERT(bp->bio_length <= MAXPHYS, ("bio_length %jd",
(uintmax_t)bp->bio_length));

with MAXPHYS = 128*1024 = 131072


Environment :

$ uname -a
FreeBSD refbench 9.2-RELEASE-p1 FreeBSD 9.2-RELEASE-p1 #75
r229873+c58f3c3-dirty: Wed Dec  4 11:22:54 CET 2013
fabient at refbench:/usr/obj/data/usr/home/fabient/fabient-freebsd/sys/GENERIC
 amd64


How-To-Repeat :

$ mkdir work && cd work

$ dd if=/dev/random of=data.img bs=256k count=1
1+0 records in
1+0 records out
262144 bytes transferred in 0.002899 secs (90427801 bytes/sec)

$ ls -lh
total 272
-rw-r--r-- 1 paolop devel 256k Dec 4 10:47:51 2013 data.img

$ cd -

$ makefs -t ffs -o optimization=time -o version=2 foo.img work/
Calculated size of `foo.img': 311296 bytes, 3 inodes
Extent size set to 8192
foo.img: 0.3MB (608 sectors) block size 8192, fragment size 1024
    using 1 cylinder groups of 0.30MB, 38 blks, 32 inodes.
super-block backups (for fsck -b #) at:
 32,
Populating `foo.img'
makefs: Writing inode 3 (work//./data.img), bytes 253952 + 8192: No
space left on device

First issue; why does this happen?
As workaround, I have to create another file/data :

$ python -c "print 'a'*300000" > work/bar.txt

$ ls -lh work/
total 592
-rw-r--r-- 1 paolop devel 293k Dec 4 10:49:22 2013 bar.txt
-rw-r--r-- 1 paolop devel 256k Dec 4 10:47:51 2013 data.img

$ makefs -t ffs -o optimization=time -o version=2 foo.img work/
Calculated size of `foo.img': 638976 bytes, 4 inodes
Extent size set to 8192
foo.img: 0.6MB (1248 sectors) block size 8192, fragment size 1024
    using 1 cylinder groups of 0.61MB, 78 blks, 32 inodes.
super-block backups (for fsck -b #) at:
 32,
Populating `foo.img'
Image `foo.img' complete

$ mkuzip foo.img; echo $?
0

$ ls -lh foo*
-rw-r--r-- 1 paolop devel 624k Dec 4 10:49:24 2013 foo.img
-rwxr-xr-x 1 paolop devel 259k Dec 4 10:49:36 2013 foo.img.uzip*

So, it's ok, I've my uzip file and I mount it :

$ sudo kldload geom_uzip

$ sudo mdconfig -a -t vnode -o readonly -f foo.img.uzip
md0

$ sudo mount -o ro,noatime /dev/md0.uzip /mnt

$ ls -al /mnt/
total 570
drwxr-xr-x 2 1023 1001 512 Dec 4 10:49 .
drwxr-xr-x 6 admin wheel 512 Dec 4 09:23 ..
-rw-r--r-- 1 1023 1001 300001 Dec 4 10:49 bar.txt
-rw-r--r-- 1 1023 1001 262144 Dec 4 10:47 data.img

$ cp /mnt/data.img /tmp/

And panic!
Is there anything I could do to help debugging this problem? I have the
core dump if that helps.

Thanks!


Regards,
-- 
Paolo Pinto
R&D System Engineer

NETASQ - We secure IT


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2268 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20131204/36fc05ab/attachment.bin>