linux-kernel - Re: Union mount and lockdep design issues

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1408.1310382069@redhat.com>
Date:	Mon, 11 Jul 2011 12:01:09 +0100
From:	David Howells <dhowells@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	dhowells@...hat.com, Ric Wheeler <rwheeler@...hat.com>,
	Alexander Viro <aviro@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...e.hu>,
	Michal Suchanek <hramrach@...trum.cz>,
	Ian Kent <ikent@...hat.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, Jeff Moyer <jmoyer@...hat.com>,
	miklos@...redi.hu
Subject: Re: Union mount and lockdep design issues

Peter Zijlstra <peterz@...radead.org> wrote:

> > > The main problem I've got is that it causes lockdep to generate warnings
> > > when the top layer and one of the lower layers are of the same
> > > filesystem type.  The obvious way round this is to give each superblock
> > > its own i_mutex lock class rather than putting this in the
> > > file_system_type struct, but I'm not sure of the consequences (the two
> > > obvious problems are superblock transience and the fact that there may
> > > be so many more of them that it may explode lockdep).
> 
> Can't, that would involve classes in dynamically allocated memory (as
> you cannot a-priori determine how many instances there will be of a
> particular sb). There a number of good (although at times rather
> frustrating) reasons why lockdep cannot do dynamic memory.

What does this mean for filesystem modules that get removed and inserted
again?  That's something I do during development rather than rebooting the
machine.

> Most of those arguments center around things like: allocating memory
> involves locks, therefore we could end up wanting to allocate memory
> while in the allocator etc.

I'm not sure what these arguments are.  Initialising the lock class doesn't
need to be done with any locks held.

I assumed the problems came from key reuse and the storage of out-of-date
keys, and an over-abundance of keys, where a lock class's key is simply the
pointer to its struct.

> Also, why would you want to have a class per sb-instance? From last
> talking to David, he said there could only ever be 2 filesystems
> involved in this, the top and bottom, and it is determined on (union)
> mount time which is which.

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.

However, I was wondering that if in the future it could be possible to make it
possible to union over a union.  I think that conceptually it shouldn't be that
hard, but definitely lockdep presents a barrier unless the top union goes
behind the scenes of the lower union and interacts with its lowerfs's directly.

> I'm also assuming that once a filesystem is part of a union mount, it
> cannot be accessed from outside of said union (can it? can the botton be
> itself be the top layer of another union?)

Not at the moment; the hard read-only requirements on the lowerfs versus the
writeability requirements of the upperfs (you can't enter a directory that you
can't mirror up) prevent it.

However, at some point I'd be interested in trying to make it possible to union
over a writeable filesystem.  This is pretty much a requirement for unioning
over NFS (as you can't tell the server to make the volume you're mounting hard
read-only).

> Therefore, why can't we, on constructing the union layers, reset the lock
> classes?

Reset in what sense?

> Also, in what state are the filesystems on construction of the union?  Are
> they already fully formed and populated (do inodes already exist?)

The lower filesystems must be fully formed and, at present, may not be modified
whilst in the union.

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.

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