linux-kernel - Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 8 Jan 2009 13:14:08 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Chris Mason <chris.mason@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...e.hu>, paulmck@...ux.vnet.ibm.com,
	Gregory Haskins <ghaskins@...ell.com>,
	Matthew Wilcox <matthew@....cx>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>
Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning




On Thu, 8 Jan 2009, Steven Rostedt wrote:
> > In fact, you might not even need a process C: all you need is for B to be 
> > on the same runqueue as A, and having enough load on the other CPU's that 
> > A never gets migrated away. So "C" might be in user space.

You're right about not needing process C.

> > 
> > I dunno. There are probably variations on the above.
> 
> Ouch! I think you are on to something:
> 
>         for (;;) {
>                 struct thread_info *owner;
> 
>                 old_val = atomic_cmpxchg(&lock->count, 1, 0);
>                 if (old_val == 1) {
>                         lock_acquired(&lock->dep_map, ip);
>                         mutex_set_owner(lock);
>                         return 0;
>                 }
> 
>                 if (old_val < 0 && !list_empty(&lock->wait_list))
>                         break;
> 
>                 /* See who owns it, and spin on him if anybody */
>                 owner = ACCESS_ONCE(lock->owner);
> 
> The owner was preempted before assigning lock->owner (as you stated).

If it was the current process that preempted the owner and these are RT 
tasks pinned to the same CPU and the owner is of lower priority than the 
spinner, we have a deadlock!

Hmm, I do not think the need_sched here will even fix that :-/

-- Steve

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