lkml.org 
[lkml]   [2011]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Union mount and lockdep design issues
On 10 July 2011 15:48, Peter Zijlstra <peterz@infradead.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@gmail.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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2011-07-11 10:37    [W:1.400 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site