linux-kernel - Re: [PATCH] cgroup: Enable controllers for default hierarchy by default.

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:	Mon, 25 Aug 2014 10:40:09 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Dongsheng Yang <yangds.fnst@...fujitsu.com>
Cc:	lizefan@...wei.com, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] cgroup: Enable controllers for default hierarchy by
 default.

Hello, Dongsheng.

On Mon, Aug 25, 2014 at 07:27:32PM +0800, Dongsheng Yang wrote:
> When we create a cgroup in unified hierarchy, we have to enable
> controllers in cgrp_dfl_root.subtree_control manually. From
> my practice, I did not find the benefit we disable controllers
> in cgrp_dfl_root by default.

Hehe, I actually enjoyed the frankness.  No fudging around, basically
just "I used it for a bit and it didn't feel useful to me".

> As I am a newbie to cgroup, please correct me if I am wrong.

I don't think being new to cgroup is important here.  Regardless of
the specific area, you should be able to build and argue the
rationales for the changes you propose.  This is important because not
only the changes need to be justified but also the process will help
you actually think about and analyze the changes that you're
proposing.  If you can't build strong enough rationales for a given
change, it probably shouldn't be proposed.

Here, your rationale is nothing more than "I played with it 5 mins and
it seemed weird to me".  There was no effort in understanding the
overall design, use cases or implications.  You're just driving by
shooting random patches expecting other people to do what you should
have done before submitting the patches.  If you want to change the
behavior, please first study and think about it and ask specific
questions when unsure.  Submitting basically random patches expecting
others to argue for or against it is one of the worst ways to learn
about a subsystem.  Please don't ever do this regardless of the
subsystem in question.

Nacked-by: Tejun Heo <tj@...nel.org>

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/