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]
Date:   Mon, 30 Mar 2020 11:08:55 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     David Laight <David.Laight@...LAB.COM>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: ftrace not showing the process names for all processes on
 syscall events

On Mon, 30 Mar 2020 14:28:01 +0000
David Laight <David.Laight@...LAB.COM> wrote:

> I've just updated one of my systems to 5.6.0-rc7+ (end of last week).
> ftrace in showing <...>-3179 in the system call events for a couple
> of threads of the active processes.
> Other threads of the same processes are fine.
> The scheduler process switch events also show the full name.
> 
> Is this a known regression?


Well, that code hasn't changed in years. But can you explain more of what
you did? Was this the "trace" file, or "trace_pipe" file? The command names
are cached in an array (see /sys/kernel/tracing/saved_cmdlines) of the size
that is defined by the saved_cmdlines_size file.

The cmdlines get updated via the sched_switch and sched_waking trace
events. The update is protected by a spinlock, which is only taken with a
"trylock", if the lock fails, then it does not get updated (we don't want
to hold back the running code just to cache the name of an event), but it
will try at the next sched event until it succeeds. This means that under
strong contention, it may fail to cache certain names.

This is not a regression, it's really just the work load that can cause
event names to be missed. I could work on something that if you have the
sched events enabled, that the output side could do its own caching to get
better results.

-- Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ