linux-kernel - Re: [PATCH 0/4] memcg: nmi-safe kmem charging

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: <xe443fcnpjf4nozjuzx2lzwjqkhzhkualcwxk4f5y6e5v7d7vl@h47t3oz3ippf>
Date: Fri, 9 May 2025 20:11:55 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Muchun Song <muchun.song@...ux.dev>, 
	Vlastimil Babka <vbabka@...e.cz>, Alexei Starovoitov <ast@...nel.org>, 
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>, bpf@...r.kernel.org, linux-mm@...ck.org, cgroups@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Meta kernel team <kernel-team@...a.com>
Subject: Re: [PATCH 0/4] memcg: nmi-safe kmem charging

Hi Andrew,

On Fri, May 09, 2025 at 06:26:32PM -0700, Andrew Morton wrote:
> On Fri,  9 May 2025 16:28:55 -0700 Shakeel Butt <shakeel.butt@...ux.dev> wrote:
> 
> > BPF programs can trigger memcg charged kernel allocations in nmi
> > context. However memcg charging infra for kernel memory is not equipped
> > to handle nmi context. This series adds support for kernel memory
> > charging for nmi context.
> 
> The patchset adds quite a bit of material to core MM on behalf of a
> single caller.  So can we please take a close look at why BPF is doing
> this?
> 
> What would be involved in changing BPF to avoid doing this, or of
> changing BPF to handle things locally?  What would be the end-user
> impact of such an alteration?  IOW, what is the value to our users of
> the present BPF behavior?
> 

Before answering the questions, let me clarify that this series is
continuation of the work which added similar support for page allocator
and related memcg charging and now the work is happening for
kmalloc/slab allocations. Alexei has a proposal on reentrant kmalloc and
here I am providing how memcg charging for that (reentrant kmalloc)
should work.

Next let me take a stab in answering the questions and BPF folks can
correct me if I am wrong. From what I understand, users can attach BPF
programs at almost any place in kernel and those BPF programs can do
memory allocations. This line of work is to make those allocations work
if the any such BPF attach point is triggered in mni context.

Before this line of work (reentrant page and slab allocators), I think
BPF had its internal cache but it was very limited and can easily fail
allocation requests (please BPF folks correct me if I am wrong). This
was discussed in LSFMM this year as well.

Now regarding the impact to the users. First there will not be any
negative impact on the non-users of this feature. For the value this
feature will provide to users, I think this line of work will make BPF
programs of the users more reliable with better allocation behavior.
BPF folks, please add more comments for the value of these features.

thanks,
Shakeel