On Fri, 23 Dec 2011 09:14:51 -0200 Marcelo Tosatti <mtosatti@xxxxxxxxxx> 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 <agraf@xxxxxxx> 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.yoshikawa@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
