Bug #1916

Constant crashes on x86_64 with UFS

Added by lentferj about 4 years ago. Updated about 4 years ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

On the VM that I provide for Justin to make bulk builds I am getting
constant panics after I enabled swapcache.

#14 0xffffffff8035d01f in panic (fmt=0xffffffff80685d46 "ffs_realloccg:
bad blockno") at /usr/src/sys/kern/kern_shutdown.c:785
#15 0xffffffff804fec9c in ffs_realloccg (ip=0xffffffe00096e698,
lbprev=<value optimized out>, bpref=8, osize=4096, nsize=5120,
cred=0xffffffe000886900, bpp=0xffffffe02e4157f0) at
/usr/src/sys/vfs/ufs/ffs_alloc.c:230
#16 0xffffffff804ff338 in ffs_balloc (ap=0xffffffe02e415838) at
/usr/src/sys/vfs/ufs/ffs_balloc.c:183
#17 0xffffffff803cece0 in vop_balloc (ops=0xffffffe007fcea80,
vp=0xffffffe02e58b400, startoffset=<value optimized out>, size=<value
optimized out>,
cred=<value optimized out>, flags=<value optimized out>,
bpp=0xffffffe02e415918) at /usr/src/sys/kern/vfs_vopops.c:936
#18 0xffffffff8050abba in ffs_write (ap=0xffffffe02e415958) at
/usr/src/sys/vfs/ufs/ufs_readwrite.c:348
#19 0xffffffff803cf738 in vop_write (ops=0xffffffe007fcea80,
vp=0xffffffe02e58b400, uio=<value optimized out>, ioflag=<value
optimized out>,
cred=<value optimized out>) at /usr/src/sys/kern/vfs_vopops.c:427
#20 0xffffffff803cdb7b in vn_write (fp=0xffffffe00ab7d4a8,
uio=0xffffffe02e415ad8, cred=0xffffffe000886900, flags=<value optimized
out>)
at /usr/src/sys/kern/vfs_vnops.c:724
#21 0xffffffff803871ef in dofilewrite (fd=6, auio=0xffffffe02e415ad8,
flags=0, res=0xffffffe02e415b48) at /usr/src/sys/sys/file2.h:72

Kernel is
DragonFly df64pkgbuilder.lan.net 2.9-DEVELOPMENT DragonFly
v2.9.0.116.ge61a8-DEVELOPMENT #0: Fri Nov 5 06:38:41 CET 2010
:/usr/obj/usr/src/sys/X86_64_GENERIC x86_64

Anyone seen this before?

Jan

History

#1 Updated by dillon about 4 years ago

:On the VM that I provide for Justin to make bulk builds I am getting
:constant panics after I enabled swapcache.
:
:#15 0xffffffff804fec9c in ffs_realloccg (ip=0xffffffe00096e698,
:lbprev=<value optimized out>, bpref=8, osize=4096, nsize=5120,
: cred=0xffffffe000886900, bpp=0xffffffe02e4157f0) at
:/usr/src/sys/vfs/ufs/ffs_alloc.c:230
:...
:
:Kernel is
:DragonFly df64pkgbuilder.lan.net 2.9-DEVELOPMENT DragonFly
:v2.9.0.116.ge61a8-DEVELOPMENT #0: Fri Nov 5 06:38:41 CET 2010
::/usr/obj/usr/src/sys/X86_64_GENERIC x86_64
:
:Anyone seen this before?
:
:Jan

Hmm. I haven't seen it before but I can see how it can happen.
b_bio2 is being used by the vn_cache_strategy code (swapcache).

UFS/FFS is assuming that *ALL* file bread()s ultimately dive into the
UFS/FFS stategy code and properly populate b_bio2 for the drill-down
to the disk device, but if it gets bypassed by the swapcache that will
not happen. Instead, b_bio2 is populated by the swapcache and the
value will have nothing to do with the underlying disk device.

The bug is actually in swapcache. The solution is for swapcache to
set bio_offset to NOOFFSET, but it is a bit of a hack to make it do
that.

The reason this problem doesn't occur with HAMMER is due to a fluke.
HAMMER does a test for HAMMER_ZONE_LARGE_DATA before believing a
cached bio_offset and, of course, that is one huge 64-bit offset and
swapcache is never able to set an offset that large.

Please try this patch:

fetch http://apollo.backplane.com/DFlyMisc/swap03.patch

-Matt
Matthew Dillon
<>

Also available in: Atom PDF