On Fri, 23 Dec 2011 09:14:51 -0200
Marcelo Tosatti <mtosa...@redhat.com> wrote:
> > >btw mark_page_dirty() itself seems to assume mmu_lock protection that
> > >doesn't exist. Marcelo?
> > >
>
> Not mmu_lock protection, kvm->srcu protection.
But it just protects slot readers against updates and two, or more, threads
can call mark_page_dirty() concurrently?
What I am worring about here is the atomicity of bitmap updates.
commit c8240bd6f0b4b1b21ffd36dd44114d05c7afe0c0
Author: Alexander Graf <ag...@suse.de>
Date: Fri Oct 30 05:47:26 2009 +0000
Use Little Endian for Dirty Bitmap
has changed set_bit() to the non-atomic version and nothing protects
dirty bits if mmu_lock is not held.
The changelog has no explanation why using non-atomic version is safe.
Some comment in the code may be worthwhile if it is really safe.
I want to see some clear reasoning now if possible.
Takuya
>
> > I want to hear the answer for this question.
> >
> > Though I myself is reading the code, I cannot understand it thoroughly yet.
> > I wish if there were mmu_lock entry in locking.txt ...
>
> Agreed.
>
--
Takuya Yoshikawa <takuya.yoshik...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
