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-next>] [day] [month] [year] [list]
Date: Fri, 09 Feb 2024 05:22:20 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: linux-kernel@...r.kernel.org
Cc: Masami Hiramatsu <mhiramat@...nel.org>,
 Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Andrew Morton <akpm@...ux-foundation.org>
Subject: [for-linus][PATCH 0/2] tracing: Fixes for v6.8-rc3


Tracing fixes for v6.8-rc3:

- Fix broken direct trampolines being called when another callback is
  attached the same function. ARM 64 does not support FTRACE_WITH_REGS, and
  when it added direct trampoline calls from ftrace, it removed the
  "WITH_REGS" flag from the ftrace_ops for direct trampolines. This broke
  x86 as x86 requires direct trampolines to have WITH_REGS. This wasn't
  noticed because direct trampolines work as long as the function it is
  attached to is not shared with other callbacks (like the function tracer).
  When there's other callbacks, a helper trampoline is called, to call all
  the non direct callbacks and when it returns, the direct trampoline is
  called. For x86, the direct trampoline sets a flag in the regs field to
  tell the x86 specific code to call the direct trampoline. But this only
  works if the ftrace_ops had WITH_REGS set. ARM does things differently
  that does not require this. For now, set WITH_REGS if the arch supports
  WITH_REGS (which ARM does not), and this makes it work for both ARM64 and
  x86.

- Fix wasted memory in the saved_cmdlines logic.

  The saved_cmdlines is a cache that maps PIDs to COMMs that tracing can
  use. Most trace events only save the PID in the event. The saved_cmdlines
  file lists PIDs to COMMs so that the tracing tools can show an actual name
  and not just a PID for each event. There's an array of PIDs that map to a
  small set of saved COMM strings. The array is set to PID_MAX_DEFAULT which
  is usually set to 32768. When a PID comes in, it will add itself to this
  array along with the index into the COMM array (note if the system allows
  more than PID_MAX_DEFAULT, this cache is similar to cache lines as an
  update of a PID that has the same PID_MAX_DEFAULT bits set will flush out
  another task with the same matching bits set).

  A while ago, the size of this cache was changed to be dynamic and the
  array was moved into a structure and created with kmalloc(). But this
  new structure had the size of 131104 bytes, or 0x20020 in hex. As kmalloc
  allocates in powers of two, it was actually allocating 0x40000 bytes
  (262144) leaving 131040 bytes of wasted memory. The last element of this
  structure was a pointer to the COMM string array which defaulted to just
  saving 128 COMMS.

  By changing the last field of this structure to a variable length string,
  and just having it round up to fill the allocated memory, the default
  size of the saved COMM cache is now 8190. This not only uses the wasted
  space, but actually saves space by removing the extra allocation for the
  COMM names.

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

Head SHA1: f2d3d1fa979e0a8e418a03e96902a9e6b4a6e9ae


Masami Hiramatsu (Google) (1):
      ftrace: Fix DIRECT_CALLS to use SAVE_REGS by default

Steven Rostedt (Google) (1):
      tracing: Fix wasted memory in saved_cmdlines logic

----
 kernel/trace/ftrace.c | 10 +++++++
 kernel/trace/trace.c  | 73 ++++++++++++++++++++++++---------------------------
 2 files changed, 44 insertions(+), 39 deletions(-)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ