Messages in this thread | | | Date | Sun, 10 Oct 1999 01:14:32 -0400 (EDT) | From | Alexander Viro <> | Subject | Re: [PATCH] devfs v123 available |
| |
On Sat, 9 Oct 1999, Richard Gooch wrote:
[snip] > Even many of the "technical" points raised are a mixture of FUD, myth > and ignorance. Or simply a lack of *careful* reading of the FAQ or > source. Just one simple example: Alex and Ted's assertion that devfs > can only be mounted once. Have a look around line 45 of the FAQ for > the facts.
Ted misread my posting. What I'm saying is that once you mounted it several times you are in for races. You can forget about the dir->i_sem protection, since the semaphore is associated with inode and you have different inodes in different instances. _VFS_ is (ab)using the existence of dir->i_sem serialization and it's part of the problem. You have to rely on revalidate and I'ld recommend you to look at the namei.c::cached_lookup. Notice the behaviour of dcache.c::d_invalidate on directory inodes.
BTW, the same thing goes for devfs_unregister() - order of invalidation matters since you may block in between (i.e. big lock doesn't help).
Richard, stuff around ->d_aliases/d_invalidate()/->i_dentry/->i_count/iget() is a large painful mess right now. Most of filesystems do not notice it, but those who go for invalidation usage are stumbling into this mess. Especially if they support links. Doubly so if they can be mounted several times. It's a VFS problem compounded by several misuses of ->i_dentry that block more-or-less obvious fixes. Sigh... The fact that i_sem is used for dcache protection also doesn't help.
Could we please take it into email or on fsdevel? Cheers, Al
- 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/
| |