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]

Message-ID: <1045420715.14686.1524495583859.JavaMail.zimbra@efficios.com>
Date:   Mon, 23 Apr 2018 10:59:43 -0400 (EDT)
From:   Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:     rostedt <rostedt@...dmis.org>
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 <kernel-team@....com>
Subject: Re: [RFC v4 3/4] irqflags: Avoid unnecessary calls to trace_ if you
 can

----- On Apr 23, 2018, at 10:53 AM, rostedt rostedt@...dmis.org wrote:

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

The main open question here is whether we want one SRCU grace period
domain per SRCU tracepoint definition, or just one SRCU domain for all
SRCU tracepoints would be fine.

I'm not sure what we would gain by having the extra granularity provided
by one SRCU grace period domain per tracepoint, and having a single SRCU
domain for all SRCU tracepoints makes it easy to batch grace period after
bulk tracepoint modifications.

Thoughts ?

Thanks,

Mathieu

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