diff for duplicates of <20200207211016.GN2401@linux.intel.com>

diff --git a/a/1.txt b/N1/1.txt
index 26d64d0..7f47570 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -16,7 +16,7 @@ On Fri, Feb 07, 2020 at 03:39:09PM -0500, Peter Xu wrote:
 > > > Is this intended?
 > > 
 > > Yes.  It's possible to allow VA=0 for userspace mappings.  It's extremely
-> > uncommon, but possible.  Therefore "hva = 0" shouldn't be used to
+> > uncommon, but possible.  Therefore "hva == 0" shouldn't be used to
 > > indicate an invalid slot.
 > 
 > Note that this is the deletion path in __x86_set_memory_region() not
@@ -47,7 +47,7 @@ to indicate it's being destroyed.
 > > > > +	struct kvm_memory_slot *mslots = slots->memslots;
 > > > > +	int i;
 > > > > +
-> > > > +	if (WARN_ON_ONCE(slots->id_to_index[memslot->id] = -1) ||
+> > > > +	if (WARN_ON_ONCE(slots->id_to_index[memslot->id] == -1) ||
 > > > > +	    WARN_ON_ONCE(!slots->used_slots))
 > > > > +		return -1;
 > > > > +
@@ -60,7 +60,7 @@ to indicate it's being destroyed.
 > > > > +		if (memslot->base_gfn > mslots[i + 1].base_gfn)
 > > > > +			break;
 > > > > +
-> > > > +		WARN_ON_ONCE(memslot->base_gfn = mslots[i + 1].base_gfn);
+> > > > +		WARN_ON_ONCE(memslot->base_gfn == mslots[i + 1].base_gfn);
 > > > 
 > > > Will this trigger?  Note that in __kvm_set_memory_region() we have
 > > > already checked overlap of memslots.
@@ -119,3 +119,7 @@ can't be used incorrectly and thus cause silent failure.
 This is also another reason I'd like to keep the WARN_ONs.  When this code
 goes awry, the result is usually silent corruption and delayed explosions,
 i.e. failures that absolutely suck to debug.
+_______________________________________________
+kvmarm mailing list
+kvmarm@lists.cs.columbia.edu
+https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
diff --git a/a/content_digest b/N1/content_digest
index 3b5edf7..06f443b 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -5,29 +5,25 @@
  "ref\020200207203909.GE720553@xz-x1\0"
  "From\0Sean Christopherson <sean.j.christopherson@intel.com>\0"
  "Subject\0Re: [PATCH v5 17/19] KVM: Terminate memslot walks via used_slots\0"
- "Date\0Fri, 07 Feb 2020 21:10:16 +0000\0"
+ "Date\0Fri, 7 Feb 2020 13:10:16 -0800\0"
  "To\0Peter Xu <peterx@redhat.com>\0"
- "Cc\0Paolo Bonzini <pbonzini@redhat.com>"
+ "Cc\0Wanpeng Li <wanpengli@tencent.com>"
+  kvm@vger.kernel.org
+  David Hildenbrand <david@redhat.com>
+  linux-mips@vger.kernel.org
   Paul Mackerras <paulus@ozlabs.org>
-  Christian Borntraeger <borntraeger@de.ibm.com>
+  kvmarm@lists.cs.columbia.edu
   Janosch Frank <frankja@linux.ibm.com>
-  David Hildenbrand <david@redhat.com>
-  Cornelia Huck <cohuck@redhat.com>
-  Vitaly Kuznetsov <vkuznets@redhat.com>
-  Wanpeng Li <wanpengli@tencent.com>
-  Jim Mattson <jmattson@google.com>
-  Joerg Roedel <joro@8bytes.org>
   Marc Zyngier <maz@kernel.org>
-  James Morse <james.morse@arm.com>
-  Julien Thierry <julien.thierry.kdev@gmail.com>
-  Suzuki K Poulose <suzuki.poulose@arm.com>
-  linux-mips@vger.kernel.org
-  kvm@vger.kernel.org
+  Joerg Roedel <joro@8bytes.org>
+  Christian Borntraeger <borntraeger@de.ibm.com>
   kvm-ppc@vger.kernel.org
   linux-arm-kernel@lists.infradead.org
-  kvmarm@lists.cs.columbia.edu
+  Jim Mattson <jmattson@google.com>
+  Cornelia Huck <cohuck@redhat.com>
   linux-kernel@vger.kernel.org
-  Christoffer Dall <christoffer.dall@arm.com>
+  Paolo Bonzini <pbonzini@redhat.com>
+  Vitaly Kuznetsov <vkuznets@redhat.com>
  " Philippe Mathieu-Daud\303\251 <f4bug@amsat.org>\0"
  "\00:1\0"
  "b\0"
@@ -49,7 +45,7 @@
  "> > > Is this intended?\n"
  "> > \n"
  "> > Yes.  It's possible to allow VA=0 for userspace mappings.  It's extremely\n"
- "> > uncommon, but possible.  Therefore \"hva = 0\" shouldn't be used to\n"
+ "> > uncommon, but possible.  Therefore \"hva == 0\" shouldn't be used to\n"
  "> > indicate an invalid slot.\n"
  "> \n"
  "> Note that this is the deletion path in __x86_set_memory_region() not\n"
@@ -80,7 +76,7 @@
  "> > > > +\tstruct kvm_memory_slot *mslots = slots->memslots;\n"
  "> > > > +\tint i;\n"
  "> > > > +\n"
- "> > > > +\tif (WARN_ON_ONCE(slots->id_to_index[memslot->id] = -1) ||\n"
+ "> > > > +\tif (WARN_ON_ONCE(slots->id_to_index[memslot->id] == -1) ||\n"
  "> > > > +\t    WARN_ON_ONCE(!slots->used_slots))\n"
  "> > > > +\t\treturn -1;\n"
  "> > > > +\n"
@@ -93,7 +89,7 @@
  "> > > > +\t\tif (memslot->base_gfn > mslots[i + 1].base_gfn)\n"
  "> > > > +\t\t\tbreak;\n"
  "> > > > +\n"
- "> > > > +\t\tWARN_ON_ONCE(memslot->base_gfn = mslots[i + 1].base_gfn);\n"
+ "> > > > +\t\tWARN_ON_ONCE(memslot->base_gfn == mslots[i + 1].base_gfn);\n"
  "> > > \n"
  "> > > Will this trigger?  Note that in __kvm_set_memory_region() we have\n"
  "> > > already checked overlap of memslots.\n"
@@ -151,6 +147,10 @@
  "\n"
  "This is also another reason I'd like to keep the WARN_ONs.  When this code\n"
  "goes awry, the result is usually silent corruption and delayed explosions,\n"
- i.e. failures that absolutely suck to debug.
+ "i.e. failures that absolutely suck to debug.\n"
+ "_______________________________________________\n"
+ "kvmarm mailing list\n"
+ "kvmarm@lists.cs.columbia.edu\n"
+ https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
 
-6b19957151838dbec7eefc3aad1df427176cf8bc8f7e5c5516ff23c41e95e850
+95f40dadb30d737c9ae8202d8b56083cff86d7c8d4761ec0a09a6a8a57bf6de1
