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]
Date:	Mon, 02 Apr 2007 00:20:08 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	Andi Kleen <ak@...e.de>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	virtualization@...ts.osdl.org, lkml <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Zachary Amsden <zach@...are.com>,
	Anthony Liguori <anthony@...emonkey.ws>
Subject: Re: [patch 12/17] Consistently wrap paravirt ops callsites to make
 them patchable

Andi Kleen wrote:
> Can you please add some comments to the code explaining this a little?
> Best would be perhaps a overview document in Documentation too.
>   

Yes, OK.

>> +#define PVOP_CALL0(__rettype, __op)					\
>>     
>
> The __s shouldn't be needed for the macro arguments because
> there is no shared name space with the caller.
>   

Yes.  I was more concerned about "op" clashing with variables used
within the macro, but that's not an issue now.

>> +	({								\
>> +		__rettype __ret;					\
>> +		if (sizeof(__rettype) > sizeof(unsigned long)) {	\
>> +			unsigned long long __tmp;			\
>> +			unsigned long __ecx;				\
>> +			asm volatile(paravirt_alt(PARAVIRT_CALL)	\
>>     
>
> Not having the volatile would probably generate better code, but it 
> seems much safer for now.
>   

I think it has to be there, though perhaps the "memory" is sufficient to
make sure all the calls get generated.  We don't want gcc to eliminate
any of these calls because it thinks they can be CSEd.

> And the cc clobber is also not needed
>   

I get conflicting advice about this.  I think Linus mentioned that the
gcc people would prefer it to be there explicitly, even though its
currently implied.


    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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ