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: <1310305703.13309.7.camel@twins>
Date:	Sun, 10 Jul 2011 15:48:23 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Ric Wheeler <rwheeler@...hat.com>
Cc:	David Howells <dhowells@...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

On Sun, 2011-07-10 at 09:28 +0100, Ric Wheeler wrote:
> On 06/29/2011 11:17 AM, David Howells wrote:
> > Ric Wheeler<ricwheeler@...il.com>  wrote:
> >
> >> I think that it has been a while since David reposted the refreshed patch set
> >> for union mounts&  know that overlayfs has recent updates as well.
> >>
> >> Despite that, I have not seen a lot of feedback from reviewers or testers.

> > 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.

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.

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.

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?)

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

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

> Peter, Ingo, are either of you the right people to think about how to fix 
> lockdep to handle stacked components (like ext4 used in union mounts stacked on 
> top of another ext4 fs) where both layers will routinely lock to the same object?

We would be.

> Should we do a specific hack to work around this for union mounts or look for 
> lockdep to change?

I still don't understand the problem at all, so lets start there ;-)
--
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/