Messages in this thread | | | Date | Tue, 18 Jul 2000 22:30:23 +0200 | From | Manfred Spraul <> | Subject | Re: [patch-2.4.0-test5-pre2] forced umount with a few fixes |
| |
Tigran Aivazian wrote: > > Hi Manfred > > The patch below has the fixes for the problems you mentioned and also one > you didn't mention (the munmap case didn't know about the possibility of > multiple mounted instances per superblock). > > Now I will think about the more serious issues you mentioned: > > a) race with module unload (meaning the corresponding filesystem module's > unload, not nullfs) >
Exactly, it's a special case of b)
> b) need to synchronize with a thread in between fget/fput (is that what > you meant by coda_release() example?) >
Yes. If a thread is within kernel space, touching that filp->f_dentry->d_inode is dangerous.
> c) deadlock with concurrent rename (not sure yet if there is a deadlock > here - need to open my eyes wider :) >
Check fs/namei.c. Al Viro is cursing because the logic is too complicated.
fs layout: /mntpoint /mntpoint/directory /mntpoint/directory/file
thread 1: rename("/mntpoint/directory/file","/mntpoint/file"); thread 2: disable_fd for a fd that points to /mntpoint/directory
It seems that your disable_fd calls down(&root->d_inode->i_sem); /mntpoint down(&inode->i_sem); /mntpoint/directory
The problem is that a rename will acquire i_sem for /mntpoint and /mntpoint/directory as well, but it might to that in a different order (it relies on the memory ordering, see double_down or triple_down)
down(&inode->i_sem); down(&root->d_inode->i_sem);
--> deadlock.
-- Manfred
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |