linux-kernel - Re: [PATCH v6 10/19] mm: memcg/slab: deprecate memory.kmem.slabinfo

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: <20200622180153.GB301338@carbon.dhcp.thefacebook.com>
Date:   Mon, 22 Jun 2020 11:01:53 -0700
From:   Roman Gushchin <guro@...com>
To:     Shakeel Butt <shakeelb@...gle.com>
CC:     Andrew Morton <akpm@...ux-foundation.org>,
        Christoph Lameter <cl@...ux.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Linux MM <linux-mm@...ck.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        Kernel Team <kernel-team@...com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 10/19] mm: memcg/slab: deprecate memory.kmem.slabinfo

On Mon, Jun 22, 2020 at 10:12:46AM -0700, Shakeel Butt wrote:
> On Mon, Jun 8, 2020 at 4:07 PM Roman Gushchin <guro@...com> wrote:
> >
> > Deprecate memory.kmem.slabinfo.
> >
> > An empty file will be presented if corresponding config options are
> > enabled.
> >
> > The interface is implementation dependent, isn't present in cgroup v2,
> > and is generally useful only for core mm debugging purposes. In other
> > words, it doesn't provide any value for the absolute majority of users.
> >
> > A drgn-based replacement can be found in tools/cgroup/slabinfo.py .
> > It does support cgroup v1 and v2, mimics memory.kmem.slabinfo output
> > and also allows to get any additional information without a need
> > to recompile the kernel.
> >
> > If a drgn-based solution is too slow for a task, a bpf-based tracing
> > tool can be used, which can easily keep track of all slab allocations
> > belonging to a memory cgroup.
> >
> > Signed-off-by: Roman Gushchin <guro@...com>
> > Acked-by: Johannes Weiner <hannes@...xchg.org>
> > Reviewed-by: Vlastimil Babka <vbabka@...e.cz>
> 
> Hi Roman,
> 
> I am not against removing the memory.kmem.slabinfo interface but I
> would like to have an alternative solution more accessible than
> tools/cgroup/slabinfo.py.
> 
> In our case, we don't have ssh access and if we need something for
> debugging, it is much more preferable to provide a file to read to
> SREs. After the review, that file will be added to a whitelist and
> then we can directly read that file through automated tools without
> approval for each request.
> 
> I am just wondering if a file interface can be provided for whatever
> tools/cgroup/slabinfo.py is providing.
> 
> Shakeel

Hello, Shakeel!

I understand your point, but Idk how much we wanna make this code a part
of the kernel and the cgroup interface. The problem is that reading
from it will be really slow in comparison to all other cgroup interface
files. Idk if Google's version of SLAB has a list of all slab pages,
but if not (as in generic SLUB case), it requires scanning of the whole RAM.
So it's not suitable for periodic reading "just in case". But also
the absolute majority of users don't need this information.

If for some reason you're not comfortable with deploying drgn, it's fairly
easy to write a small standalone tool (similar to page-types), which will
do the trick. Maybe it can work for you?

Thanks!