linux-kernel - Re: [PATCH 3/3] ftrace: add ability to only trace swapper tasks

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] [day] [month] [year] [list]

Message-ID: <m1zljapokx.fsf@frodo.ebiederm.org>
Date:	Fri, 05 Dec 2008 08:35:26 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Frederic Weisbecker <fweisbec@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Dave Hansen <dave@...ux.vnet.ibm.com>,
	containers@...ts.osdl.org,
	Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
	"Serge E. Hallyn" <serue@...ibm.com>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 3/3] ftrace: add ability to only trace swapper tasks

Steven Rostedt <rostedt@...dmis.org> writes:

> Other pids get allocated per task. In the beginning of copy_process we 
> have:
>
>         if (pid != &init_struct_pid) {
>                 retval = -ENOMEM;
>                 pid = alloc_pid(task_active_pid_ns(p));
>
> Where alloc_pid allocates a pid structure. But this is only done if it is
> not a swapper task.

For PIDTYPE_PID.  For sessions and process groups we don't always allocate them,
and attach_pid is fine.

There is a bit of oddness in the pid freeing case, in using an unhashed pid,
so cpu hotunplug might be a problem.  But you certainly shouldn't be running
into this.

>> > When doing the code you suggested, I end up with only marking the last 
>> > idle task to be created.
>> 
>> Odd. It is all a linked list through the task structures.
>> I'm guessing the initialization isn't quite right.
>> 
>> Weird.  
>
> Do I need to change the loop to do_each_pid_thread?

> I'll try that later today.

I don't think so.  I'm pretty certain we aren't passing the necessary
clone flags to make that case work for idle threads, and in fact we aren't
even cloning from the idle task when we create additional idle threads
so I don't see how do_each_pid_thread could work better.

That said do_each_pid_thread appears to be a proper superset of
do_each_pid_task so it should not be harmful.

I am all for figuring out how to remove this special case if we can.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/