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: <20211013131155.69fa0e11@gandalf.local.home>
Date:   Wed, 13 Oct 2021 13:11:55 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Beau Belgrave <beaub@...ux.microsoft.com>
Cc:     Masami Hiramatsu <mhiramat@...nel.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 Wed, 13 Oct 2021 09:50:43 -0700
Beau Belgrave <beaub@...ux.microsoft.com> wrote:

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

Well, I was thinking simple locking could work too. But I guess RCU is like
Batman. You know, "Always be yourself. Unless you can be Batman, then
always be Batman!". So always use locking, unless you can use RCU,
then always use RCU.

> 
> 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 :)
> 

Sure, thanks.

-- Steve