linux-kernel - Re: [patch] don't preempt not TASK

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:	Fri, 20 Mar 2009 11:53:06 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	peterz@...radead.org, roland@...hat.com, efault@....de,
	rjw@...k.pl, jdike@...toit.com,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org
Subject: Re: [patch] don't preempt not TASK_RUNNING tasks


* Miklos Szeredi <miklos@...redi.hu> wrote:

> On Fri, 20 Mar 2009, Peter Zijlstra wrote:
> > On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> > > Ingo,
> > > 
> > > I tested this one, and I think it makes sense in any case as an
> > > optimization.  It should also be good for -stable kernels.
> > > 
> > > Does it look OK?
> > 
> > The idea is good, but there is a risk of preemption latencies here. Some
> > code paths aren't real quick between setting ->state != TASK_RUNNING and
> > calling schedule.
> > 
> > [ Both quick: as in O(1) and few instructions ]
> > 
> > So if we're going to do this, we'd need to audit all such code paths --
> > and there be lots.
> 
> Oh, yes.
> 
> In a random sample the most common pattern is something like this:
> 
> 	spin_lock(&some_lock);
> 	/* do something */
> 	set_task_state(TASK_SOMESLEEP);
> 	/* do something more */
> 	spin_unlock(&some_lock);
> 	schedule();
> 	...
> 
> Which should only positively be impacted by the change.  But I can 
> imagine rare cases where it's more complex.

I'd suggest spin_unlock_no_resched() and task_unlock_no_resched() 
instead of open-coding preempt-disable sequences.

> > The first line of attack for this problem is making 
> > wait_task_inactive() sucks less, which shouldn't be too hard, 
> > that unconditional 1 jiffy sleep is simply retarded.
> 
> I completely agree.  However, I'd like to have a non-invasive 
> solution that can go into current and stable kernels so UML users 
> don't need to suffer any more.

Agreed. task_unlock_no_resched() should do that i think.

	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/