Alexander Viro writes:
> On Mon, 1 May 2000, Richard Gooch wrote:
> > Alexander Viro writes:
> > > On Mon, 1 May 2000, Richard Gooch wrote:
> > > > Eric W. Biederman writes:
> > > > > Last I saw it was his complaint that you varied what you
> > > > > showed at different mount points, and that doing that all in
> > > > > one dcache tree was fundamentally broken.
> > > >
> > > > But it's not one dcache tree: there is a separate dcache tree for each
> > > > mount of devfs. So I don't understand that complaint.
> > >
> > > There is a lot of places where we do serialization using semaphores in
> > > struct inode. You don't duplicate it all. Think what happens if two
> > > instances operate on the same directory. You've got no locking here.
> >
> > Correct, I have no locking now. But adding locking is on my list of
> > things to do. So, for example, I could put a semaphore in my "struct
> > directory_type" (amongst other places). That would serialise changes.
> >
> > I get the impression you think no amount of locking added to devfs
> > will solve the races, but I don't see why that would be the case.
> >
> > Or are you just saying that it would be a lot of work to get all the
> > locking correct? If that's what bothers you, don't worry. That's my
> > job ;-)
>
> There are dragons. It _is_ tricky and ordering is going to be a
> bitch to deal with - just look what do_rename()/vfs_rename() have to
> do and consider the effects of second system of locks interacting
> with them.
Well, this one is easy deal with: I don't allow renames in devfs.
Never have, and have no intention of doing so (it wouldn't make
sense).
> Besides, basic assumption is that ->i_sem on parent blocks any
> changes of dentry status (coming from other threads, that
> is). Making your revalidate() deal with that nicely... Not an easy
> thing.
Well, my revalidate() already deals with that, and I didn't find it
that hard. Is there a specific concern you have (ignoring the fact I
don't have locking deeper down)?
> And it will be very vulnerable to pretty subtle changes in VFS, ones
> that would never be visible to any other fs. I'm not saying that it
> can't be done - just that it will be either full of holes _or_ hell
> to maintain. Essentially, the code will be so tightly bound to VFS
> details that for all practical purposes it _will_ be a part of
> VFS...
If you're mainly thinking about rename operations, I'd agree. Ordering
locking correctly would be awkward, and fragile to VFS changes.
However, the revalidate() thing is a lot simpler. The main thing I
dislike is that I have to release dir->i_sem, call my revalidate()
method and than grab the semaphore again when doing a lookup().
This is because real_lookup() will not call the revalidate() method
after calling i_op->lookup(). I wish it did. Not only would it be
nicer for me, but conceptually it's cleaner.
> > BTW: when are we likely to have union mounts available?
>
> Umm... Well, let's see. I've got lookup code switched to the new linkage
[...]
> It's not that far, considering that in the beginning of April list
> was several times longer.
So perhaps by the end of May?
That would be good. My first priority is adding locking to my internal
devfs structures, which should fix the races. After that, once union
mounting goes into the tree, I can look at that as an alternative to
mounting devfs multiple times.
Going back to something you said:
> There is one case when you can safely have multiple trees - when
> directories in each tree are read-only. If you union-mount such
> trees you get some selective exposure.
This restriction on both trees being read-only is a problem, though.
The devfs tree will of course be read-write.
The way I'd like it to work is that the sysadmin creates a directory
tree which is a template /dev, containing only selected device nodes.
Then this tree is union-mounted with devfs into a chroot(2) gaol.
Where the template has inodes, lookup() will return the corresponding
inode in devfs. A lookup() where the template has no inode will fail,
of course.
I'm quite happy to impose the restriction that the union-mounted FS is
immutable. I don't think this will block legitimate use. It is of
course different from the way it's done now in devfs (where you mount
it and mknod(2) to expose devices), but that's OK.
Regards,
Richard....
Permanent: [EMAIL PROTECTED]
Current: [EMAIL PROTECTED]
