From: Ric Wheeler <rwheeler@redhat.com>
To: David Howells <dhowells@redhat.com>,
Alexander Viro <aviro@redhat.com>,
Christoph Hellwig <hch@infradead.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>
Cc: Michal Suchanek <hramrach@centrum.cz>,
Ian Kent <ikent@redhat.com>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
Jeff Moyer <jmoyer@redhat.com>,
miklos@szeredi.hu
Subject: Union mount and lockdep design issues
Date: Sun, 10 Jul 2011 09:28:46 +0100 [thread overview]
Message-ID: <4E1962BE.8010204@redhat.com> (raw)
In-Reply-To: <2477.1309342656@redhat.com>
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
next prev parent reply other threads:[~2011-07-10 8:29 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-12 15:00 Unionmount status? Michal Suchanek
2011-04-12 20:31 ` Ric Wheeler
2011-04-12 21:36 ` Michal Suchanek
2011-04-13 14:18 ` Jiri Kosina
2011-04-13 15:13 ` Michal Suchanek
2011-04-14 8:38 ` Miklos Szeredi
2011-04-14 9:48 ` Sedat Dilek
2011-04-14 9:58 ` Miklos Szeredi
2011-04-15 11:22 ` Michal Suchanek
2011-04-15 11:31 ` Miklos Szeredi
2011-04-15 11:51 ` Michal Suchanek
2011-04-15 12:29 ` Miklos Szeredi
2011-04-15 12:34 ` Michal Suchanek
2011-04-15 12:48 ` Miklos Szeredi
2011-04-15 21:48 ` Hugh Dickins
2011-04-15 22:18 ` Andreas Dilger
2011-04-18 13:31 ` Michal Suchanek
2011-04-19 20:04 ` [PATCH] tmpfs: implement generic xattr support Miklos Szeredi
2011-04-20 2:18 ` Phillip Lougher
2011-04-20 13:43 ` Miklos Szeredi
2011-04-21 6:59 ` Michal Suchanek
2011-04-21 9:08 ` Miklos Szeredi
2011-04-21 10:59 ` Michal Suchanek
2011-04-21 14:58 ` Jordi Pujol
2011-04-21 15:22 ` Michal Suchanek
2011-04-21 15:43 ` Michal Suchanek
2011-04-21 17:26 ` Miklos Szeredi
2011-04-21 19:17 ` Michal Suchanek
2011-04-20 16:00 ` Serge E. Hallyn
2011-05-12 4:20 ` Hugh Dickins
2011-05-12 7:52 ` Michal Suchanek
2011-05-12 12:27 ` Miklos Szeredi
2011-05-12 14:00 ` Miklos Szeredi
2011-05-12 16:52 ` Hugh Dickins
2011-04-18 13:34 ` Unionmount status? Michal Suchanek
2011-04-18 13:37 ` Michal Suchanek
2011-04-13 17:26 ` Ric Wheeler
2011-04-13 18:58 ` Michal Suchanek
2011-04-13 19:11 ` Ric Wheeler
2011-04-13 19:47 ` Michal Suchanek
2011-04-14 4:50 ` Ian Kent
2011-04-14 9:32 ` Michal Suchanek
2011-04-14 9:40 ` Miklos Szeredi
2011-04-14 13:21 ` Ric Wheeler
2011-04-14 14:54 ` Michal Suchanek
2011-04-15 16:31 ` Ric Wheeler
2011-04-14 19:14 ` David Howells
2011-06-29 9:39 ` Union mount and overlayfs bake off? Ric Wheeler
2011-06-29 11:40 ` Michal Suchanek
2011-06-29 10:17 ` David Howells
2011-06-30 12:44 ` Miklos Szeredi
2011-07-10 8:28 ` Ric Wheeler [this message]
2011-07-10 13:48 ` Union mount and lockdep design issues Peter Zijlstra
2011-07-11 8:35 ` Michal Suchanek
2011-07-11 11:01 ` David Howells
2011-07-11 12:00 ` Peter Zijlstra
2011-07-11 13:36 ` Michal Suchanek
2011-07-11 13:50 ` Ian Kent
2011-07-11 16:17 ` Michal Suchanek
2011-07-11 17:23 ` Ian Kent
2011-07-11 18:08 ` Michal Suchanek
2011-07-12 8:30 ` Miklos Szeredi
2011-07-12 9:58 ` Michal Suchanek
2011-07-12 11:45 ` Miklos Szeredi
2011-07-12 18:49 ` Michal Suchanek
2011-07-13 9:49 ` Miklos Szeredi
2011-07-13 12:02 ` David Howells
2011-07-13 13:20 ` Miklos Szeredi
2011-07-14 0:57 ` David Howells
2011-07-11 13:54 ` David Howells
2011-07-11 14:02 ` Peter Zijlstra
2011-07-11 14:50 ` [PATCH 1/2] VFS: Pass mount flags to sget() David Howells
2011-07-11 14:50 ` [PATCH 2/2] union-mount: Duplicate the i_{, dir_}mutex lock classes and use for upper layer David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E1962BE.8010204@redhat.com \
--to=rwheeler@redhat.com \
--cc=aviro@redhat.com \
--cc=dhowells@redhat.com \
--cc=hch@infradead.org \
--cc=hramrach@centrum.cz \
--cc=ikent@redhat.com \
--cc=jmoyer@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).