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. :\

Userspace components using the system heap can be constrained with, e.g: systemd-run --user --scope -p MemoryMax=10M ...

Signed-off-by: Eric Chanudet echanude@redhat.com

drivers/dma-buf/heaps/system_heap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c index 4c782fe33fd4..c91fcdff4b77 100644 --- a/drivers/dma-buf/heaps/system_heap.c +++ b/drivers/dma-buf/heaps/system_heap.c @@ -38,10 +38,10 @@ struct dma_heap_attachment { bool mapped; };

-#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO) +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_ACCOUNT) #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \ | __GFP_NORETRY) & ~__GFP_RECLAIM) \

•                           | __GFP_COMP)
  

•                           | __GFP_COMP | __GFP_ACCOUNT)
  

static gfp_t order_flags[] = {HIGH_ORDER_GFP, HIGH_ORDER_GFP, LOW_ORDER_GFP}; /*

• The selection of the orders used for allocation (1MB, 64K, 4K) is designed

-- 2.52.0