linux-kernel - Re: [PATCH 1/5] Add a global synchronization point for pvclock

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]

Message-ID: <4BCD748E.7080007@redhat.com>
Date:	Tue, 20 Apr 2010 12:31:58 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
CC:	Peter Zijlstra <peterz@...radead.org>,
	Glauber Costa <glommer@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>
Subject: Re: [PATCH 1/5] Add a global synchronization point for pvclock

On 04/19/2010 07:18 PM, Jeremy Fitzhardinge wrote:
> On 04/19/2010 07:46 AM, Peter Zijlstra wrote:
>    
>> What avi says! :-)
>>
>> On a 32bit machine a 64bit read are two 32bit reads, so
>>
>>    last = last_value;
>>
>> becomes:
>>
>>    last.high = last_value.high;
>>    last.low  = last_vlue.low;
>>
>> (or the reverse of course)
>>
>> Now imagine a write getting interleaved with that ;-)
>>
>>      
> You could explicitly do:
>
> 	do {
> 		h = last.high;
> 		barrier();
> 		l = last.low;
> 		barrier();
> 	} while (last.high != h);
>
>
> This works because we expect last to be always increasing, so the only
> worry is low wrapping and incrementing high, and is more efficient than
> making the read fully atomic (the write is still cmpxchg64).  But it's
> pretty ugly to open code just for 32b architectures; its something that
> might be useful to turn into a general abstraction (monotonic_read_64
> FTW!).  I already have code like this in the Xen time code, so I could
> make immediate use of it.
>    

I don't think this is worthwhile - the cmpxchg is not that expensive on 
most kvm capable hosts (the exception is the Pentium D).

btw, do you want this code in pvclock.c, or shall we keep it kvmclock 
specific?

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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