Date: Tue, 4 Jul 1995 15:08:28 +1000 From: Bruce Evans <bde@zeta.org.au> To: bugs@FreeBSD.org, uhclem%nemesis@fw.ast.com Cc: joerg_wunsch@uriah.heep.sax.de Subject: Re: State of Problem 389 (and 392)? Message-ID: <199507040508.PAA10185@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Has anybody looked into problem 389 since it was reported back in May? This Yes. >had to do with the filesystem being corrupted by lots of file/directory >deletions and file/directory creations going on at the same time. You >eventually end up with directories that can't be deleted by rmdir because the >link counts are wrong. Then you must run fsck two or three times to >completely straighten-out things. This still happens in 2.0.5R. AFAIR the problem showed up here on a small file system (10MB) but not on a larger otherwise empty file system (512MB) and a pre-2.0.5R change seemed to fix it. >There was a similar problem with DOS file systems that was reported under >392 and has apparently been closed, but I see no evidence of it being fixed. >If anyone knows what happened to 392, I'd like to know. Thanks. I changed its state from open to open-analyzed. Apparently the weekly list of open PR's doesn't include open-analyzed PR's. Joerg, please fix this. You should have got mail about the change: --- State-Changed-From-To: open-analyzed State-Changed-By: bde State-Changed-When: Sat May 27 17:39:13 PDT 1995 State-Changed-Why: msdosfs locking is broken as designed. Deadlock is possible in msdosfs_lookup because the directory buffer is not released before attempting to lock the denode. Another process may have the denode locked and be waiting for the directory buffer to be unlocked. --- I haven't made any progress fixing this. msdosfs locks the directory buffer where ufs would lock the inode. The fix presumably involves locking only the in-core msdosfs inode (the denode). I didn't want to risk changing this for 2.0.5 and haven't had time to look at it since. Deadlock is less serious than the race conditions in msdosfs_rename() and ufs_rename(). I sent the following mail to freebsd-hackers about races in ufs_rename(): --- ufs_rename() tries hard to avoid races and deadlocks. I think it fails to avoid serious races in 2 places: 1) After looking up the source and before reaching ufs_rename(). The parent directory of the source isn't locked (locking might cause deadlock), so the source directory entry may be moved or deleted. This need not be serious, but it can cause a panic in the `doingdirectory' case when the source is unlinked. IN_RENAME was supposed to stop the source directory entry from being moved and an extra link was supposed to stop it being deleted, but these tricks are done too late. 2) In the `doingdirectory && newparent' case, when ufs_checkpath() is called, all locks on the target directories are released (hanging on to them might cause deadlock), so the target directories may be moved or deleted. I tested this by adding a tsleep() to ufs_checkpath() before the call to VFS_VGET() and had no difficulty moving the target directory to a bad place (a subdirectory of the source) while ufs_checkpath() was sleeping. ufs_rename() should at least check that relookup() of the target produces the same inode like it does for the source. --- msdosfs_rename() essentially ignores all of the races in (1), and has the same problem() in (2). Excessive (deadlock-enhancing) locking in msdosfs_lookup() probably reduces the races in msdosfs_rename(). >Here is the 389 report again. There's no need to send it again. It's in the PR database. I'm not sure how (if) the database can be queried if you don't have an account on freefall, however. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507040508.PAA10185>