On Fri, Dec 12, 2025 at 4:31 AM Eric Chanudet <[email protected]> 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 <[email protected]> > --- > 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 >
