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

Message-ID: <20151210134031.GN19496@dhcp22.suse.cz>
Date:	Thu, 10 Dec 2015 14:40:31 +0100
From:	Michal Hocko <mhocko@...nel.org>
To:	Johannes Weiner <hannes@...xchg.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 Wed 09-12-15 15:30:04, Johannes Weiner wrote:
> Hey guys,
> 
> there has been quite a bit of trouble that stems from dividing our
> CONFIG space and having to provide real code and dummy functions
> correctly in all possible combinations. This is amplified by having
> the legacy mode and the cgroup2 mode in the same file sharing code.
> 
> The socket memory and kmem accounting series is a nightmare in that
> respect, and I'm still in the process of sorting it out. But no matter
> what the outcome there is going to be, what do you think about getting
> rid of the CONFIG_MEMCG[_LEGACY]_KMEM and CONFIG_INET stuff?

The code size difference after your recent patches is indeed not that
large but that is only because huge part of the kmem code is enabled by
default now. I have raised this in the reply to the respective patch.
This is ~8K of the code 1K for data. I do understand your reasoning
about the complications but this is quite a lot of code. CONFIG_INET
ifdefs are probably pointless - they do not add really much and most
configs will have it by default. The core for KMEM seems to be a
different thing to me. Maybe we can reorganize the code to make the
maintenance easier and still allow to enable KMEM accounting separately
for kernel size savy users?

[...]
-- 
Michal Hocko
SUSE Labs
--
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/