linux-kernel - Re: [KVM PATCH v3 1/3] KVM: fix race in irq

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]

Date:	Tue, 27 Oct 2009 12:53:04 -0400
From:	Gregory Haskins <gregory.haskins@...il.com>
To:	Gleb Natapov <gleb@...hat.com>
CC:	Gregory Haskins <ghaskins@...ell.com>, kvm@...r.kernel.org,
	"alacrityvm-devel@...ts.sourceforge.net" 
	<alacrityvm-devel@...ts.sourceforge.net>,
	linux-kernel@...r.kernel.org, paulmck@...ux.vnet.ibm.com
Subject: Re: [KVM PATCH v3 1/3] KVM: fix race in irq_routing logic

Gleb Natapov wrote:
>>
>> 1) rcu_read_lock is something like 4x faster than srcu_read_lock(), but
>> we are talking about nanoseconds on modern hardware (I think Paul quoted
>> me 10ns vs 45ns on his rig).  I don't think either overhead is something
>> to be concerned about in this case.
>>
> If we can avoid why not? Nanoseconds tend to add up.
> 

BTW: I didn't mean to imply that we should be cavalier in adding
overhead.  My point was that adding overhead is sometimes _necessary_ to
prevent a race above and beyond an RCU pointer acquisition, and 35ns is
not _terrible_ IMO.

I was suggesting to solve this by switching to SRCU, but an alternative
is copying the structure (when permitted with immutable objects), which
seems to work in this particular case.  It should be noted that the copy
has its own unquantified overhead beyond basic RCU as well, so its not
truly free (I'd guess its <= as the switch to SRCU without copies, though).

IOW: sync hurts, but its sometimes a necessary evil ;)

Kind Regards,
-Greg

Download attachment "signature.asc" of type "application/pgp-signature" (268 bytes)