linux-kernel - Re: [PATCH rfc 0/5] mm: introduce shrinker sysfs interface

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: <20220419211055.jtzfvqagsiwrco6r@moria.home.lan>
Date:   Tue, 19 Apr 2022 17:10:55 -0400
From:   Kent Overstreet <kent.overstreet@...il.com>
To:     Roman Gushchin <roman.gushchin@...ux.dev>
Cc:     linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
        Dave Chinner <dchinner@...hat.com>,
        linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        Yang Shi <shy828301@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH rfc 0/5] mm: introduce shrinker sysfs interface

On Tue, Apr 19, 2022 at 11:50:45AM -0700, Roman Gushchin wrote:
> On Tue, Apr 19, 2022 at 02:36:54PM -0400, Kent Overstreet wrote:
> > On Fri, Apr 15, 2022 at 05:27:51PM -0700, Roman Gushchin wrote:
> > > 7) Don't display cgroups with less than 500 attached objects
> > >   $ echo 500 > count_memcg
> > >   $ cat count_memcg
> > >     53 817
> > >     1868 886
> > >     2396 799
> > >     2462 861
> > > 
> > > 8) Don't display cgroups with less than 500 attached objects (sum over all nodes)
> > >   $ echo "500" > count_memcg_node
> > >   $ cat count_memcg_node
> > >     53 810 7
> > >     1868 886 0
> > >     2396 799 0
> > >     2462 861 0
> > > 
> > > 9) Scan system/root shrinker
> > >   $ cat count
> > >     212
> > >   $ echo 100 > scan
> > >   $ cat scan
> > >     97
> > >   $ cat count
> > >     115
> > 
> > This part seems entirely overengineered though and a really bad idea - can we
> > please _not_ store query state in the kernel? It's not thread safe, and it seems
> > like overengineering before we've done the basics (just getting this stuff in
> > sysfs is a major improvement!).
> 
> Yes, it's not great, but I don't have a better idea yet. How to return the number
> of freed objects? Do you suggest to drop this functionality at all or there are
> other options I'm not seeing?

I'd just drop all of the stateful stuff - or add an ioctl interface.