linux-kernel - Re: [ckrm-tech] [PATCH 1/7] containers (V7): Generic container system abstracted from cpusets code

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070311123843.a16a1555.pj@sgi.com>
Date:	Sun, 11 Mar 2007 12:38:43 -0700
From:	Paul Jackson <pj@....com>
To:	vatsa@...ibm.com
Cc:	menage@...gle.com, sekharan@...ibm.com,
	ckrm-tech@...ts.sourceforge.net, linux-kernel@...r.kernel.org,
	xemul@...ru, dev@...ru, containers@...ts.osdl.org,
	ebiederm@...ssion.com, mbligh@...gle.com, winget@...gle.com,
	rohitseth@...gle.com, serue@...ibm.com, devel@...nvz.org
Subject: Re: [ckrm-tech] [PATCH 1/7] containers (V7): Generic container
 system abstracted from cpusets code

vatsa wrote:
> Yes, that way only the hierarchy hosting cpusets takes the hit of
> double-locking. cpuset_subsys->create/destroy can take this additional lock 
> inside cpuset.c.

The primary reason for the cpuset double locking, as I recall, was because
cpusets needs to access cpusets inside the memory allocator.  A single,
straight forward, cpuset lock failed under the following common scenario:
 1) user does cpuset system call (writes some file below /dev/cpuset, e.g.)
 2) kernel cpuset code locks its lock
 3) cpuset code asks to allocate some memory for some cpuset structure
 4) memory allocator tries to lock the cpuset lock - deadlock!

The reason that the memory allocator needs the cpuset lock is to check
whether the memory nodes the current task is allowed to use have changed,
due to changes in the current tasks cpuset.

A secondary reason that the cpuset code needs two locks is because the
main cpuset lock is a long held, system wide lock, and various low
level bits of performance critical code sometimes require quick,
read-only access to cpusets.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@....com> 1.925.600.0401
-
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/