diff for duplicates of <53F24A49.2010807@redhat.com> diff --git a/a/1.txt b/N1/1.txt index 261beea..9bd957b 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -36,21 +36,21 @@ has already used kvm_memslots(). Calling kvm_memslots() twice is the root cause the bug. > I think this patch is auditable, page-fault is always called by holding -> srcu-lock so that a page fault can’t go across synchronize_srcu_expedited. +> srcu-lock so that a page fault can�t go across synchronize_srcu_expedited. > Only these cases can happen: > > 1) page fault occurs before synchronize_srcu_expedited. > In this case, vcpu will generate mmio-exit for the memslot being registered -> by the ioctl. That’s ok since the ioctl have not finished. +> by the ioctl. That�s ok since the ioctl have not finished. > > 2) page fault occurs after synchronize_srcu_expedited and during > increasing generation-number. > In this case, userspace may get wrong mmio-exit (that happen if handing -> page-fault is slower that the ioctl), that’s ok too since userspace need do +> page-fault is slower that the ioctl), that�s ok too since userspace need do > the check anyway like i said above. > > 3) page fault occurs after generation-number update -> that’s definitely correct. :) +> that�s definitely correct. :) > >> Another alternative could be to use the low bit to mark an in-progress >> change, and skip the caching if the low bit is set. Similar to a diff --git a/a/content_digest b/N1/content_digest index 5f771a5..fbf1af3 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -52,21 +52,21 @@ "root cause the bug.\n" "\n" "> I think this patch is auditable, page-fault is always called by holding\n" - "> srcu-lock so that a page fault can\342\200\231t go across synchronize_srcu_expedited.\n" + "> srcu-lock so that a page fault can\303\257\302\277\302\275t go across synchronize_srcu_expedited.\n" "> Only these cases can happen:\n" "> \n" "> 1) page fault occurs before synchronize_srcu_expedited.\n" "> In this case, vcpu will generate mmio-exit for the memslot being registered\n" - "> by the ioctl. That\342\200\231s ok since the ioctl have not finished.\n" + "> by the ioctl. That\303\257\302\277\302\275s ok since the ioctl have not finished.\n" "> \n" "> 2) page fault occurs after synchronize_srcu_expedited and during\n" "> increasing generation-number.\n" "> In this case, userspace may get wrong mmio-exit (that happen if handing\n" - "> page-fault is slower that the ioctl), that\342\200\231s ok too since userspace need do\n" + "> page-fault is slower that the ioctl), that\303\257\302\277\302\275s ok too since userspace need do\n" "> the check anyway like i said above.\n" "> \n" "> 3) page fault occurs after generation-number update\n" - "> that\342\200\231s definitely correct. :)\n" + "> that\303\257\302\277\302\275s definitely correct. :)\n" "> \n" ">> Another alternative could be to use the low bit to mark an in-progress\n" ">> change, and skip the caching if the low bit is set. Similar to a\n" @@ -96,4 +96,4 @@ "\n" Paolo -039094b13af9b29ba09e1a69890fef7df06ce22e9eba9c7fa3e63c8e9eec507c +12405b066dceb7df13986155aefd8abd498e0987b7e1d21283fcdaa12361a1fa
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.