[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1112061547530.15884@chino.kir.corp.google.com>
Date: Tue, 6 Dec 2011 15:53:47 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Andrew Morton <akpm@...ux-foundation.org>,
Mike Galbraith <efault@....de>
cc: Paul Menage <paul@...lmenage.org>,
LKML <linux-kernel@...r.kernel.org>,
Tejun Heo <htejun@...il.com>, Li Zefan <lizf@...fujitsu.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [patch-final] Re: patch] cpusets, cgroups: disallow attaching
kthreadd
On Tue, 6 Dec 2011, Andrew Morton wrote:
> > Ping #2?
> >
>
> Why am I being pinged about scheduler patches? My sole contribution
> to this one is to point out that "its"->possessive and "it's"->"it is".
>
It touches two areas and there's probably a counter argument on the
otherside about wanting to apply cpuset patches, which typically go
through -mm. It's a patch that, as the changelog indicates, fixes cpusets
from becoming immortal if their set of tasks can never be emptied. Would
you like the change separated into kernel/cpuset.c and kernel/sched.c
portions each referring to each other?
> Also, Peter has said
>
> : I really think that if we want to restrain userspace from doing
> : something stupid we might as well do something that makes sense, and
> : that is mandate kthreadd stays in the root group at all times for
> : everybody.
>
> which appears to be what the patch already did, so I'm confused again.
>
Yes, that's what the patch does. I'm not sure that Peter's explanation
above is any better than what Mike wrote in the changelog, though, the
changelog states why allowing kthreadd to move to a cpuset is actually
troublesome.
> It's time for a fresh resend, IMO.
>
Mike, would you mind resending the patch for the fourth or fifth time? If
not, I'll rebase 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/
Powered by blists - more mailing lists