linux-kernel - Re: Instrumentation and RCU

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: <1421454673.21890.1583781953778.JavaMail.zimbra@efficios.com>
Date:   Mon, 9 Mar 2020 15:25:53 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     rostedt <rostedt@...dmis.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        paulmck <paulmck@...nel.org>,
        "Joel Fernandes, Google" <joel@...lfernandes.org>,
        Frederic Weisbecker <frederic@...nel.org>
Subject: Re: Instrumentation and RCU

----- On Mar 9, 2020, at 3:09 PM, rostedt rostedt@...dmis.org wrote:

> On Mon, 9 Mar 2020 14:52:40 -0400 (EDT)
> Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
>> And when I say "go back to plain RCU", I really mean removing use of SRCU
>> from the tracepoints until we have other purposes for it (e.g. taking
>> faults within specific tracepoint probes such as syscall enter/exit).
> 
> Actually, with both you and Alexei talking about having a sleeping
> tracepoint callback, where we can add a can sleep check (but not in the
> DO_TRACE macro, I would think that registered sleeping callbacks would be
> its own callback), I would think we do not want to remove the SRCU usage.

Whether we keep it or add it back later when needed should not make much
difference.

In any case, considering that overhead which motivated use of SRCU for the rcuidle
case could instead be handled by using is_rcu_watching() and normal RCU, I would
prefer removing it from the rcuidle tracepoints for now, and add it back when we
add a new kind of "sleepable" tracepoints later on.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com