linux-kernel - Re: [PATCH 2/4, v2] x86: enlightenment for ticket spin locks

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] [day] [month] [year] [list]

Date:	Mon, 05 Jul 2010 16:12:43 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Jan Beulich <JBeulich@...ell.com>, "mingo@...e.hu" <mingo@...e.hu>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	Ky Srinivasan <KSrinivasan@...ell.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/4, v2] x86: enlightenment for ticket spin locks -	 Xen
  implementation

On 06/30/2010 03:14 PM, H. Peter Anvin wrote:
> On 06/30/2010 06:23 AM, Jeremy Fitzhardinge wrote:
>   
>> pvops is a superset of alternative instruction patching, and are really
>> designed to serve different purposes.  There are some areas in which
>> there's some overlap, but otherwise they are distinct.  In particular,
>> alternative instructions are really only useful if you can express the
>> patch in terms of the presence or absence of a particular cpu feature. 
>> It can't do multi-way choice, and it can't do anything other than insert
>> literal instructions.  pvops patching can do multi-way, and has a
>> higher-level view of each patch site which allows it to do things like
>> generate appropraite save/restores, make inline vs call decisions, nop
>> out nop callsites, etc.
>>
>>     
> A lot of this -- in particular the multiway -- is a defect in the
> alternatives implementation and should have been addressed as such.

The pvops and asm alternatives have different design goals.  Asm
alternatives is all about replacing particular instructions with
different ones depending on the properties of the CPU.  pvops is about
inserting an ops vector in front of various OS-level interfaces to allow
alternate implementations; the patching part was a later optimisation
sprinkled on top to reduce the abstraction overhead.  The fact that
there's some similarity in mechanism is the result of convergence rather
than a desire to reinvent.

>   One
> of the biggest problems with pvops as it currently stands is that it is
> monolithic; in general we have this class of problems (static selection)
> in a *lot* more places than we're dealing with right now, and as such,
> generalizing *something* -- be it pvops or alternatives -- would be useful.
>   

Yes.  The module system might also be a candidate for making more
general (by allowing the kernel to have unbound references, and the
module system can be used to create a runtime binding).  Modules are
already arch neutral (the arch-specific bits), which is an improvement
over alternatives or pvops, but it has no notion of patching anything
beyond linker relocs (but aside from very hot-path pvops such as
interrupt enable/disable, instruction patching isn't used all that much).

> gcc 4.5 also includes a very powerful facility called "asm goto", which
> I have already used to implement static_cpu_has().  Again, that
> particular construct (unlike "asm goto" itself) doesn't support multiway.
>   

What does the fallback for older compilers look like?

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