On Mon, 1 May 2000, Richard Gooch wrote:
> Alexander Viro writes:
> >
> >
> >
> > On Mon, 1 May 2000, Richard Gooch wrote:
> >
> > > Eric W. Biederman writes:
> > > > Richard Gooch <[EMAIL PROTECTED]> writes:
> > > >
> > > > > Hi, Al. You've previously stated that you consider the multiple
> > > > > mount feature of devfs broken. I agree that there are some races in
> > > > > there. However, I'm not clear on whether you're saying that the entire
> > > > > concept is broken, or that it can be fixed with appropriate loffcking.
> > > > > I've asked this before, but haven't had a response.
> > > >
> > > > 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.
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. 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 feel that it's fundamentally impossible to mount a FS multiple
> > > > > times, please explain your reasoning.
> > > >
> > > > At this point it would make sense to just use the generic multiple
> > > > mount features in the VFS that Alexander has been putting in.
> > >
> > > The generic multi-mount patch is good, but it doesn't solve the
> > > particular problem of mounting with selective exposure.
> >
> > 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.
>
> Yes, I've been thinking about this approach. I'll like to table it for
> now and sort the locking issue out first.
>
> 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
(as of pre7-1) and the only major offend^Wuser of old linkage is autofs4.
Fixable, and I know how to fix it (knfsd is another, but that one is utterly
trivial). So the next steps are
* remove the last traces of ->d_mounts/->d_covers
* remove the checks preventing multiple mounts (they are there to
avoid screwing the old linkage)
* add FS_SINGLE
* add phony superblocks for pipe and socket inodes.
* switch shmfs and possibly devpts to FS_SINGLE stuff.
* union-mounts.
It's not that far, considering that in the beginning of April list was
several times longer.
Keep in mind that userland may need to be taught how to deal with getdents()
returning duplicates - there is no reasonable way to serve that in the kernel.
