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: <20140825144009.GB31066@mtj.dyndns.org>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ