RELENG_6 vm_fault panic on filesystem mount

Fri Nov 18 22:02:30 GMT 2005

On Fri, 18 Nov 2005 18:59:34 +0000 (GMT)
Robert Watson <rwatson at FreeBSD.org> wrote:

> Could I ask you to boot to single user mode, try mounting the file
> system, then try compiling a kernel without UFS_EXTATTR and
> UFS_EXTATTR_AUTOSTART, boot to single user mode, and see if you can
> mount the file system successfully?  I.e., compare mounting with and
> without extended attributes, but on a "quiet" file system so any
> existing extended attributes remain in sync.

Alright, I built two kernels, both with makeoptions DEBUG=-g,
ADAPTIVE_GIANT, MUTEX_DEBUG, WITNESS, KDB, KDB_TRACE, DDB, DDB_NUMSYM,
GDB, SYSCTL_DEBUG, DEBUG_MEMGUARD, KTRACE, KTRACE_REUQEST_POOL=101,
INVARIANTS, INVARIANTS_SUPPORT, DIAGNOSTIC, KDB_STOP_NMI.

One of them with UFS_ACLS, UFS_EXTATTR, UFS_EXTATTR_AUTOSTART and the
other without (both with UFS_DIRHASH).

Booting the one without the extattr options, I was able to mount the
filesystem without getting a panic, but encountered a LOR upon
umount.

lock order reversal:
 1st 0xc50416dc vnode interlock (vnode interlock) @
	 /usr/src/sys/kern/vfs_subr.c:2430
 2nd 0xc1060144 system map (system map) @ /usr/src/sys/vm/vm_kern.c:295
KDB: stack acktrace:
witness_checkorder(c1060144,9,c081f0f8,127,eaad4990) at 0xc060f8df = 
	witness_checkorder+0x5bf
_mtx_lock_flags(c1060144,0,c081f0f8,127,321) at 0xc05da594 =
	_mtx_lock_flags+0x54
_vm_map_lock(c10600c0,c081f0f8,127,8,c106c468) at 0xc072a8e5 = 
	_vm_map_lock+0x35
kmem_malloc(c10600c0,1000,101,101,8) at 0xc0729cdc = kmem_malloc+0x3c
slab_zalloc(9,c081e180,8a2,c4fae780,c4fae7f8) at 0xc07201d2 =
 	slab_zalloc+0x82
uma_zone_slab(c106c468,8,c081e180,8a2,0) at 0xc072071e =
 	uma_zalloc_internal+0x3e
bucket_alloc(c10440a8,0,c081e180,95e,c10440a0) at 0xc0720c09 =
	bucket_alloc+0x29
uma_zfree_arg(c1042000,c503121c,0,eaad4ae4,c06e98f8) at 0xc0721d86 =
	uma_zfree_arg+0x2d6
mac_labelzone_free(c503121c,c5041660,eaad4b00,c064b9fe,c5041660)
	at 0xc06e04d0 = mac_labelzone_free+0x20
mac_destroy_vnode(c5041660,0,c080fb66,2ff,c080fb66) at 0xc06e98f8 =
	mac_destroy_vnode+0x18
vdropl(c0849ee0,eaad4b28,c080fb66,8e8,c4f87444) at 0xc064b9fe =
	vdropl+0x11e
vflush(c4f87400,0,0,c4fae780,c081ccbc) at 0xc064da58 = vflush+0x378
ffs_flushfiles(c4f87400,0,c4fae780,c070b376,0) at 0xc070a19a =
	ffs_flushfiles+0x4a
softdep_flushfiles(c4f87400,0,c4fae780,c4f6ea00,0) at 0xc07096f3 = 
	softdep_flushfiles+0x33
ffs_unmount(c4f87400,8000000,c4fae780,c4fae780,0) at 0xc070b470 =
	ffs_unmount+0x40
dounmount(c4f87400,8000000,c4fae780,37e,42262023) at 0xc0647b97 =
	dounmount+0x1e7
unmount(c4fae780,eaad4d04,c0828274,3c6,2) at 0xc0648091 =
	unmount+0x211
syscall(3b,3b,3b,804aa92,804d6a1) at 0xc07a40ec = syscall+0x14c
Xint0x80_syscall() at 0xc078e9df = Xint0x80_syscall+0x1f
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x480c1c3f, 
	esp = 0xbfbfe40c, ebp = 0xbfbfe4c8 ---

Booting the kernel with the extattr options, the system panic'ed
when I tried to mount the filesystem.

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0xd76f7004
fault code              = supervisor read, page not present
instruction pointer     = 0x20:0xc0712adc
stack pointer           = 0x28:0xe5e10680
frame pointer           = 0x28:0xe5e106d8
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, press 1, def32 1, gran 1
processor flags         = interrupt enabled, resume, IOPL = 0
current process         = 657 (mount)
[thread pid 657 tid 100055 ]
Stopped at      0xc0712adc = ufs_dirhash_build+0x6ac:
   	movzwl  0x4(%ecx),%ebx
db> trace
Tracing pid 657 tid 100055 td 0xc4c93d80
ufsdirhash_build(c53b38c4,c4c93d80,c1044b48,351,e5e1070c) at 0xc0712adc =
 	ufs_dirhash_build+0x6ac
ufs_lookup(e5e10824,c4f8f000,400,e5e10810,0) at 0xc0716093 = 
	ufs_lookup+0xf3
ufs_extattr_lookup(c08204f9,e5e10860,c4c93d80,c4c93d80,c5246800) 
	at 0xc07143c4 = ufs_extattr_lookup+0xf4
ufs_extattr_autostart(c4d41400,c4c93d80,c559f000,c558c300,c558c300) 
	at 0xc0714aa6 = ufs_extattr_autostart+0x76
ffs_mount(c4d41400,c4v93d80,e5e10acc,2c7,0) at 0xc070da76 = 
	ffs_mount+0x2066
vfs_donmount(e5e10bf4,e5e10d04,c4f9cd00,e,c0648ac2) at 0xc0647637 = 
	vfs_donmount+0xb07
kernel_mount(c4f48840,0,e5e10c38,6c,bfbfeb96) at 0xc06490a0 = 
	kernel_mount+0xb0
ffs_cmount(c4f48840,bfbfddc0,0,c4c93d80,0) at 0xc070a16d = 
	ffs_cmount+0x8d
mount(c4c93d80,e5e10d04,c082b2a7,3c6,4) at 0xc0648de5 = mount+0x175
syscall(3b,3b,3b,bfbfddbc,bfbfe854) at 0xc07a6c2c = syscall+0x14c
Xint0x80_syscall() at 0xc079151f = Xint0x80_syscall+0x1f
--- syscall (21, FreeBSD ELF32, mount), eip = 0x480c2c5f, 
	esp = 0xbfbfdd9c, ebp = 0xbfbfde48 ---
db> show alllocks
Process 657 (mount) thread 0xc4c93d80 (100055)
exclusive sleep mutex Giant r = 1 (0xc0887780) locked @ 
	/usr/src/sys/kern/vfs_lookup.c:197
db> 

The fs was fsck'ed before each mounted and always reported clean.
I use 'src/sys/ufs/ufs/ufs_extattr.c,v 1.81.2.1 2005/10/15 18:32:55'.

I hope this new information helps you.

Joerg

-- 
| /"\   ASCII ribbon   |  GnuPG Key ID | c7e4 d91d 64e2 6321 9988 |
| \ / campaign against |    0xb248b614 | f27a 4e5b 06ce b248 b614 |
|  X    HTML in email  |       .the next sentence is a lie.       |
| / \     and news     |     .the previous sentence was true.     |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051118/49c70078/attachment.bin