[GIT PULL] cgroup fixes for v3.17-rc4

[GIT PULL] cgroup fixes for v3.17-rc4

[Tejun Heo]

Hello, Linus.

Up until now, cgroup has allowed any character including '\n' in
cgroup names; unfortunately, as '\n' is used as the row delimiter in
/proc/$PID/cgroup, '\n' in a cgroup name makes the content of the file
ambiguous to parse.  This pull request includes Alban's patch to
disallow '\n' in cgroup names.  While this is a userland visible
behavior change, given the craziness of allowing '\n' and its
implications, I believe the change is justified.  The patch is marked
for -stable backport.

Two other patches from Li to fix a possible oops when cgroup
destruction races against other file operations and one from Vivek to
fix a unified hierarchy devel behavior.

Thanks.

The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9:

  Linux 3.17-rc1 (2014-08-16 10:40:26 -0600)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-3.17-fixes

for you to fetch changes up to aa32362f011c6e863132b16c1761487166a4bad2:

  cgroup: check cgroup liveliness before unbreaking kernfs (2014-09-05 01:36:19 +0900)

----------------------------------------------------------------
Alban Crequy (1):
      cgroup: reject cgroup names with '\n'

Li Zefan (2):
      cgroup: delay the clearing of cgrp->kn->priv
      cgroup: check cgroup liveliness before unbreaking kernfs

Vivek Goyal (1):
      cgroup: Display legacy cgroup files on default hierarchy

 kernel/cgroup.c | 47 +++++++++++++++++++++++++++++++++--------------
 1 file changed, 33 insertions(+), 14 deletions(-)

-- 
tejun

Re: [GIT PULL] cgroup fixes for v3.17-rc4

[Linus Torvalds]

On Sun, Sep 7, 2014 at 6:20 PM, Tejun Heo <tj@kernel.org> wrote:
>
>                   While this is a userland visible
> behavior change, given the craziness of allowing '\n' and its
> implications, I believe the change is justified.

Tejun, absolutely nothing "justifies" things if they break. Not "bad
design", not "craziness". Even security issues should be worked around
without breaking, if at all possible,

However, "userland visible" is only relevant _if_ things break.
Presumably nobody actually uses '\n' in a cgroup name. And if nothing
breaks, you don't need the excuses.

In other words, I'll happily pull this, but your excuses for it are
wrong-headed. There is no "crazyness justifies this". That's crap. But
the argument of "nobody does this, so let's fix it before anybody
_starts_ doing it" is perfectly valid - with the deep and implicit
understanding that if it turns out somebody *does* do it, the change
gets reverted asap.

People need to understand this. "Theoretical ABI breakage" is entirely
irrelevant. Nobody cares. But any _actual_ ABI breakage is a complete
no-no.

So next time you realize "ok, this could break things", don't make
excuses. Look for alternatives (maybe the name can be escaped, for
example), or take the approach of "let's hopw nobody notices".

None of this "the interface is crazy, so we can change it".  Because
that is pure and utter BS. Whether the interface is crazy or not is
*entirely* irrelevant to whether it can be changed or not. The only
thing that matters is whether people actually _trigger_ the issue you
have in reality, not whether the issue is crazy.

See the difference?

                 Linus

Re: [GIT PULL] cgroup fixes for v3.17-rc4

[Tejun Heo]

Hello, Linus.

On Sun, Sep 07, 2014 at 08:17:11PM -0700, Linus Torvalds wrote:
> In other words, I'll happily pull this, but your excuses for it are
> wrong-headed. There is no "crazyness justifies this". That's crap. But
> the argument of "nobody does this, so let's fix it before anybody
> _starts_ doing it" is perfectly valid - with the deep and implicit
> understanding that if it turns out somebody *does* do it, the change
> gets reverted asap.

Yeap, that's the intention which I failed to articulate.  It's highly
unlikely to be in use currently and would already be noticeably
breaking things.  Given that it's justified to try to ban '\n' usage
and see whether anybody reports regression from that.  Will describe
similar situations more accruately from now on.

Thanks.

-- 
tejun