[src/trunk]: src/sys/arch/amd64/amd64 Improve two comments and a KASSERT.

[maxv <maxv%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/3b565d4ce98c
branches:  trunk
changeset: 358857:3b565d4ce98c
user:      maxv <maxv%NetBSD.org@localhost>
date:      Sat Jan 20 07:43:28 2018 +0000

description:
Improve two comments and a KASSERT.

diffstat:

 sys/arch/amd64/amd64/machdep.c |  13 ++++++-------
 1 files changed, 6 insertions(+), 7 deletions(-)

diffs (48 lines):

diff -r 5d98f15a5780 -r 3b565d4ce98c sys/arch/amd64/amd64/machdep.c
--- a/sys/arch/amd64/amd64/machdep.c    Sat Jan 20 03:50:28 2018 +0000
+++ b/sys/arch/amd64/amd64/machdep.c    Sat Jan 20 07:43:28 2018 +0000
@@ -1,4 +1,4 @@
-/*     $NetBSD: machdep.c,v 1.291 2018/01/18 07:25:34 maxv Exp $       */
+/*     $NetBSD: machdep.c,v 1.292 2018/01/20 07:43:28 maxv Exp $       */
 
 /*
  * Copyright (c) 1996, 1997, 1998, 2000, 2006, 2007, 2008, 2011
@@ -110,7 +110,7 @@
  */
 
 #include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: machdep.c,v 1.291 2018/01/18 07:25:34 maxv Exp $");
+__KERNEL_RCSID(0, "$NetBSD: machdep.c,v 1.292 2018/01/20 07:43:28 maxv Exp $");
 
 /* #define XENDEBUG_LOW  */
 
@@ -2478,7 +2478,7 @@
        KASSERT(pmap != pmap_kernel());
        KASSERT(mutex_owned(pmap->pm_lock));
        KASSERT(kpreempt_disabled());
-       KASSERT(index <= 255);
+       KASSERT(index < 255);
 
        for (CPU_INFO_FOREACH(cii, ci)) {
                cid = cpu_index(ci);
@@ -2530,9 +2530,8 @@
            (ci->ci_svs_ursp0 % PAGE_SIZE));
 
        /*
-        * Enter the user rsp0. We don't need to flush the TLB here, it will
-        * be implicitly flushed when we reload CR3 next time we return to
-        * userland.
+        * Enter the user rsp0. We don't need to flush the TLB here, since
+        * the user page tables are not loaded.
         */
        pte = ci->ci_svs_rsp0_pte;
        *pte = L1_BASE[pl1_i(va)];
@@ -2549,7 +2548,7 @@
 
 /*
  * We may come here with the pmap unlocked. So read its PTEs atomically. If
- * a remote CPU is updating them at the same time, it's not that bad: the
+ * a remote CPU is updating them at the same time, it's not a problem: the
  * remote CPU will call svs_pmap_sync afterwards, and our updirpa will be
  * synchronized properly.
  */