On 10 July 2011 15:48, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
