linux-kernel - Re: [PATCH v4 1/5] tracing: Introduce faultable tracepoints

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: <e3721b80-4dfb-4914-acfb-b315b8cc45b8@paulmck-laptop>
Date:   Tue, 21 Nov 2023 08:41:56 -0800
From:   "Paul E. McKenney" <paulmck@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        linux-kernel@...r.kernel.org,
        Michael Jeanson <mjeanson@...icios.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Yonghong Song <yhs@...com>, Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>, bpf@...r.kernel.org,
        Joel Fernandes <joel@...lfernandes.org>
Subject: Re: [PATCH v4 1/5] tracing: Introduce faultable tracepoints

On Tue, Nov 21, 2023 at 04:52:56PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 21, 2023 at 03:46:43PM +0100, Peter Zijlstra wrote:
> 
> > Why is this such a hard question?

The place to look is here:

https://docs.kernel.org/RCU/Design/Requirements/Requirements.html

Or, if you prefer, Documentation/RCU/Design/Requirements/Requirements.rst.

> Anyway, recapping from IRC:
> 
> preemptible, SRCU:
>   counter-array based, GP advances by increasing array index
>   and waiting for previous index to drop to 0.
> 
>   notably, a GP can pass while a task is preempted but not within a
>   critical section.
> 
>   SRCU has smp_mb() in the critical sections to improve GP.

https://docs.kernel.org/RCU/Design/Requirements/Requirements.html#sleepable-rcu

Allows general blocking in SRCU readers, which it tolerates by giving
each user its own SRCU via DEFINE_SRCU(), DEFINE_STATIC_SRCU() or
a srcu_struct structure.  Users blocking too much in SRCU read-side
critical sections hurt only themselves.  Yes, heavy-weight readers.

> tasks:
>   waits for every task to pass schedule()
> 
>   ensures that any pieces of text rendered unreachable before, is
>   actually unused after.

But does not wait for tasks where RCU is not watching, including the
idle loop.

> tasks-rude:
>   like tasks, but different? build to handle tracing while rcu-idle,
>   even though that was already deemed bad?

This waits for the tasks that RCU Tasks cannot wait for.  If noinstr
is fully fixed, RCU Tasks Rude can go away.

> tasks-tracing-rcu:
>   extention of tasks to have critical-sections ? Should this simply be
>   tasks?

Tasks Trace RCU is its own thing.  It uses rcu_read_lock_trace() and
rcu_read_unlock_trace() to mark its readers.  It can detect quiescent
states even when the task in question does not call schedule().
Unlike Tasks RCU, Tasks Trace RCU does not scan the full task list.
(It used to, but that caused latency blows on non-realtime workloads.)
Tasks Trace RCU allows preemption and blocking for page faults in
its readers.  Also blocking on non-raw spinlocks in PREEMPT_RT, but I
am not sure that anyone cares.  If you want to block on anything else,
you need to talk to the current Tasks Trace RCU users.

							Thanx, Paul

> Can someone complete, please?
> 
> 
>