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]

Date:	Mon, 11 Jul 2011 10:35:28 +0200
From:	Michal Suchanek <hramrach@...trum.cz>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Ric Wheeler <rwheeler@...hat.com>,
	David Howells <dhowells@...hat.com>,
	Alexander Viro <aviro@...hat.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, 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 10 July 2011 15:48, Peter Zijlstra <peterz@...radead.org> wrote:
> 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?)
>

It can still be accessed, there is nothing preventing access, just
like mount --bind won't prevent access to the original location.

It might be possible to block access to it but it would be another
artifical limitation.

Thanks

Michal
--
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/