From: Steven Rostedt <rostedt@goodmis.org>
To: Vincent Donnefort <vdonnefort@google.com>
Cc: Tao Cui <cui.tao@linux.dev>,
akpm@linux-foundation.org, dgilbert@interlog.com, mkp@kernel.org,
loberman@redhat.com, jmeneghi@redhat.com, kraxel@redhat.com,
vivek.kasireddy@intel.com, mst@redhat.com, jasowangio@gmail.com,
eperezma@redhat.com, stefanha@redhat.com, sgarzare@redhat.com,
mhiramat@kernel.org, jgg@ziepe.ca, kevin.tian@intel.com,
axboe@kernel.dk, linux-mm@kvack.org,
James.Bottomley@hansenpartnership.com, sumit.semwal@linaro.org,
christian.koenig@amd.com, phasta@kernel.org, joro@8bytes.org,
will@kernel.org, linux-scsi@vger.kernel.org,
dri-devel@lists.freedesktop.org, linux-media@vger.kernel.org,
linaro-mm-sig@lists.linaro.org, kvm@vger.kernel.org,
virtualization@lists.linux.dev,
linux-trace-kernel@vger.kernel.org, iommu@lists.linux.dev,
io-uring@vger.kernel.org, linux-kernel@vger.kernel.org,
bobbyeshleman@meta.com, mathieu.desnoyers@efficios.com,
robin.murphy@arm.com, mason@kernel.org, aesteve@redhat.com,
tjmercier@google.com, harry@kernel.org, vbabka@suse.cz,
cuitao@kylinos.cn
Subject: Re: [PATCH 4/7] tracing: account ring buffer pages and trace_array metadata to memcg
Date: Wed, 11 Nov 2026 18:14:47 -0500 [thread overview]
Message-ID: <20261111181447.3c483a50@fedora> (raw)
In-Reply-To: <avScKhR22kFOQ1z4@google.com>
On Wed, 11 Nov 2026 16:47:38 +0000
Vincent Donnefort <vdonnefort@google.com> wrote:
> On Fri, Nov 06, 2026 at 09:18:26PM +0800, Tao Cui wrote:
> > From: Tao Cui <cuitao@kylinos.cn>
> >
> > Creating an instance immediately allocates two full sets of per-cpu
> > ring buffers, array buffer plus snapshot, about 1.375MB per cpu per set
> > on the default config, plus the trace_array and its name. None of it
> > is charged: neither trace.c nor ring_buffer.c passes __GFP_ACCOUNT,
> > while user_events in the same directory accounts everything it
> > allocates.
As the name suggests, "user_events" are for users and are special.
> >
> > Instance creation is currently gated by tracefs file permissions
> > alone, so a
> > rootful container with the host tracefs bound in can create instances
> > until the host runs out of memory.
You mean, "works as expected"?
> Charge the ring buffer pages and
> > the trace_array metadata to the creating cgroup.
> >
> > Signed-off-by: Tao Cui <cuitao@kylinos.cn>
> > ---
> > kernel/trace/ring_buffer.c | 8 +++++++-
> > kernel/trace/trace.c | 6 +++---
> > 2 files changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
> > index 1fd28a72e6ee..676c059c112c 100644
> > --- a/kernel/trace/ring_buffer.c
> > +++ b/kernel/trace/ring_buffer.c
> > @@ -441,7 +441,13 @@ static struct buffer_data_page *alloc_cpu_data(int cpu, int order)
> > * gracefully without invoking oom-killer and the system is not
> > * destabilized.
> > */
> > - mflags = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO;
> > + /*
> > + * The subbuffers are charged to the memcg of whoever caused the
> > + * allocation: the creator of a trace instance, or root at boot for
> > + * the global trace.
> > + */
> > + mflags = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_COMP | __GFP_ZERO |
> > + __GFP_ACCOUNT;
> >
> > page = alloc_pages_node(cpu_to_node(cpu), mflags, order);
> > if (!page)
>
> Hum, by default tracefs is root only.
>
> And even if made accessible to other users:
>
> 1. The life span of a trace instance is not tied to the caller.
> 2. The ring buffer is shared by multiple users.
Right. Is there a use case out there that allows non-admin to create an
instance? Tracing ring buffers can expose a lot and should not be given
to unprivileged users.
What exactly is this trying to achieve?
-- Steve
>
> Overall I am not convinced charging the creator makes much sense.
>
> Eventually a few allocations for iterators could be GFP_ACCOUNT.
>
next prev parent reply other threads:[~2026-11-11 23:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-06 13:18 [PATCH 0/7] memcg: account the remaining uncharged kernel allocations Tao Cui
2026-11-06 13:18 ` [PATCH 1/7] scsi: sg and st: account the command buffer memory to memcg Tao Cui
2026-11-06 13:18 ` [PATCH 2/7] dma-buf/udmabuf: account the page array metadata " Tao Cui
2026-11-06 13:23 ` Christian König
2026-11-06 17:25 ` T.J. Mercier
2026-11-09 2:32 ` Tao Cui
2026-11-09 10:56 ` Christian König
2026-11-09 13:44 ` Albert Esteve
2026-11-06 13:18 ` [PATCH 3/7] vhost: account the per-device kernel allocations " Tao Cui
2026-11-06 13:18 ` [PATCH 4/7] tracing: account ring buffer pages and trace_array metadata " Tao Cui
2026-11-11 16:47 ` Vincent Donnefort
2026-11-11 23:14 ` Steven Rostedt [this message]
2026-11-06 13:18 ` [PATCH 5/7] iommufd: account the hw_queue page array " Tao Cui
2026-11-06 13:18 ` [PATCH 6/7] io_uring: account the ring context and SQPOLL thread data " Tao Cui
2026-11-06 13:18 ` [PATCH 7/7] io_uring: account the remaining per-object allocations " Tao Cui
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261111181447.3c483a50@fedora \
--to=rostedt@goodmis.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=aesteve@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=bobbyeshleman@meta.com \
--cc=christian.koenig@amd.com \
--cc=cui.tao@linux.dev \
--cc=cuitao@kylinos.cn \
--cc=dgilbert@interlog.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=eperezma@redhat.com \
--cc=harry@kernel.org \
--cc=io-uring@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=jasowangio@gmail.com \
--cc=jgg@ziepe.ca \
--cc=jmeneghi@redhat.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=loberman@redhat.com \
--cc=mason@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mkp@kernel.org \
--cc=mst@redhat.com \
--cc=phasta@kernel.org \
--cc=robin.murphy@arm.com \
--cc=sgarzare@redhat.com \
--cc=stefanha@redhat.com \
--cc=sumit.semwal@linaro.org \
--cc=tjmercier@google.com \
--cc=vbabka@suse.cz \
--cc=vdonnefort@google.com \
--cc=virtualization@lists.linux.dev \
--cc=vivek.kasireddy@intel.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox