linux-kernel - Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

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]

Date:	Thu, 5 Apr 2012 15:55:11 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	Tejun Heo <tj@...nel.org>
cc:	Mike Galbraith <mgalbraith@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Menage <paul@...lmenage.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Li Zefan <lizefan@...wei.com>
Subject: Re: [patch 0/2] cpusets, cpu_cgroup: disallow attaching kthreadd

On Thu, 5 Apr 2012, Tejun Heo wrote:

> > The reason we're discussing kthreadd here is because it has the funny 
> > ability to fork other kthreads that become PF_THREAD_BOUND.  Usually the 
> > only PF_THREAD_BOUND threads are ones created at boot.  However, if a 
> > kthread is started for a specific cpu, it gets this bit set to stay on 
> > that cpu via kthread_bind().  That's what causes an inconsistency for only 
> > two types of cgroups: cpusets and cpu and we don't allow them to move 
> > amongst them because of that.
> 
> That and because ramifications of putting kthreadd is difficult to
> predict it being the root of all kthreads.  It's fine to be able to
> put specific kthreads into cgroups if doing such makes sense for that
> type of kthreads.
> 

But it's not fine to put kthreadd in a cgroup to monitor cpu or memory of 
workqueues?  We're using the forking property of attaching all children to 
the same cgroup as its parent.  Modules calling daemonize() get reparented 
to kthreadd but are not moved amongst cgroups in which they were created, 
why wouldn't they be attached to the root cgroup too if you're going to 
mandate this for all cgroups?  We need no cpuset or cpu consideration here 
because daemonize() does not adjust the cpu affinity of the user thread.

> > That's what this patch series addresses.  Please don't unnecessarily limit 
> > our ability with kthreadd or kthreads in general for accounting of system 
> > activity.
> 
> I can see your point but the problem is that it conflicts with the
> long term direction cgroup is taking and that cgroup seems generally
> over-engineered to allow too many things which aren't too necessary to
> the point where it's a giant pain in the ass for the subsystems and
> people involved, so I'm far more likely to go for chopping down and
> restricting stuff if it's not strictly necessary.

How does kthreadd's placement conflict with the long-term direction of 
cgroups?  We don't need to have a hierarchy for monitoring, we can easily 
iterate over all memcgs or cpu cgroups that house kernel threads or other 
daemons and add their memory.usage_in_bytes or cpuacct.usage if we want 
the aggregate.  The point is that we want to monitor the memory and cpu of 
a set of tasks and cgroups is naturally the perfect interface for doing 
this and already has cgroups such as memcg and cpuacct that allow it.
--
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/