linux-kernel - Re: [PATCH RFC] memcg: revert kmem.tcp accounting

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Sep 2014 15:14:01 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Vladimir Davydov <vdavydov@...allels.com>
Cc:	Michal Hocko <mhocko@...e.cz>, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, cgroups@...r.kernel.org,
	Li Zefan <lizefan@...wei.com>,
	"David S. Miller" <davem@...emloft.net>,
	Johannes Weiner <hannes@...xchg.org>,
	Kamezawa Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Glauber Costa <glommer@...il.com>,
	Pavel Emelianov <xemul@...allels.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Thelen <gthelen@...gle.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH RFC] memcg: revert kmem.tcp accounting

Hello, Vladimir.

On Mon, Sep 15, 2014 at 11:42:57AM +0400, Vladimir Davydov wrote:
> > So, I'd love to see this happen too but I don't think we can do this.
> > People use published interface.  The usages might be utterly one-off
> > and mental but let's please not underestimate the sometimes senseless
> > creativity found in the wild.  We simply can't remove a bunch of
> > control knobs like this.
> 
> We definitely can't remove something properly operating and widely used,
> but kmem limits are not working and never worked properly due to lack of
> kmem shrinkers, and furthermore CONFIG_MEMCG_KMEM, which tcp accounting
> is enabled by, is marked as UNDER DEVELOPMENT.

I don't think marking config options as "UNDER DEVELOPMENT" in its
help documentation means anything.  It's a rather silly thing to do.
Not many people pay much attention to the help texts and once somebody
somewhere enabled the option for a distro, it's as free in the wild as
any other kernel feature and CONFIG_MEMCG_KMEM is enabled by a lot of
distros.  The same goes with the "debug" controller.  It doesn't mean
much that it has "debug" in its name.  Once it's out in the wild,
there will be someone making use of it in some weird way.

If a debug feature has to be in the mainline kernel, the fact that
it's a debug feature must be explicitly chosen in each use.  IOW, gate
it by an unwieldy boot param which makes it painfully clear that it's
enabling an unstable debug feature and print out a loud warning
message about it.

As it currently stands, CONFIG_MEMCG_KMEM is as good as any other
enabled kernel option.  The help text saying that it's experimental
does not mean anything especially when it doesn't even depend on
CONFIG_BROKEN.

So, the argument "the option was explained as experimental in help
text" doesn't fly at all.  We can still try to deprecate it gradually
if the cleanup seems worthwhile; however, with v2 interface pending,
I'm not sure how meaningful that'd be.  We'd have to carry quite a bit
of v1 code around anyway and I'd like to keep v1 interface as static
as possible.  No reason to shake that at this point.

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/