lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 11 Dec 2008 10:05:01 +0900 From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> To: Paul Menage <menage@...gle.com> Cc: balbir@...ux.vnet.ibm.com, containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org, akpm@...ux-foundation.org Subject: Re: [RFC][PATCH 2/3] CGroups: Use hierarchy_mutex in memory controller On Wed, 10 Dec 2008 16:52:57 -0800 Paul Menage <menage@...gle.com> wrote: > On Wed, Dec 10, 2008 at 4:49 PM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@...fujitsu.com> 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) 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. -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists