linux-kernel - Re: [PATCH 1/1] linux headers: header file(s) changes to enable spinlock use jumplabel

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: <4F41E4C1.9010901@linux.vnet.ibm.com>
Date:	Mon, 20 Feb 2012 11:44:25 +0530
From:	Raghavendra K T <raghavendra.kt@...ux.vnet.ibm.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>,
	Gleb Natapov <gleb@...hat.com>
CC:	Tejun Heo <tj@...nel.org>, John Stultz <johnstul@...ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	David Howells <dhowells@...hat.com>,
	Andrew Jones <drjones@...hat.com>
Subject: Re: [PATCH 1/1] linux headers: header file(s) changes to enable spinlock
 use jumplabel

On 02/20/2012 10:46 AM, Jeremy Fitzhardinge wrote:
[...]
>>>>   So we get following error when we try to include jump_label.h from
>>>> arch/x86/include/asm/spinlock.h because of cyclic dependency
>>>> <spinlock.h>  ->  <jumplabe.h>  ->  <workque.h>  ->  ...<seqlock.h>  ->  <spinlock.h>
>>> What about splitting the jump_label_key_deferred stuff into a separate
>>> jump_label_deferred.h, and just include that where it's needed?
>>>
>> Andrew Jones did exactly that (CCed).

Sorry, did not get it. Tried to search the patch. Is it similar
work or same work?. Could you please point. shall try both the way
(current way and jump_label_deferred way). So whichever makes maintainer 
happy, let that go :)

But does pvlock have to use jump
>> label? I looked at the code and it is used like paravirt patching. Meaning
>> it is patched only once on a boot up when XEN is detected. May be use
>> paravirt patching instead of jump label? What if jump label will want
>> to use spinlock for some reason in the future (it uses mutex currently)?
>
> The point of the pv ticketlocks is to avoid any pvop calls on the
> lock/unlock fastpath, relegating them to only the slow path.
> Unfortunately, the pv unlock case can't be identical with the non-pv
> unlock, and jump_labels are lighter weight and more efficient than pvops.
>
> It doesn't matter if jump_labels start using spinlocks; all we need the
> jump_label machinery to do is patch the jump sites in the code so that
> one of two execution paths can be selected.  Since all the ticketlock
> jump_label patching happens before SMP is enabled, there's no problem
> with changing a lock while a cpu is executing the code.
>

I also felt agreeing with Jeremy. seemed to me that latter is more
performance friendly. no?.

(Hmm. Thinking..  By the way is it not that Jeremy's earlier version
had implementation similar to what Gleb asked ?)

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