Re: kern/93942: panic: ufs_dirbad: bad dir

Update:

Attempting to mount my corrupt /home slice produces the following:

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0xdab2d004
fault code		= supervisor read, page not present
instruction pointer	= 0x20:0xc06ff7d7
stack pointer		= 0x28:0xe9c56514
frame pointer		= 0x28:0xe9c56570
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, def32 1, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 73 (mount)
trap number		= 12
panic: page fault
cpuid = 0
Uptime 23s
Dumping 1023 MB (2 chunks)
  chunk 0: 1MB (159 pages) ... ok
  chunk 1: 1023MB (261748 pages) ... ok

However I am able to mount this same corrupt /home partition with the 
6.1-BETA2 kernel without error.  After tweaking, building and testing my 
custom  KERNCONF the problem seems to be with:

options	UFS_EXTATTR
options	UFS_EXTATTR_AUTOSTART

which according to the src/sys/ufs/ufs/README.* should only effect UFS1.  I 
only use UFS2, so technically I do not need these options.

To sum up: my computer became unresponsive.  Reboot and fsck produced a 
"panic: ufs_dirbad: bad dir".  Many fsck -f runs later 'mount -r /home' 
started causing the "Fatal trap 12: page fault while in kernel mode" panic. 
Booting a kernel without options UFS_EXTATTR & UFS_EXTATTR_AUTOSTART does 
not cause this mount proc kernel panic.  I have a vmcore dump if anyone 
cares to look at it.

Question: Why does fsck mark a UFS2 clean, but a kernel with options 
UFS_EXTATTR & UFS_EXTATTR_AUTOSTART still cause a kernel panic on that one 
UFS2 but none of the other UFS2 slices?

Regarding the src/sys/kern/vfs_cluster.c patch.  All of the testing 
described above was performed with the patch applied.  But the initial 
corruption occurred before the patch.  It would be nice if someone who 
understands that code looked at it, blessed it and got it committed.  We 
will only find out if the patch indeed fixes the ufs_dirbad problem if all 
those who've been bitten by this bug no longer run into this sort of 
corruption over time.

-- 
Yarema