linux-kernel - Re: [RFC PATCH] mm: memcontrol: reign in CONFIG space madness

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] [day] [month] [year] [list]

Date:	Thu, 10 Dec 2015 12:15:59 -0500
From:	Johannes Weiner <hannes@...xchg.org>
To:	Michal Hocko <mhocko@...nel.org>
Cc:	Vladimir Davydov <vdavydov@...tuozzo.com>, linux-mm@...ck.org,
	cgroups@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] mm: memcontrol: reign in CONFIG space madness

On Thu, Dec 10, 2015 at 05:12:12PM +0100, Michal Hocko wrote:
> This is what we call a review process. Raise concerns and deal with
> them. My review hasn't implied this would be a show stopper or block
> those change to get merged. I was merely asking whether we can keep
> the code size with a _reasonable_ maintenance burden. If the answer is
> no then I can live with that even when I might not like that fact. That
> has been reflected by a lack of my acked-by.

Everything we do bears a cost, our entire work is making tradeoffs
(with a few exceptions where code is just dumb). So when you bring up
cost, you have to weigh it against what you're trading off. There is
simply no value in saying "this costs X" and nothing else. It's
meaningless on its own. Unless X is so unreasonably large that there
MUST be another way of doing it, and investing the time is worth it.

8K is not unreasonably large given the history and overall trend of
the memcg code. And the only possible tradeoff is to make even more
CONFIG options and encourage balkanization of cgroup users, which is
hardly a reasonable route to go down. So what exactly ARE you saying
when you post `size' results that you don't consider show stoppers?
That you don't like increasing the kernel size? Do you think I do?

Pointing out the unexpected (bugs, excessive cost, design problems) is
part of a healthy review process. Proposing a different tradeoff,
supported by a cost/benefit analysis in both directions is useful.

What's happening here is definitely not a constructive review process.

> You sound as if you had to overrule a nack which sounds like over
> reacting because this is not the case.

Issues raised are usually considered showstoppers unless it's clear
from the way they're raised that we can live with them.

And I'm tired of having the same discussion over and over.
--
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/