On Thu, 11 Dec 2008 12:03:07 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
> * KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> [2008-12-11 10:05:01]: > > > On Wed, 10 Dec 2008 16:52:57 -0800 > > Paul Menage <[EMAIL PROTECTED]> wrote: > > > > > On Wed, Dec 10, 2008 at 4:49 PM, KAMEZAWA Hiroyuki > > > <[EMAIL PROTECTED]> wrote: > > > > > > > > an operation like rmdir() in somewhere. > > > > hierarchy_lock for A (acquired) > > > > hierarchy_lock for B (waiting) > > > > > > > > in subsys A. > > > > mmap_sem (acquired) > > > > hierarchy_lock for A (waiting) > > > > in subsys B. > > > > hierarchy_lock for B (aquired) > > > > mmap_sem (waiting) > > > > > > > > > > That's a valid deadlock - you'd need to require the mmap_sem nests > > > either inside all hierarchy_mutexes or else outside all of them. > > > > > This was a found dead lock between memcg and cpuset. > > > > another one was > > > > an operation like rmdir() in somewhere. > > hierarchy_lock for memcg (acquired) > > hierarchy_lock for B (waiting) > > > > in subsys B. > > hierarchy_lock for B (aquired) > > But then the hierarchy_locks acquired will be different right? > yes. > > have to do some memory reclaim -> hierarchy_lock for memcg > > (waiting) > > > > I have no objections to hierarchy_lock itself but calling context to memcg > > is very > > complicated and simple replace of these locks will be just a small help. > > Could you please explain the race better? > I explained... One example was mmap_sem. above one is recursive lock in cpuset you tried to fix. (Fortunately, cpuset's subsys ID is smaller than memcg's one. you'll not see in real environment.) And there are other unknown subsyses are planned, bio, checkpoint, etc.. Could you write a document to explain what kind of nest of locks are allowed before merging this ? Thanks, -Kame _______________________________________________ Containers mailing list [EMAIL PROTECTED] https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel
