Re: Union mount and lockdep design issues

[David Howells]

Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:

> At some point lockdep runs out of resources and you'll have to reboot.
> This is true for all module muck.

Fair enough; I guess for normal use, modules just don't get unloaded.

> > There can be more than 2 - one upperfs (the actual union) and many lowerfs -
> > though I think only one lowerfs is accessed at a time.
> 
> Right, however I understood from our earlier discussion that the vfs
> would only ever try to lock 2 filesystems at a time, the top and one
> lower.

That's what I meant by 'only one lowerfs is accessed at a time'.

> Aside from lockdep, how many fs locks will you nest and how will you
> enforce the filesystem relations remain a DAG?

This ought to be fine.  Unionmount requires the superblock for the upperfs be
fresh and unsullied when it gets to union it.  Furthermore, it shouldn't allow
that partition to be mounted elsewhere in a second mount whilst it is still
unioned.  Bind mounts should be okay, since they're effectively a reference on
the union we already have.

> Right, ok, but lets try and make the current situation work first. I
> understand the desire to later grow.

Indeed.

> > The upper filesystem can be empty or filled by a previous union.  In fact,
> > there's nothing stopping the upper fs being an ordinary fs that's then used
> > as the upper layer in a union, but I'm not sure you can then access the
> > lower echelons as the directories don't contain fallthru entries.
> 
> Right, so in both cases they can be fully formed, in that case we'll
> need to iterate all inodes and change their lock class as well.

I think I misunderstood you, then.  'Fully formed' in what sense?  I assumed
you meant populated on disk.

I'll post the two patches I have to deal with this.  The first propagates the
mount flags to sget() and the second makes use of MS_UNION in sget() to key the
locks appropriately.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/