lkml.org 
[lkml]   [2011]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectUnion mount and lockdep design issues
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).
>
> I've split out some of the VFS patches that we might be interested in taking
> upstream anyway. They're currently sat on Al's plate for his consideration.
>
> I've been dealing with some of Al's issues with the unionmount patches, but I
> know he's got more - I just can't remember them all.
>
> David

After sitting down in person to dive into the lockdep issues with David over
some very nice food (thanks David!), it does seem that this is really more of a
lockdep issue and the way it is designed than a union mount issue.

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?

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

Thanks!

Ric




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