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]

Date:   Wed, 13 Oct 2021 13:27:53 -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 10:17:47 -0700
Beau Belgrave <beaub@...ux.microsoft.com> wrote:

> On Wed, Oct 13, 2021 at 01:11:55PM -0400, Steven Rostedt wrote:
> > 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.
> >   
> LOL, I'm happy to use a rwlock_t instead. Not sure which is faster, to
> me I care most about the write path not skewing clock times of the
> events being emitted. It seems like the contention case will be low in
> most cases, so these paths will be read-only most of the time.
> 
> It seems rwlock_t has the disadvantage of the writes blocking on the
> realloc/free case during the resize. RCU can delay the free until
> something has time to do so, so seems a good fit.
> 
> Thoughts?

You can always do the allocation and free outside the rwlock_t.

	new_data = alloc();
	lock();
	update new_data with old_data
	ptr = new_data;
	unlock();
	free old_data

And is the preferred method, as we don't want allocation or freeing done
inside the locking (especially on RT, where rwlocks are not "special").

The main concern is cache contention with the updates, even among readers.
That is, readers may not block on each other, but the accessing of the same
lock will cause cache contention.

And writers will block. I don't remember if rwlocks are fair or not (when a
writer blocks, all new readers block too.) I think it is.

For RCU, it's how you free it. You can push it off to a queue, if you have
a field in the data structure that can be added to the rcu link list that
wont affect the readers.

If you are concerned about the contention between readers, then RCU is the
way to go, as it doesn't have that issue.

-- Steve