linux-kernel - Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace

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:   Mon, 23 Apr 2018 10:53:25 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-rt-users <linux-rt-users@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Tom Zanussi <tom.zanussi@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Boqun Feng <boqun.feng@...il.com>,
        fweisbec <fweisbec@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        kbuild test robot <fengguang.wu@...el.com>,
        baohong liu <baohong.liu@...el.com>,
        vedang patel <vedang.patel@...el.com>, kernel-team@....com
Subject: Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you
 can

On Mon, 23 Apr 2018 10:31:28 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> I've been wanting to introduce an alternative tracepoint instrumentation
> "flavor" for e.g. system call entry/exit which rely on SRCU rather than
> sched-rcu (preempt-off). This would allow taking faults within the instrumentation
> probe, which makes lots of things easier when fetching data from user-space
> upon system call entry/exit. This could also be used to cleanly instrument
> the idle loop.

I'd be OK with such an approach. And I don't think it would be that
hard to implement. It could be similar to the rcu_idle() tracepoints,
where each flavor simply passes in what protection it uses for
DO_TRACE(). We could do linker tricks to tell the tracepoint.c code how
the tracepoint is protected (add section code, that could be read to
update flags in the tracepoint). Of course modules that have
tracepoints could only use the standard preempt ones.

That is, if trace_##event##_srcu(trace_##event##_sp, PARAMS), is used,
then the trace_##event##_sp would need to be created somewhere. The use
of trace_##event##_srcu() would create a section entry, and on boot up
we can see that the use of this tracepoint requires srcu protection
with a pointer to the trace_##event##_sp srcu_struct. This could be
used to make sure that trace_#event() call isn't done multiple times
that uses two different protection flavors.

I'm just brain storming the idea, and I'm sure I screwed up something
above, but I do believe it is feasible.

> 
> I would be tempted to proceed carefully and introduce a new kind of SRCU
> tracepoint rather than changing all existing ones from sched-rcu to SRCU
> though.

Agreed.

> 
> So the lockdep stuff could use the SRCU tracepoint flavor, which I guess
> would be faster than the rcu_irq_enter_*().

Also agree.

-- Steve