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]
Message-ID: <20130516195735.GJ14597@redhat.com>
Date:	Thu, 16 May 2013 22:57:35 +0300
From:	Gleb Natapov <gleb@...hat.com>
To:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
Cc:	avi.kivity@...il.com, mtosatti@...hat.com, pbonzini@...hat.com,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v5 3/8] KVM: MMU: fast invalidate all pages

On Fri, May 17, 2013 at 02:39:07AM +0800, Xiao Guangrong wrote:
> On 05/16/2013 11:57 PM, Gleb Natapov wrote:
> 
> > One more thought. With current patch if zap_invalid_page() will be
> > called second time while another zap_invalid_page() is still running
> > (can that happen?) they will both run concurrently fighting for the
> 
> Currently, it can not happen since zap_invalid_page is needed when slot
> is being deleted which protected by slot-lock.
> 
> But we allow it to be concurrent as you commented: we can use it in
> ->release() instead of calling kvm_mmu_zap_all(), in that case, multiple
> call zap_invalid_page() can happen.
> 
That's only during VM destruction, no need to optimize for. 

> > mmu_lock. Is this a problem?
> 
> Are you worry about that it can not progress due to lock contention when
> walking active_list? Zapping at least 10 pages before releasing the lock
> should ensure that it can progress.
Yes, it will progress, but will bounce between two threads after each 10
pages. This is less efficient that letting one thread to finish zapping.
Theoretically we can make one thread wait for the other.

> 
> Do you see any potential issue?
> 
Just thinking out loud :). If this cannot happen during normal
operation, no reason to optimize for it.

--
			Gleb.
--
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