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  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:   Tue, 5 Oct 2021 16:02:52 -0400
From:   Steven Rostedt <>
To:     Linus Torvalds <>
Cc:     Jan Engelhardt <>,
        Mathieu Desnoyers <>,
        Rasmus Villemoes <>,
        linux-kernel <>,
        Paul <>,
        Josh Triplett <>,
        Lai Jiangshan <>,
        "Joel Fernandes, Google" <>,
        Pablo Neira Ayuso <>,
        Jozsef Kadlecsik <>,
        Florian Westphal <>,
        "David S. Miller" <>,
        Hideaki YOSHIFUJI <>,
        David Ahern <>,
        Jakub Kicinski <>, rcu <>,
        netfilter-devel <>,
        coreteam <>,
        netdev <>
Subject: Re: [RFC][PATCH] rcu: Use typeof(p) instead of typeof(*p) *

On Tue, 5 Oct 2021 12:46:43 -0700
Linus Torvalds <> wrote:

> On Tue, Oct 5, 2021 at 12:40 PM Steven Rostedt <> wrote:
> >
> > I may try it, because exposing the structure I want to hide, is pulling out
> > a lot of other crap with it :-p  
> One option is just "don't do rcu_access of a pointer that you're not
> supposed to touch in a file that isn't supposed to touch it".

The problem is, the RCU isn't for touching it, it is for knowing it exists.

> IOW, why are you doing that
>      pid_list = rcu_dereference_sched(tr->function_pids);
> in a place that isn't supposed to look at the pid_list in the first place?
> Yeah, yeah, I see how you just pass it to trace_ignore_this_task() as
> an argument, but maybe the real fix is to just pass that trace_array
> pointer instead?
> IOW, if you want to keep that structure private, maybe you really just
> shouldn't have non-private users of it randomly doing RCU lookups of
> it?

Ideally, I wanted to keep the logic of the pid lists separate, and not have
it know about the trace array at all.

And this was the best "incremental" approach I had, as the code is
currently all just open coded.

The RCU lookups are not an internal use functionality of the pid lists. The
updates to the pid list are done by allocating a new pid_list, copying the
old pid_list with the new updates and then swapping the pointers. The logic
of the pid_list is orthogonal to the RCU update. It's just "allocate some
random thing" and use RCU to swap it with the old random thing.

That is, the logic to synchronize updates is left to the user not the pid
list itself.

I also want to limit function calls, as this is called from the function
tracer (every function being traced) and if the pid_list pointer is NULL it
skips it. Hence, I want to avoid calling a function to know if the pointer
is NULL or not.

-- Steve

Powered by blists - more mailing lists