linux-kernel - Re: [PATCHSET] cgroup, sched: restructure threadgroup locking and replace it with a percpu

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: <20150518163440.GA24861@htj.duckdns.org>
Date:	Mon, 18 May 2015 12:34:40 -0400
From:	Tejun Heo <tj@...nel.org>
To:	lizefan@...wei.com
Cc:	cgroups@...r.kernel.org, mingo@...hat.com, peterz@...radead.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHSET] cgroup, sched: restructure threadgroup locking and
 replace it with a percpu_rwsem

On Wed, May 13, 2015 at 04:35:15PM -0400, Tejun Heo wrote:
> threadgroup locking was added because cgroup needs threadgroups to
> stay stable across attach operations.  It was implemented as a
> per-signal_struct generic locking mechanism so that other users which
> require threadgroups stable across blocking operations can use it too;
> however, it hasn't grown any other use cases and still conditionalized
> on CONFIG_CGROUPS.

Ingo, Peter, what do you guys think?  If you guys are okay with the
changes, how do you want to route the patches?  Given that it's mostly
cgroup-specific and there are more cgroup changes depending on these,
it'd be the easiest to route these through the cgroup tree but putting
it elsewhere and pulling into cgroup is fine too.

Thanks.

-- 
tejun
--
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/