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:	Tue, 19 Apr 2016 20:30:07 +0000 (UTC)
From:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To:	rostedt <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jiri Olsa <jolsa@...nel.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Namhyung Kim <namhyung@...nel.org>,
	linux-trace-users@...r.kernel.org
Subject: Re: [RFC][PATCH 3/4] tracing: Add infrastructure to allow
 set_event_pid to follow children

----- On Apr 19, 2016, at 1:13 PM, rostedt rostedt@...dmis.org wrote:

> On Tue, 19 Apr 2016 16:55:11 +0000 (UTC)
> Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
> 
>> ----- On Apr 19, 2016, at 10:34 AM, rostedt rostedt@...dmis.org wrote:
>> 
>> > From: Steven Rostedt <rostedt@...dmis.org>
>> > 
>> > Add the infrastructure needed to have the PIDs in set_event_pid to
>> > automatically add PIDs of the children of the tasks that have their PIDs in
>> > set_event_pid. This will also remove PIDs from set_event_pid when a task
>> > exits
>> > 
>> > This is implemented by adding hooks into the fork and exit tracepoints. On
>> > fork, the PIDs are added to the list, and on exit, they are removed.
>> > 
>> > Add a new option called event_fork that when set, PIDs in set_event_pid will
>> > automatically get their children PIDs added when they fork, as well as any
>> > task that exits will have its PID removed from set_event_pid.
>> 
>> Just out of curiosity: how does it deal with multi-process and multi-thread ?
>> What events are expected in each case ?
>> 
> 
> Not sure what you mean by that. This is in-kernel, and it's simply
> tasks. That is, any task (process or thread) that creates another task
> has its kernel pid checked. That would be the thread ID as well. So it
> works the same with processes as with threads because within the kernel
> they are just all just "tasks".

You register on sched_process_fork and sched_process_exit tracepoints
for adding/removing PIDs to/from your "PID tracker".

sched_process_fork() is called both when a process and when a thread
is created.

sched_process_exit() is called from do_exit(). Ah! and it seems do_exit
is called whenever a user-space thread exits. The process exiting
system call is rather exit_group(2).

I was concerned that you might miss the thread exiting system calls,
but it seems OK after digging back into that part of the kernel
source code. It's been a while since last time I had to do modeling
of the kernel state based on events by myself, sorry about the
confusion. :-)

Thanks,

Mathieu

> 
> -- Steve

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ