Date: Sun, 7 Oct 2001 17:18:26 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Yevgeniy Aleynikov <eugenea@infospace.com> Cc: Kirk McKusick <mckusick@mckusick.com>, Ian Dowse <iedowse@maths.tcd.ie>, Matt Dillon <dillon@earth.backplane.com>, peter@FreeBSD.ORG, ache@FreeBSD.ORG, Ken Pizzini <kenp@infospace.com>, hackers@FreeBSD.ORG Subject: Re: bleh. Re: ufs_rename panic Message-ID: <200110080018.f980IQK01299@earth.backplane.com> References: <200110030610.f936AbR11859@beastie.mckusick.com> <3BBE3F7A.98FBC714@infospace.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200110080018.f980IQK01299>