public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: [for-linus][PATCH 0/2] tracing: A couple of fixes for 6.13
Date: Wed, 04 Dec 2024 21:35:52 -0500	[thread overview]
Message-ID: <20241205023552.609451828@goodmis.org> (raw)

tracing fixes for v6.13:

- Fix trace histogram sort function cmp_entries_dup()

  The sort function cmp_entries_dup() returns either 1 or 0, and not
  -1 if parameter "a" is less than "b" by memcmp().

- Fix archs that call trace_hardirqs_off() without RCU watching

  Both x86 and arm64 no longer call any tracepoints with RCU not
  watching. It was assumed that it was safe to get rid of
  trace_*_rcuidle() version of the tracepoint calls. This was needed
  to get rid of the SRCU protection and be able to implement features
  like faultable traceponits and add rust tracepoints.

  Unfortunately, there were a few architectures that still relied on
  that logic. There's only one file that has tracepoints that are
  called without RCU watching. Add macro logic around the tracepoints
  for architectures that do not have CONFIG_ARCH_WANTS_NO_INSTR defined
  will check if the code is in the idle path (the only place RCU isn't
  watching), and enable RCU around calling the tracepoint, but only
  do it if the tracepoint is enabled.

  git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
trace/fixes

Head SHA1: 2f88ccdee3326a6197573623cd31947391eb5579


Kuan-Wei Chiu (1):
      tracing: Fix cmp_entries_dup() to respect sort() comparison rules

Steven Rostedt (1):
      tracing: Fix archs that still call tracepoints without RCU watching

----
 kernel/trace/trace_preemptirq.c | 43 +++++++++++++++++++++++++++++++++++------
 kernel/trace/tracing_map.c      |  6 +-----
 2 files changed, 38 insertions(+), 11 deletions(-)

             reply	other threads:[~2024-12-05  2:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-05  2:35 Steven Rostedt [this message]
2024-12-05  2:35 ` [for-linus][PATCH 1/2] tracing: Fix cmp_entries_dup() to respect sort() comparison rules Steven Rostedt
2024-12-05  2:35 ` [for-linus][PATCH 2/2] tracing: Fix archs that still call tracepoints without RCU watching Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20241205023552.609451828@goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox