And it's been almost 2 years since i wrote about it.
Workaround (commenting out panic call) doesnt fix the problem.
Server still crashes (not so often though) from virtual memory failures like this:
panic: vm_fault: fault on nofault entry, addr: d0912000
mp_lock = 01000002; cpuid = 1; lapic.id = 00000000
boot() called on cpu#1
(kgdb) bt
#0 0xc0175662 in dumpsys ()
#1 0xc017542c in boot ()
#2 0xc0175894 in poweroff_wait ()
#3 0xc01e7c18 in vm_fault ()
#4 0xc0219d32 in trap_pfault ()
#5 0xc021990b in trap ()
#6 0xc01e008a in ufs_dirrewrite ()
#7 0xc01e31a4 in ufs_rename ()
#8 0xc01e4645 in ufs_vnoperate ()
#9 0xc01a9121 in rename ()
#10 0xc021a44d in syscall2 ()
#11 0xc02077cb in Xint0x80_syscall ()
How can i help to resolve this problem ASAP?
Thanks!
Matt Dillon wrote:
Well, I've gone through hell trying to fix the rename()/rmdir()/remove()
races and failed utterly. There are far more race conditions then even
my last posting indicated, and there are *severe* problems fixing NFS
to deal with even Ian's suggestion... it turns out that NFS's nfs_namei()
permanently adjusts the mbuf while processing the path name, making
restarts impossible.
The only solution is to implement namei cache path locking and formalize
the 'nameidata' structure, which means ripping up a lot of code because
nearly the entire code base currently plays with the contents of 'nameidata' willy-nilly. Nothing else will work. It's not something
that I can consider doing now.
In the mean time I am going to remove the panic()'s in question. This
means that in ufs_rename() the machine will silently ignore the race (not do the rename) instead of panic. It's all that can be done for
the moment. It solve the security/attack issue. We'll have to attack
the races as a separate issue. The patch to remove the panics is utterly
trivial and I will commit it after I test it.
-Matt
-- Yevgeniy Aleynikov | Sr. Systems Engineer - USE InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 Tel 425.709.8214 | Fax 425.201.6160 | Mobile 425.418.8924 [EMAIL PROTECTED] | http://www.infospaceinc.com
Discover what you can do.TM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
