On Fri, 18 Nov 2005 18:59:34 +0000 (GMT) Robert Watson <[EMAIL PROTECTED]> 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. |
pgp8z6jOJf70J.pgp
Description: PGP signature
