On Thu, 11 Dec 2008 12:03:07 +0530 Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> wrote: > * KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> [2008-12-11 10:05:01]: > > > On Wed, 10 Dec 2008 16:52:57 -0800 > > Paul Menage <menage@xxxxxxxxxx> wrote: > > > > > On Wed, Dec 10, 2008 at 4:49 PM, KAMEZAWA Hiroyuki > > > <kamezawa.hiroyu@xxxxxxxxxxxxxx> 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 Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
