From: Beau Belgrave <beaub@linux.microsoft.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] user_events: Enable user processes to create and write to trace events
Date: Wed, 13 Oct 2021 09:50:43 -0700 [thread overview]
Message-ID: <20211013165043.GA1427@kbox> (raw)
In-Reply-To: <20211012211852.2bbf921b@oasis.local.home>
On Tue, Oct 12, 2021 at 09:18:52PM -0400, Steven Rostedt wrote:
> On Mon, 11 Oct 2021 09:25:23 -0700
> Beau Belgrave <beaub@linux.microsoft.com> wrote:
> >
> > Yes, in my mind there are two options to avoid kernel memory usage
> > per-event.
> >
> > 1.
> > We have a an array per file struct that is independently ref-counted.
> > This is required to ensure lifetime requirements and to ensure user code
> > cannot access other user events that might have been free'd outside of
> > the lifetime and cause a kernel crash.
> >
> > This approach also requires 2 int's to be returned, 1 for the status
> > page the other a local index for the write into the above array per-file
> > struct.
> >
> > This is likely the most complex method due to it's lifetime and RCU
> > synchronization requirements. However, it represents the least memory to
> > both kernel and user space.
>
> Does it require RCU synchronization as the updates only happen from
> user space. But is this for the writing of the event? You want a
> separate fd for each event to write to, instead of saying you have
> another interface to write and just pass the given id?
>
Yes, an example is a process creates the fd and registers some events.
Then the process forks and the child registers another event using the
same fd that was inherited.
If the original process writes while the child process registers at that
point the FD array can get resized / moved, therefore we need RCU deref
protection when resizing, etc.
I have a few gauntlet tools that try to crash user_events by writing,
registering, unregistering at weird times to try to flush this stuff
out.
> > In our own use case this will be low due to the way we plan to use the
> > events. However, I am not sure others will follow that :)
>
> I will say, whenever we say this will only have a "few", if it becomes
> useful, it will end up having many.
>
> -- Steve
Agree 100%, I've gone back and forth on which is better for a while. I'm
happy to update to RCU and send out a V3. Want to make sure we have
consensus of the right approach before spinning on it :)
Thanks,
-Beau
next prev parent reply other threads:[~2021-10-13 16:50 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-05 22:44 [PATCH] user_events: Enable user processes to create and write to trace events Beau Belgrave
2021-10-06 16:28 ` Masami Hiramatsu
2021-10-06 17:56 ` Beau Belgrave
2021-10-07 14:17 ` Masami Hiramatsu
2021-10-07 16:22 ` Beau Belgrave
2021-10-07 23:12 ` Masami Hiramatsu
2021-10-08 0:05 ` Beau Belgrave
2021-10-08 9:22 ` Masami Hiramatsu
2021-10-11 16:25 ` Beau Belgrave
2021-10-13 1:18 ` Steven Rostedt
2021-10-13 16:50 ` Beau Belgrave [this message]
2021-10-13 17:11 ` Steven Rostedt
2021-10-13 17:17 ` Beau Belgrave
2021-10-13 17:27 ` Steven Rostedt
2021-10-13 15:21 ` Masami Hiramatsu
2021-10-13 15:40 ` Steven Rostedt
2021-10-14 12:21 ` Masami Hiramatsu
2021-10-13 16:56 ` Beau Belgrave
2021-10-06 16:54 ` Steven Rostedt
2021-10-06 17:27 ` Beau Belgrave
2021-10-06 17:44 ` Steven Rostedt
2021-10-08 13:11 ` Peter.Enderborg
2021-10-08 16:09 ` Beau Belgrave
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=20211013165043.GA1427@kbox \
--to=beaub@linux.microsoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-devel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).