Re: [PATCH] dma-buf: system_heap: account for system heap allocation in memcg

["Christian König" <christian.koenig@amd.com>]

On 12/15/25 11:51, Maxime Ripard wrote:
> Hi TJ,
> 
> On Fri, Dec 12, 2025 at 08:25:19AM +0900, T.J. Mercier wrote:
>> On Fri, Dec 12, 2025 at 4:31 AM Eric Chanudet <echanude@redhat.com> wrote:
>>>
>>> The system dma-buf heap lets userspace allocate buffers from the page
>>> allocator. However, these allocations are not accounted for in memcg,
>>> allowing processes to escape limits that may be configured.
>>>
>>> Pass the __GFP_ACCOUNT for our allocations to account them into memcg.
>>
>> We had a discussion just last night in the MM track at LPC about how
>> shared memory accounted in memcg is pretty broken. Without a way to
>> identify (and possibly transfer) ownership of a shared buffer, this
>> makes the accounting of shared memory, and zombie memcg problems
>> worse. :\
> 
> Are there notes or a report from that discussion anywhere?
> 
> The way I see it, the dma-buf heaps *trivial* case is non-existent at
> the moment and that's definitely broken. Any application can bypass its
> cgroups limits trivially, and that's a pretty big hole in the system.

Well, that is just the tip of the iceberg.

Pretty much all driver interfaces doesn't account to memcg at the moment, all the way from alsa, over GPUs (both TTM and SHM-GEM) to V4L2.

> The shared ownership is indeed broken, but it's not more or less broken
> than, say, memfd + udmabuf, and I'm sure plenty of others.
> 
> So we really improve the common case, but only make the "advanced"
> slightly more broken than it already is.
> 
> Would you disagree?

I strongly disagree. As far as I can see there is a huge chance we break existing use cases with that.

There has been some work on TTM by Dave but I still haven't found time to wrap my head around all possible side effects such a change can have.

The fundamental problem is that neither memcg nor the classic resource tracking (e.g. the OOM killer) has a good understanding of shared resources.

For example you can use memfd to basically kill any process in the system because the OOM killer can't identify the process which holds the reference to the memory in question. And that is a *MUCH* bigger problem than just inaccurate memcg accounting.

Regards,
Christian.

> 
> Maxime