linux-kernel - Re: [PATCH -v5][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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <alpine.DEB.1.10.0901071530490.23456@gandalf.stny.rr.com>
Date:	Wed, 7 Jan 2009 15:40:12 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
cc:	Peter Zijlstra <peterz@...radead.org>, paulmck@...ux.vnet.ibm.com,
	Gregory Haskins <ghaskins@...ell.com>,
	Ingo Molnar <mingo@...e.hu>, Matthew Wilcox <matthew@....cx>,
	Andi Kleen <andi@...stfloor.org>,
	Chris Mason <chris.mason@...cle.com>,
	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 -v5][RFC]: mutex: implement adaptive spinning


On Wed, 7 Jan 2009, Linus Torvalds wrote:
> 
> So we can do all that locklessly and optimistically, just going back and 
> verifying the results later. This is why "thread_info" is actually a 
> better thing to use than "task_struct" - we can look up the cpu in it with 
> a simple dereference. We knew the pointer _used_ to be valid, so in any 
> normal situation, it will never page fault (and if you have 
> CONFIG_DEBUG_PAGEALLOC and hit a very unlucky race, then performance isn't 
> your concern anyway: we just need to make the page fault be non-lethal ;)

Wow, and I thought I do some crazy things with side effects of different 
kernel characteristics. So basically, since the owner use to be valid and 
we take the cpu number directly from the thread_info struct, we do not 
need to worry about page faulting.

Next comes the issue to know if the owner is still running. Wouldn't we 
need to do something like

	if (task_thread_info(cpu_rq(cpu)->curr) == owner)

I guess that would have the same characteristic, that even if the task 
struct of cpu_rq(cpu)->curr was freed, we can still reference the 
thread_info. Although, we might get garbage, but we don't care.

I understand that this should not be a problem, but I'm afraid it will 
give me nightmares at night. ;-)

God that code had better be commented well.

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