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, 15 Apr 2019 15:49:45 +0100
From:   Qais Yousef <>
Subject: Re: Tracehooks in scheduler

Hi Steve, Peter

> On 04/07/19 18:52, Qais Yousef wrote:
> > Hi Steve, Peter
> > 
> > I know the topic has sprung up in the past but I couldn't find anything that
> > points into any conclusion.
> > 
> > As far as I understand new TRACE_EVENTS() in the scheduler (and probably other
> > subsystems) isn't desirable as it intorduces a sort of ABI that can be painful
> > to maintain.
> > 
> > But for us to be able to test various aspect of EAS, we rely on some events
> > that track load_avg, util_avg and some other metrics in the scheduler.
> > Example of such patches that are in android and we maintain out of tree can be
> > found here:
> > 
> >
> >
> > 
> > Dietmar and Quentin pointed me to a discussion you guys had with Daniel Bristot
> > in the last LPC when he had a similar need. So it is something that could
> > benefit other users as well.
> > 
> > What is the best way forward to be able to add tracehooks into the scheduler
> > and any other subsystem for that matters?
> > 
> > We tried using DECLARE_TRACE() to create a tracepoint which doesn't export
> > anything in /sys/kernel/debug/tracing/events and hoped that we can use eBPF or
> > a kernel module to attach to this tracepoint and access the args to inject our
> > own trace_printks() but this didn't work. The glue logic necessary to attach
> > to this tracepoint in a similar manner to how RAW_TRACEPOINT() in eBPF works
> > isn't there AFAICT.
> > 
> > I can post the full example if the above doesn't make sense. I am still
> > familiarizing myself with the different aspects of this code as well. There
> > might be support for what we want but I failed to figure out the magic
> > combination to get it to work.
> > 
> > If I got this glue logic done, would this be an acceptable solution? If not, do
> > you have any suggestions on how to progress?

I have written some patches in hope it'll clarify further what we are trying to
achieve here and what would be the best possible approach about it.

I have taken two approaches to solve the problem.


	In this approach everything we need is already available and we just
	need to create new tracepoints as described in
	Documentation/trace/tracepoints.rst and export it with

	A user then can have an out of tree module to probe this tp and
	manipulate it as they like.

	Example of such a module is here, the pelt_se tp is to demo the

	Googling around I can see that the use of
	EXPORT_TRACEPOINT_SYMBOL_GPL() is not desired unless the module is
	in-tree which I doubt will be the case here.


	In this approach I try to allow attaching to a TP using eBPF. Sadly the
	current infrastructure is lacking so I hacked the above up to create a
	new DECLARE_TRACE_HOOK() macro which will allow using eBPF but without
	exporting anything in debugfs that can constitute an ABI.

	The following eBPF program can be used then to attach and access some
	info at the TP:

Does any of the above approaches make sense?


Qais Yousef

Powered by blists - more mailing lists