linux-kernel - Re: [PATCH] user_events: Enable user processes to create and write to trace events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20211008182258.6bf272e6691679d41e7971fc@kernel.org>
Date:   Fri, 8 Oct 2021 18:22:58 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     rostedt@...dmis.org, linux-trace-devel@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] user_events: Enable user processes to create and write
 to trace events

On Thu, 7 Oct 2021 17:05:40 -0700
Beau Belgrave <beaub@...ux.microsoft.com> wrote:

> > > > > The other thing is we need ref counting to know if the event is busy.
> > > > > Having the ID in the packet avoids having a fd per-event, but it also
> > > > > makes ref counting process lifetime of each event quite hard.
> > > > 
> > > > Hmm, I don't think so. You can use an array of the pointer to
> > > > events on the private data of the struct file.
> > > > When you add (or start using) an event (this is identified by ioctl),
> > > > you can increment the event refcount and add it to the array.
> > > > When the file is closed (in exiting process), it will loop on the
> > > > array and decrement the refcount for each event.
> > > > Then, after all tracers disabled the event, ftrace can remove the
> > > > event in background (unless it is defined through 'dynamic_events' or
> > > > 'user_events').
> > > > 
> > > Yes, I didn't say it's impossible :) It's quite hard and takes a lot
> > > more management. I don't see a clear benefit to that approach, why is it
> > > better than an fd lifetime? Not trying to be difficult, just trying to
> > > be pragmatic about what approach is best.
> > 
> > I'm not sure this point, you mean 1 fd == 1 event model?
> > 
> Yeah, I like the idea of not having an fd per event.

Ah, OK. I misunderstood the idea.
per-FD model sounds like having events/user-events/*/marker file.

> I want to make
> sure the complexity is worth it. Is the overhead of an FD per event in
> user space too much?

It depends on the use case, how much events you wants to use with
the user-events. If there are hundreds of the evets, that will consume
kernel resources and /proc/*/fd/ will be filled with the event's fds.
But if there is a few events, I think no problem.

> What happens to the first 4 bytes (ID)? Does it not
> show up in the buffer?

You can add the 'ID' field commonly in the user-event by default
if you need it. Or, just skip the ID as it is a header of the packet.
(since the ID is process local number, that will not important for
the tracers who trace the events by name)

> This would be fine as long as the rel_loc idea
> gets into ftrace, etc.
> 
> This would require a global array as well as a local per-FD array. I'm
> wondering if the per-FD array becoming large mitigates the gain by
> simply having an FD per-event.

OK, I got it. I hope no one adds hundreds of events at once for
trace.

Thank you,


-- 
Masami Hiramatsu <mhiramat@...nel.org>