RELENG_6 vm_fault panic on filesystem mount

[Robert Watson]

On Fri, 18 Nov 2005, Joerg Pernfuss wrote:

> #6  0xc078806a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> #7  0xc070c00c in ufsdirhash_build (ip=0xc5426948) at /usr/src/sys/ufs/ufs/ufs_dirhash.c:232
> #8  0xc070f5c3 in ufs_lookup (ap=0xeabb6824) at /usr/src/sys/ufs/ufs/ufs_lookup.c:192
> #9  0xc070d8f4 in ufs_extattr_lookup (start_dvp=0xc5414dd0, lockparent=0x2, dirname=0xd71f3000 "\002", vp=0xd71f3000, td=0xc5558780) at /usr/src/sys/
> ufs/ufs/ufs_extattr.c:274
> #10 0xc070dfd6 in ufs_extattr_autostart (mp=0xc4ca3000, td=0xc5558780) at /usr/src/sys/ufs/ufs/ufs_extattr.c:463
> #11 0xc0706fa6 in ffs_mount (mp=0xc4ca3000, td=0xc5558780) at /usr/src/sys/ufs/ffs/ffs_vfsops.c:779
> #12 0xc0640d57 in vfs_donmount (td=0xc5558780, fsflags=0x8008, fsoptions=0xeabb6bf4) at /usr/src/sys/kern/vfs_mount.c:739
> #13 0xc06427c0 in kernel_mount (ma=0xc5235240, flags=0x0) at pcpu.h:162

The UFS1 extended attribute code performs directory listings, lookups, and 
file operations very early in the "life cycle" of a UFS file system in 
order to identify attribute backing files.  We could be looking at a bug 
or new negative interaction between the extended attribute code in UFS1, 
dirhash, and the changes to VFS required to get SMP VFS support in 6.x. 
In principle, however, the EA code waits until everything is "ready to go" 
before starting on file system I/O.  Are you actively using UFS1 
attributes on that file system?  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.

Robert N M Watson