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: <20180425185149.64f89922@vmware.local.home>
Date:   Wed, 25 Apr 2018 18:51:49 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc:     Joel Fernandes <joelaf@...gle.com>,
        "Paul E. McKenney" <paulmck@...ux.vnet.ibm.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 Wed, 25 Apr 2018 17:40:56 -0400 (EDT)
Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:

> One problem with your approach is that you can have multiple callers
> for the same tracepoint name, where some could be non-preemptible and
> others blocking. Also, there is then no clear way for the callback
> registration API to enforce whether the callback expects the tracepoint
> to be blocking or non-preemptible. This can introduce hard to diagnose
> issues in a kernel without debug options enabled.

I agree that it should not be tied to an implementation name. But
"blocking" is confusing. I would say "can_sleep" or some such name that
states that the trace point caller is indeed something that can sleep.

> 
> Regarding the name, I'm OK with having something along the lines of
> trace_*event*_blocking or such. Please don't use "srcu" or other naming
> that is explicitly tied to the underlying mechanism used internally
> however: what we want to convey is that this specific tracepoint probe
> can be preempted and block. The underlying implementation could move to
> a different RCU flavor brand in the future, and it should not impact
> users of the tracepoint APIs.
> 
> In order to ensure that probes that may block only register themselves
> to tracepoints that allow blocking, we should introduce new tracepoint
> declaration/definition *and* registration APIs also contain the
> "BLOCKING/blocking" keywords (or such), so we can ensure that a
> tracepoint probe being registered to a "blocking" tracepoint is indeed
> allowed to block.

I'd really don't want to add more declaration/definitions, as we
already have too many as is, and with different meanings and the number
is of incarnations is n! in growth.

I'd say we just stick with a trace_<event>_can_sleep() call, and make
sure that if that is used that no trace_<event>() call is also used, and
enforce this with linker or compiler tricks.

-- Steve