linux-kernel - Re: [PATCH 2/4] mm: Add a .to

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: <YmKd2iHTHuzaTkE6@dhcp22.suse.cz>
Date:   Fri, 22 Apr 2022 14:21:46 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Kent Overstreet <kent.overstreet@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org, roman.gushchin@...ux.dev,
        hannes@...xchg.org
Subject: Re: [PATCH 2/4] mm: Add a .to_text() method for shrinkers

On Thu 21-04-22 19:48:26, Kent Overstreet wrote:
> This adds a new callback method to shrinkers which they can use to
> describe anything relevant to memory reclaim about their internal state,
> for example object dirtyness.
> 
> This uses the new printbufs to output to heap allocated strings, so that
> the .to_text() methods can be used both for messages logged to the
> console, and also sysfs/debugfs.
> 
> This patch also adds shrinkers_to_text(), which reports on the top 10
> shrinkers - by object count - in sorted order, to be used in OOM
> reporting.

Let's put aside whether doing the sorting is useful or not for a moment.
The primary concern I have here is that pr_buf is internally relying on
memory allocations. This makes it really risky to use from the OOM path
which is the primary motivation here AFAICS.

Especially the oom killer path where we _know_ the memory is depleted.
The only way to pursue the allocation is to rely on PF_MEMALLOC and
memory reserves.

If you want to have a generic way to dump shrinker's internal state then
those would really need a prellocated buffer and .to_text would need to
be documented to not depend on any locking that could be directly or
indirectly depending on memory allocations.

> Signed-off-by: Kent Overstreet <kent.overstreet@...il.com>
> ---
>  include/linux/shrinker.h |  5 +++
>  mm/vmscan.c              | 75 ++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 80 insertions(+)
-- 
Michal Hocko
SUSE Labs