NetBSD Problem Report #53311
From www@NetBSD.org Thu May 24 12:58:55 2018
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id E8E537A1E9
for <gnats-bugs@gnats.NetBSD.org>; Thu, 24 May 2018 12:58:55 +0000 (UTC)
Message-Id: <20180524125854.D7FCF7A221@mollari.NetBSD.org>
Date: Thu, 24 May 2018 12:58:54 +0000 (UTC)
From: prlw1@cam.ac.uk
Reply-To: prlw1@cam.ac.uk
To: gnats-bugs@NetBSD.org
Subject: boot netbsd -d panics
X-Send-Pr-Version: www-1.0
>Number: 53311
>Category: kern
>Synopsis: boot netbsd -d panics
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu May 24 13:00:00 +0000 2018
>Closed-Date:
>Last-Modified: Tue Nov 17 11:05:37 +0000 2020
>Originator: Patrick Welche
>Release: NetBSD-8.99.18/amd64
>Organization:
>Environment:
>Description:
boot netbsd -vx works
boot netbsd -d panics, but no serial console on either machine
so don't know what
One machine had ordinary old bootblocks, the other fresh netboot pxeboot_ia32.bin. ctrl-alt-esc does drop into ddb.
>How-To-Repeat:
boot netbsd -d
>Fix:
>Release-Note:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Thu, 24 May 2018 15:54:57 +0200
On Thu, May 24, 2018 at 01:00:00PM +0000, prlw1@cam.ac.uk wrote:
> boot netbsd -d panics, but no serial console on either machine
> so don't know what
For me it just hangs on one machine (bios console) and reboots
with parts of a kernel panic on a machine with serial console:
Press return to boot now, any other key for boot menu
booting hd0a:netbsd - starting in 0 seconds.
> boot -d
18225128+820032+1277120 [1036113+1149408+800069]=0x16d9828
[ 1.0000000] fatal breakpoint trap in supervisor mode
[ 1.0000000] trap type 1 code 0 rip 0xffffffff8021da75 cs 0x8 rflags 0x202 cr2 0 ilevel 0x8 rsp 0xffffffff818dfea0
[ 1.0000000] curlwp 0xffffffff81481f00 pid 0.1 lowest kstack 0xffffffff818db2c0
and:
(gdb) x/16i 0xffffffff8021da70
0xffffffff8021da70 <breakpoint>: push %rbp
0xffffffff8021da71 <breakpoint+1>: mov %rsp,%rbp
0xffffffff8021da74 <breakpoint+4>: int3
0xffffffff8021da75 <breakpoint+5>: leaveq
0xffffffff8021da76 <breakpoint+6>: retq
0xffffffff8021da77: nop
Martin
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Fri, 25 May 2018 15:39:52 +0200
This also affects i386 and (argh!) netbsd-8 as well.
Martin
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Fri, 25 May 2018 17:37:44 +0300
On Thu, May 24, 2018 at 13:00:00 +0000, prlw1@cam.ac.uk wrote:
> boot netbsd -d
I think this is caused by the automatic bt that is now performed when
entering ddb. I have a current'ish VM with a kernel from late January
that is before that change. I can boot -d and get to the ddb prompt
and continue to the normal boot. But if at that ddb prompt I do bt, i
get triple fault.
Under VirtualBox with --debug - when the machine is sitting at that
ddb prompt the EBP is c1516be4, when it triple faults esp=c1512fc0
ebp=c15130dc, so it looks like bt runs out of kernel stack in an
unbound recursion.
-uwe
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Fri, 25 May 2018 17:53:53 +0300
On Fri, May 25, 2018 at 17:37:44 +0300, Valery Ushakov wrote:
> Under VirtualBox with --debug - when the machine is sitting at that
> ddb prompt the EBP is c1516be4, when it triple faults esp=c1512fc0
> ebp=c15130dc, so it looks like bt runs out of kernel stack in an
> unbound recursion.
Actually, any attempts to examine data in the VM (including addresses
that should be valid, like kernel text) give me VERR_PAGE_TABLE_NOT_PRESENT
-uwe
From: Andreas Gustafsson <gson@gson.org>
To: prlw1@cam.ac.uk, ozaki-r@NetBSD.org, gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 13:36:54 +0300
By bisection, I found that the problem started with the following
commit:
2018.03.16.04.48.19 ozaki-r src/sys/arch/x86/x86/db_memrw.c 1.6
I suggest reverting it (and its pullup).
--
Andreas Gustafsson, gson@gson.org
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: Andreas Gustafsson <gson@gson.org>
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 15:07:16 +0300
On Sun, May 27, 2018 at 10:40:00 +0000, Andreas Gustafsson wrote:
> By bisection, I found that the problem started with the following
> commit:
>
> 2018.03.16.04.48.19 ozaki-r src/sys/arch/x86/x86/db_memrw.c 1.6
>
> I suggest reverting it (and its pullup).
This is from March 2018. The boot -d + bt triple fault that I
reported above is on i386 with 8.99.12 from late January 2018. So
that's probably not the whole story.
-uwe
From: Andreas Gustafsson <gson@gson.org>
To: Valery Ushakov <uwe@stderr.spb.ru>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 15:41:46 +0300
Valery Ushakov wrote:
> > By bisection, I found that the problem started with the following
> > commit:
> >
> > 2018.03.16.04.48.19 ozaki-r src/sys/arch/x86/x86/db_memrw.c 1.6
> >
> > I suggest reverting it (and its pullup).
>
> This is from March 2018. The boot -d + bt triple fault that I
> reported above is on i386 with 8.99.12 from late January 2018. So
> that's probably not the whole story.
To me it looks like "boot netbsd -d panics" (immediately) and
"entering bt after boot -d causes triple fault" are two separate
problems and ought to have separate PRs. If you file a PR about
the latter, I'll be happy to bisect it, too.
--
Andreas Gustafsson, gson@gson.org
From: Valery Ushakov <uwe@stderr.spb.ru>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 16:05:28 +0300
On Sun, May 27, 2018 at 15:41:46 +0300, Andreas Gustafsson wrote:
> Valery Ushakov wrote:
> > > By bisection, I found that the problem started with the following
> > > commit:
> > >
> > > 2018.03.16.04.48.19 ozaki-r src/sys/arch/x86/x86/db_memrw.c 1.6
> > >
> > > I suggest reverting it (and its pullup).
> >
> > This is from March 2018. The boot -d + bt triple fault that I
> > reported above is on i386 with 8.99.12 from late January 2018. So
> > that's probably not the whole story.
>
> To me it looks like "boot netbsd -d panics" (immediately) and
> "entering bt after boot -d causes triple fault" are two separate
> problems
The timeline I see is
- entering "bt" after "boot -d" causes triple fault (virtualbox guru)
with late January kernel on i386
- "bt" is now executed automatically when entering ddb, committed on
February 17
http://mail-index.netbsd.org/source-changes/2018/02/17/msg092275.html
- "boot -d" causes panic/reset on real hardware
I may be infering wrong conclusions.
Also, the latter report is for amd64, while the triple fault I see is
on i386. I found another VM that is amd64 and has kerel from Feb 15,
and it doesn't show that problem - bt after boot -d works ok.
Did you bisect/test on amd64 or i386? If that was only on amd64, does
the kernel before the commit you identified as problematic also work
on i386?
-uwe
From: Andreas Gustafsson <gson@gson.org>
To: Valery Ushakov <uwe@stderr.spb.ru>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 16:44:07 +0300
Valery Ushakov wrote:
> Did you bisect/test on amd64 or i386?
On amd64, using real hardware, searching for when the ddb prompt
stopped appearing after "boot -d".
> If that was only on amd64, does the kernel before the commit you
> identified as problematic also work on i386?
I can rerun my test scripts against i386, but the definition of "works"
will still be the same: "after boot -d, a ddb prompt appears". If you
would like me to test for a different problem than the ddb prompt not
appearing, I must still insist on a separate PR to formally define the
problem I am to test for.
--
Andreas Gustafsson, gson@gson.org
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, prlw1@cam.ac.uk
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 10:21:05 -0400
On May 27, 12:10pm, uwe@stderr.spb.ru (Valery Ushakov) wrote:
-- Subject: Re: kern/53311: boot netbsd -d panics
| The following reply was made to PR kern/53311; it has been noted by GNATS.
|
| From: Valery Ushakov <uwe@stderr.spb.ru>
| To: gnats-bugs@NetBSD.org
| Cc: Andreas Gustafsson <gson@gson.org>
| Subject: Re: kern/53311: boot netbsd -d panics
| Date: Sun, 27 May 2018 15:07:16 +0300
|
| On Sun, May 27, 2018 at 10:40:00 +0000, Andreas Gustafsson wrote:
|
| > By bisection, I found that the problem started with the following
| > commit:
| >
| > 2018.03.16.04.48.19 ozaki-r src/sys/arch/x86/x86/db_memrw.c 1.6
| >
| > I suggest reverting it (and its pullup).
|
| This is from March 2018. The boot -d + bt triple fault that I
| reported above is on i386 with 8.99.12 from late January 2018. So
| that's probably not the whole story.
Indeed, but perhaps a simple way to avoid it right now is:
Index: db_memrw.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/x86/db_memrw.c,v
retrieving revision 1.6
diff -u -p -u -r1.6 db_memrw.c
--- db_memrw.c 16 Mar 2018 04:48:19 -0000 1.6
+++ db_memrw.c 27 May 2018 14:20:00 -0000
@@ -70,6 +70,9 @@ db_validate_address(vaddr_t addr)
struct proc *p = curproc;
struct pmap *pmap;
+ if (cold)
+ return true;
+
if (!p || !p->p_vmspace || !p->p_vmspace->vm_map.pmap ||
addr >= VM_MIN_KERNEL_ADDRESS
)
From: Valery Ushakov <uwe@stderr.spb.ru>
To: Andreas Gustafsson <gson@gson.org>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 18:09:48 +0300
On Sun, May 27, 2018 at 16:44:07 +0300, Andreas Gustafsson wrote:
> Valery Ushakov wrote:
> > Did you bisect/test on amd64 or i386?
>
> On amd64, using real hardware, searching for when the ddb prompt
> stopped appearing after "boot -d".
>
> > If that was only on amd64, does the kernel before the commit you
> > identified as problematic also work on i386?
>
> I can rerun my test scripts against i386, but the definition of "works"
> will still be the same: "after boot -d, a ddb prompt appears".
Well, does it? martin@ mentioned in the PR that i386 is affected by
this bug.
-uwe
From: Andreas Gustafsson <gson@gson.org>
To: Valery Ushakov <uwe@stderr.spb.ru>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 20:22:10 +0300
Valery Ushakov wrote:
> Well, does it? martin@ mentioned in the PR that i386 is affected by
> this bug.
I have now run the test with NetBSD/i386 (running on 64-bit capable
hardware) using sources from immediately before and after the commit
identified by the amd64 bisection, and the results are the same as
with NetBSD/amd64:
source date 2018.03.16.04.45.20: the ddb prompt appears
source date 2018.03.16.04.48.19: the ddb prompt does not appear
--
Andreas Gustafsson, gson@gson.org
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 27 May 2018 22:13:03 +0300
On Sun, May 27, 2018 at 16:05:28 +0300, Valery Ushakov wrote:
> On Sun, May 27, 2018 at 15:41:46 +0300, Andreas Gustafsson wrote:
>
> > Valery Ushakov wrote:
> > > > By bisection, I found that the problem started with the following
> > > > commit:
> > > >
> > > > 2018.03.16.04.48.19 ozaki-r src/sys/arch/x86/x86/db_memrw.c 1.6
> > > >
> > > > I suggest reverting it (and its pullup).
> > >
> > > This is from March 2018. The boot -d + bt triple fault that I
> > > reported above is on i386 with 8.99.12 from late January 2018. So
> > > that's probably not the whole story.
> >
> > To me it looks like "boot netbsd -d panics" (immediately) and
> > "entering bt after boot -d causes triple fault" are two separate
> > problems
>
> The timeline I see is
>
> - entering "bt" after "boot -d" causes triple fault (virtualbox guru)
> with late January kernel on i386
>
> - "bt" is now executed automatically when entering ddb, committed on
> February 17
>
> http://mail-index.netbsd.org/source-changes/2018/02/17/msg092275.html
>
> - "boot -d" causes panic/reset on real hardware
Ok, so what I was wrong about is the automatic "bt" in newer kernels.
That only happens on panic, not every time ddb is entered. But
otherwise the problem is still the same: pmap is messed up. The
committ by ozaki-r@ is just an innocent victim here, it walks into the
pmap mess when it checks the breakpoint address. Reverting that
change makes no sense.
-uwe
State-Changed-From-To: open->closed
State-Changed-By: maxv@NetBSD.org
State-Changed-When: Sun, 24 Mar 2019 11:46:26 +0000
State-Changed-Why:
fixed
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Sun, 24 Mar 2019 23:11:06 +0200
For the record, I can confirm that the issue was fixed by the
following commits:
2019.03.10.16.30.01 maxv src/sys/arch/x86/include/pmap.h 1.100
2019.03.10.16.30.01 maxv src/sys/arch/x86/x86/pmap.c 1.330
2019.03.10.16.30.01 maxv src/sys/arch/xen/x86/xen_pmap.c 1.31
--
Andreas Gustafsson, gson@gson.org
From: Edgar =?iso-8859-1?B?RnXf?= <ef@math.uni-bonn.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/53311: boot netbsd -d panics
Date: Tue, 17 Nov 2020 11:54:06 +0100
--6Nae48J/T25AfBN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I've tried to back-port the three relevant commits to -8, which seems to be mostly string substitution on various PTE_ symbols. Note that ptp_masks has changed its meaning from -8 to -current (as far as I can tell).
I don't know what to do to the RCS/CVS/whatever IDs.
I'm running a modified kernel since yesterday. I could boot -d and it seems to behave. Nevertheless, someone In The Know should certainly review my patches.
The fix for -9 should be easier, I guess.
--6Nae48J/T25AfBN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pmap.h.diff"
Index: sys/arch/x86/include/pmap.h
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/include/pmap.h,v
retrieving revision 1.64.6.2
diff -u -r1.64.6.2 pmap.h
--- sys/arch/x86/include/pmap.h 22 Mar 2018 16:59:04 -0000 1.64.6.2
+++ sys/arch/x86/include/pmap.h 13 Nov 2020 14:59:01 -0000
@@ -1,4 +1,4 @@
-/* $NetBSD: pmap.h,v 1.64.6.2 2018/03/22 16:59:04 martin Exp $ */
+/* $NetBSD: pmap.h,v 1.100 2019/03/10 16:30:01 maxv Exp $ */
/*
* Copyright (c) 1997 Charles D. Cranor and Washington University.
@@ -291,7 +291,8 @@
pd_entry_t * const **);
void pmap_unmap_ptes(struct pmap *, struct pmap *);
-int pmap_pdes_invalid(vaddr_t, pd_entry_t * const *, pd_entry_t *);
+bool pmap_pdes_valid(vaddr_t, pd_entry_t * const *, pd_entry_t *,
+ int *lastlvl);
u_int x86_mmap_flags(paddr_t);
@@ -342,12 +343,6 @@
* inline functions
*/
-__inline static bool __unused
-pmap_pdes_valid(vaddr_t va, pd_entry_t * const *pdes, pd_entry_t *lastpde)
-{
- return pmap_pdes_invalid(va, pdes, lastpde) == 0;
-}
-
/*
* pmap_update_pg: flush one page from the TLB (or flush the whole thing
* if hardware doesn't support one-page flushing)
--6Nae48J/T25AfBN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="pmap.c.diff"
Index: sys/arch/x86/x86/pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/x86/x86/pmap.c,v
retrieving revision 1.245.6.6
diff -u -r1.245.6.6 pmap.c
--- sys/arch/x86/x86/pmap.c 22 Mar 2018 16:59:04 -0000 1.245.6.6
+++ sys/arch/x86/x86/pmap.c 13 Nov 2020 15:37:49 -0000
@@ -28,6 +28,7 @@
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
+/* $NetBSD: pmap.c,v 1.330 2019/03/10 16:30:01 maxv Exp $ */
/*
* Copyright (c) 2007 Manuel Bouyer.
@@ -171,7 +172,7 @@
*/
#include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: pmap.c,v 1.245.6.6 2018/03/22 16:59:04 martin Exp $");
+__KERNEL_RCSID(0, "$NetBSD: pmap.c,v XXX $");
#include "opt_user_ldt.h"
#include "opt_lockdebug.h"
@@ -3059,22 +3060,28 @@
* some misc. functions
*/
-int
-pmap_pdes_invalid(vaddr_t va, pd_entry_t * const *pdes, pd_entry_t *lastpde)
+bool
+pmap_pdes_valid(vaddr_t va, pd_entry_t * const *pdes, pd_entry_t *lastpde,
+ int *lastlvl)
{
- int i;
unsigned long index;
pd_entry_t pde;
+ int i;
for (i = PTP_LEVELS; i > 1; i--) {
index = pl_i(va, i);
pde = pdes[i - 2][index];
- if ((pde & PG_V) == 0)
- return i;
+ if ((pde & PG_V) == 0) {
+ *lastlvl = i;
+ return false;
+ }
+ if (pde & PG_PS)
+ break;
}
if (lastpde != NULL)
*lastpde = pde;
- return 0;
+ *lastlvl = i;
+ return true;
}
/*
@@ -3092,6 +3099,7 @@
paddr_t pa;
lwp_t *l;
bool hard, rv;
+ int lvl;
#ifdef __HAVE_DIRECT_MAP
if (va >= PMAP_DIRECT_BASE && va < PMAP_DIRECT_END) {
@@ -3108,8 +3116,8 @@
kpreempt_disable();
ci = l->l_cpu;
- if (__predict_true(!ci->ci_want_pmapload && ci->ci_pmap == pmap) ||
- pmap == pmap_kernel()) {
+ if (pmap == pmap_kernel() ||
+ __predict_true(!ci->ci_want_pmapload && ci->ci_pmap == pmap)) {
/*
* no need to lock, because it's pmap_kernel() or our
* own pmap and is active. if a user pmap, the caller
@@ -3126,14 +3134,17 @@
hard = true;
pmap_map_ptes(pmap, &pmap2, &ptes, &pdes);
}
- if (pmap_pdes_valid(va, pdes, &pde)) {
- pte = ptes[pl1_i(va)];
- if (pde & PG_PS) {
+ if (pmap_pdes_valid(va, pdes, &pde, &lvl)) {
+ if (lvl == 2) {
pa = (pde & PG_LGFRAME) | (va & (NBPD_L2 - 1));
rv = true;
- } else if (__predict_true((pte & PG_V) != 0)) {
- pa = pmap_pte2pa(pte) | (va & (NBPD_L1 - 1));
- rv = true;
+ } else {
+ KASSERT(lvl == 1);
+ pte = ptes[pl1_i(va)];
+ if (__predict_true((pte & PG_V) != 0)) {
+ pa = pmap_pte2pa(pte) | (va & (NBPD_L1 - 1));
+ rv = true;
+ }
}
}
if (__predict_false(hard)) {
@@ -3552,6 +3563,7 @@
vaddr_t blkendva, va = sva;
struct vm_page *ptp;
struct pmap *pmap2;
+ int lvl;
kpreempt_disable();
pmap_map_ptes(pmap, &pmap2, &ptes, &pdes); /* locks pmap */
@@ -3561,7 +3573,8 @@
*/
if (va + PAGE_SIZE == eva) {
- if (pmap_pdes_valid(va, pdes, &pde)) {
+ if (pmap_pdes_valid(va, pdes, &pde, &lvl)) {
+ KASSERT(lvl == 1);
/* PA of the PTP */
ptppa = pmap_pte2pa(pde);
@@ -3588,8 +3601,6 @@
pmap_free_ptp(pmap, ptp, va, ptes, pdes);
}
} else for (/* null */ ; va < eva ; va = blkendva) {
- int lvl;
-
/* determine range of block */
blkendva = x86_round_pdr(va+1);
if (blkendva > eva)
@@ -3609,14 +3620,14 @@
panic("PTE space accessed");
}
- lvl = pmap_pdes_invalid(va, pdes, &pde);
- if (lvl != 0) {
+ if (!pmap_pdes_valid(va, pdes, &pde, &lvl)) {
/*
* skip a range corresponding to an invalid pde.
*/
blkendva = (va & ptp_masks[lvl - 1]) + nbpd[lvl - 1];
continue;
}
+ KASSERT(lvl == 1);
/* PA of the PTP */
ptppa = pmap_pte2pa(pde);
@@ -4031,6 +4042,7 @@
pt_entry_t * const *pdes;
struct pmap *pmap2;
vaddr_t blockend, va;
+ int lvl;
KASSERT(curlwp->l_md.md_gc_pmap != pmap);
@@ -4072,10 +4084,11 @@
}
/* Is it a valid block? */
- if (!pmap_pdes_valid(va, pdes, NULL)) {
+ if (!pmap_pdes_valid(va, pdes, NULL, &lvl)) {
continue;
}
KASSERT(va < VM_MAXUSER_ADDRESS || va >= VM_MAX_ADDRESS);
+ KASSERT(lvl == 1);
spte = &ptes[pl1_i(va)];
epte = &ptes[pl1_i(blockend)];
@@ -4116,14 +4129,16 @@
pt_entry_t *ptes, *ptep, opte;
pd_entry_t * const *pdes;
struct pmap *pmap2;
+ int lvl;
/* Acquire pmap. */
kpreempt_disable();
pmap_map_ptes(pmap, &pmap2, &ptes, &pdes);
- if (!pmap_pdes_valid(va, pdes, NULL)) {
+ if (!pmap_pdes_valid(va, pdes, NULL, &lvl)) {
panic("pmap_unwire: invalid PDE");
}
+ KASSERT(lvl == 1);
ptep = &ptes[pl1_i(va)];
opte = *ptep;
@@ -4631,6 +4646,7 @@
pd_entry_t * const *pdes;
struct pmap *pmap2;
vaddr_t blkendva;
+ int lvl;
/*
* if end is out of range truncate.
@@ -4659,8 +4675,9 @@
blkendva = eva;
/* valid block? */
- if (!pmap_pdes_valid(sva, pdes, NULL))
+ if (!pmap_pdes_valid(sva, pdes, NULL, &lvl))
continue;
+ KASSERT(lvl == 1);
pte = &ptes[pl1_i(sva)];
for (/* null */; sva < blkendva ; sva += PAGE_SIZE, pte++) {
--6Nae48J/T25AfBN4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="xen_pmap.c.diff"
Index: sys/arch/xen/x86/xen_pmap.c
===================================================================
RCS file: /cvsroot/src/sys/arch/xen/x86/xen_pmap.c,v
retrieving revision 1.26
diff -u -r1.26 xen_pmap.c
--- sys/arch/xen/x86/xen_pmap.c 23 Mar 2017 18:08:06 -0000 1.26
+++ sys/arch/xen/x86/xen_pmap.c 13 Nov 2020 14:59:41 -0000
@@ -1,4 +1,4 @@
-/* $NetBSD: xen_pmap.c,v 1.26 2017/03/23 18:08:06 maxv Exp $ */
+/* $NetBSD: xen_pmap.c,v 1.31 2019/03/10 16:30:01 maxv Exp $ */
/*
* Copyright (c) 2007 Manuel Bouyer.
@@ -101,7 +101,7 @@
*/
#include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: xen_pmap.c,v 1.26 2017/03/23 18:08:06 maxv Exp $");
+__KERNEL_RCSID(0, "$NetBSD: xen_pmap.c,v XXX $");
#include "opt_user_ldt.h"
#include "opt_lockdebug.h"
@@ -212,15 +212,17 @@
pd_entry_t pde;
pd_entry_t * const *pdes;
struct pmap *pmap2;
+ int lvl;
kpreempt_disable();
pmap_map_ptes(pmap, &pmap2, &ptes, &pdes);
- if (!pmap_pdes_valid(va, pdes, &pde)) {
+ if (!pmap_pdes_valid(va, pdes, &pde, &lvl)) {
pmap_unmap_ptes(pmap, pmap2);
kpreempt_enable();
return false;
}
+ KASSERT(lvl == 1);
pte = ptes[pl1_i(va)];
pmap_unmap_ptes(pmap, pmap2);
kpreempt_enable();
--6Nae48J/T25AfBN4--
State-Changed-From-To: closed->open
State-Changed-By: gson@NetBSD.org
State-Changed-When: Tue, 17 Nov 2020 11:05:37 +0000
State-Changed-Why:
Reopening as requested by Edgar Fuß; -8 is reportedly broken.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home