linux-kernel - Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

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:	Wed, 27 Sep 2006 11:01:49 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Bill Huey <billh@...ppy.monkey.org>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	John Stultz <johnstul@...ibm.com>,
	"Paul E. McKenney" <paulmck@...ibm.com>,
	Dipankar Sarma <dipankar@...ibm.com>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH] move put_task_struct() reaping into a thread [Re: 2.6.18-rt1]

* Eric W. Biederman <ebiederm@...ssion.com> wrote:

> Yes I am.  The motivator would be the RT work but I don't see a reason 
> why the it couldn't be put in the mainline kernel.  If not at least we 
> need the big fat comment in the mainline kernel that says 
> put_task_struct must be safe to call with interrupts disabled.
> 
> The way the code is structured now it deviates from the mainline 
> kernel in more than just changing locking behavior.  Which is what 
> brought me into this conversation in the first place.  So removing 
> that point of discord would be good.

well, this is one of those few cases (out of ~50,000 lock uses in the 
kernel) where such a change was unavoidable: put_task_struct() is used 
in the scheduler context-switch path. (see sched.c:finish_task_switch())

So that's why i first turned it into a separate, extra delayed-free via 
the "desched thread", and later on picked up the RCUification from Paul 
McKenney. The RCUification was the simpler (and hence easier to 
maintain) change. There is no problem with putting this into the RCU 
path on PREEMPT_RT, as this is a resource-freeing act. I.e. whatever 
'delay' there might be in RCU processing, it does not impact program 
logic. I agree with you that on !PREEMPT_RT there's no reason to 
complicate things with an extra layer of indirection.

	Ingo
-
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/