> > > + * This is tricky, because for namespace modification we must take the
> > > + * namespace semaphore. But mntput() is called from various places,
> > > + * sometimes with namespace_sem held. Fortunately in those places the
> > > + * mount cannot yet have MNT_DIRONFILE, or at least that's what I
> > > + * hope...
> > > + *
> > > + * The umounting is done in two stages, first the mount is removed
> > > + * from the hashes. This is done atomically wrt other mount lookups,
> > > + * so it's not possible to acquire a new ref to this dead mount that
> > > + * way.
> > > + *
> > > + * Then after having locked namespace_sem and relocked vfsmount_lock,
> > > + * the mount is properly detached.
> > > + */
> > > +static void umount_dironfile(struct vfsmount *mnt)
> > > + __releases(vfsmount_lock)
> > > +{
> > > + struct nameidata nd;
> >
> > You've got to be kidding. nameidata is *big*. If anything, we want
> > to make detach_mnt() take struct path * instead, but even that is
> > lousy due to recursion.
> >
> > I really don't like what's going on here. The thing is, current code
> > is based on assumption that presence in the mount tree => holding a
> > reference. We _might_ deal with that (there was an old plan to change
> > refcounting logics for vfsmounts), but that sort of games with locks
> > spells trouble. What happens, for example, if namespace gets cloned
> > before you grab namespace_sem?
>
> It _should_ work. The mount in the new namespace will be created
> (with namespace_sem held, so we can't yet free this mount), and then
> dropped, because there are no refs to it.
BTW, I'm not saying I like this. It's pretty ugly and fragile. But
it's damn convenient to get rid of these mounts from mntput().
Is there a better alternative?
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
