linux-kernel - Re: [PATCH 2/2] locking: Apply contention tracepoints in the slow path

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: <20220318180750.744f08d4@gandalf.local.home>
Date:   Fri, 18 Mar 2022 18:07:50 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Boqun Feng <boqun.feng@...il.com>,
        Ingo Molnar <mingo@...nel.org>, Will Deacon <will@...nel.org>,
        Waiman Long <longman@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Byungchul Park <byungchul.park@....com>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Arnd Bergmann <arnd@...db.de>,
        Radoslaw Burny <rburny@...gle.com>,
        linux-arch <linux-arch@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH 2/2] locking: Apply contention tracepoints in the slow
 path

On Fri, 18 Mar 2022 14:55:27 -0700
Namhyung Kim <namhyung@...nel.org> wrote:

> > > This looks a littl ugly ;-/ Maybe we can rename __down_common() to
> > > ___down_common() and implement __down_common() as:
> > >
> > >       static inline int __sched __down_common(...)
> > >       {
> > >               int ret;
> > >               trace_contention_begin(sem, 0);
> > >               ret = ___down_common(...);
> > >               trace_contention_end(sem, ret);
> > >               return ret;
> > >       }
> > >
> > > Thoughts?  
> >
> > Yeah, that works, except I think he wants a few extra
> > __set_current_state()'s like so:  
> 
> Not anymore, I decided not to because of noise in the task state.
> 
> Also I'm considering two tracepoints for the return path to reduce
> the buffer size as Mathieu suggested.  Normally it'd return with 0
> so we can ignore it in the contention_end.  For non-zero cases,
> we can add a new tracepoint to save the return value.

I don't think you need two tracepoints, but one that you can override.

We have eprobes that let you create a trace event on top of a current trace
event that can limit or extend what is traced in the buffer.

And I also have custom events that can be placed on top of any existing
tracepoint that has full access to what is sent into the tracepoint on not
just what is available to the trace event:

  https://lore.kernel.org/all/20220312232551.181178712@goodmis.org/

-- Steve