linux-kernel - Re: [PATCH] sched: correct testing need_resched in mutex_spin_on

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]

Message-ID: <1307456680.2322.270.camel@twins>
Date:	Tue, 07 Jun 2011 16:24:40 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Hillf Danton <dhillf@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sched: correct testing need_resched in
 mutex_spin_on_owner()

On Tue, 2011-06-07 at 22:10 +0800, Hillf Danton wrote:
> On Tue, Jun 7, 2011 at 9:47 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Tue, 2011-06-07 at 21:41 +0800, Hillf Danton wrote:
> >> It is suppose to check the owner task that is not absolutly running on the
> >> local CPU,
> >
> > Oh, why do you think so?
> >
> as the comment in __mutex_lock_common() says,
> 
> #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> 	/*
> 	 * Optimistic spinning.
> 	 *
> 	 * We try to spin for acquisition when we find that there are no
> 	 * pending waiters and the lock owner is currently running on a
> 	 ***************************
>          * (different) CPU.
> 	 ***************************
>          * .....
>          */

Which is exactly what owner_running() does, clearly it cannot run on the
current cpu, since then we wouldn't be running to check things, so for
as long as owner is on_cpu we spin.

However,

> need_resched is checked after true is returned by owner_running(),
> in other words, owner is still on its CPU, so owner should be check
> here. Even ower's CPU == this CPU, checking owner also gives
> correct result.

no, after rcu_read_unlock() in owner_running() -- read that comment
again -- the owner pointer can be free or reused memory.

Also, since we already check owner_running() this need_resched() is
clearly something different. By your argument it would be superfluous
not wrong.

Now since it appears superfluous, ask yourself why it would exist. The
answer is simple, we should not be greedy and consume our cpu when
there's someone else that wants to run, we should yield the cpu on
need_resched(), which is exactly what happens.

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