NetBSD Problem Report #56900
From wiz@yt.nih.at Fri Jun 24 17:44:56 2022
Return-Path: <wiz@yt.nih.at>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.3 with cipher TLS_AES_256_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 C37D71A921F
for <gnats-bugs@gnats.NetBSD.org>; Fri, 24 Jun 2022 17:44:56 +0000 (UTC)
Message-Id: <20220624162852.161BA1CB6ADA@yt.nih.at>
Date: Fri, 24 Jun 2022 18:28:52 +0200 (CEST)
From: Thomas Klausner <wiz@NetBSD.org>
Reply-To: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@NetBSD.org
Subject: panic in uvm_map_findspace
X-Send-Pr-Version: 3.95
>Number: 56900
>Category: kern
>Synopsis: panic in uvm_map_findspace
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jun 24 17:45:00 +0000 2022
>Closed-Date: Sat Aug 05 16:33:16 +0000 2023
>Last-Modified: Sat Aug 05 16:33:16 +0000 2023
>Originator: Thomas Klausner
>Release: NetBSD 9.99.98
>Organization:
>Environment:
Architecture: x86_64
Machine: amd64
>Description:
Before the UVM changes from early June 2022, my system was stable.
Afterwards, when bulk building, I usually have about a panic after a couple hours, the last one
had this back trace:
panic: kernel diagnostic assertion “!topdown || hint <= orig_hint” failed: file “/usr/src/sys/uvm/uvm_map.c”, line 1795 map=0xffffc8415a1d9388 hint=0xfffffff944a00000 orig_hint=0x82000000 length=0x77e000000 uobj=0x0 uoffset=0xfffffffffffffffff align=0 flags=0x80710 entry=0xffffc8415a1d93e0 (uvm_map_findspace line 1998)
cpu0: begin traceback
vpanic()
kern_assert()
uvm_findspace_invariants() at netbsd:uvm_findspace_invariants+0x83
uvm_map_findspace() at netbsd:uvm_map_findspace()+0x1c6
uvm_map_prepare() at netbsd:uvm_map_prepare+0x1f6
uvm_map() at netbsd:uvm_map+0x70
uvm_mmap.part.0() at netbsd:vm_mmap.part.0+0x15a
sys_mmap() at netbsd:sys_mmap+0x42f
syscall() number 197
(Handcopied with autocorrection, but I have pictures if you want to verify something).
>How-To-Repeat:
Boot 9.99.98, start bulk build.
>Fix:
Backing out the changes makes the system stable again, but riastradh thinks this
might be just papering over an underlying (benign?) problem the new assertion detects.
>Release-Note:
>Audit-Trail:
From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Fri, 24 Jun 2022 20:04:44 +0200
--XwFBqNPNA03tvv54
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
I think it might be related to building openjdk17 or nodejs16, I had
work directories for these left-over after the panics.
And here's the diff I reverted locally to make my system stable again.
Thomas
--XwFBqNPNA03tvv54
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="uvm.diff"
Index: uvm_map.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_map.c,v
retrieving revision 1.394
retrieving revision 1.402
diff -u -r1.394 -r1.402
--- uvm_map.c 10 Apr 2022 09:50:46 -0000 1.394
+++ uvm_map.c 8 Jun 2022 16:55:00 -0000 1.402
@@ -1778,6 +1778,29 @@
return (0);
}
+static void
+uvm_findspace_invariants(struct vm_map *map, vaddr_t orig_hint, vaddr_t length,
+ struct uvm_object *uobj, voff_t uoffset, vsize_t align, int flags,
+ vaddr_t hint, struct vm_map_entry *entry, int line)
+{
+ const int topdown = map->flags & VM_MAP_TOPDOWN;
+
+ KASSERTMSG( topdown || hint >= orig_hint,
+ "map=%p hint=%#"PRIxVADDR" orig_hint=%#"PRIxVADDR
+ " length=%#"PRIxVSIZE" uobj=%p uoffset=%#llx align=%"PRIxVSIZE
+ " flags=%#x entry=%p (uvm_map_findspace line %d)",
+ map, hint, orig_hint,
+ length, uobj, (unsigned long long)uoffset, align,
+ flags, entry, line);
+ KASSERTMSG(!topdown || hint <= orig_hint,
+ "map=%p hint=%#"PRIxVADDR" orig_hint=%#"PRIxVADDR
+ " length=%#"PRIxVSIZE" uobj=%p uoffset=%#llx align=%"PRIxVSIZE
+ " flags=%#x entry=%p (uvm_map_findspace line %d)",
+ map, hint, orig_hint,
+ length, uobj, (unsigned long long)uoffset, align,
+ flags, entry, line);
+}
+
/*
* uvm_map_findspace: find "length" sized space in "map".
*
@@ -1796,10 +1819,14 @@
vaddr_t *result /* OUT */, struct uvm_object *uobj, voff_t uoffset,
vsize_t align, int flags)
{
- struct vm_map_entry *entry;
+#define INVARIANTS() \
+ uvm_findspace_invariants(map, orig_hint, length, uobj, uoffset, align,\
+ flags, hint, entry, __LINE__)
+ struct vm_map_entry *entry = NULL;
struct vm_map_entry *child, *prev, *tmp;
vaddr_t orig_hint __diagused;
const int topdown = map->flags & VM_MAP_TOPDOWN;
+ int avail;
UVMHIST_FUNC(__func__);
UVMHIST_CALLARGS(maphist, "(map=%#jx, hint=%#jx, len=%ju, flags=%#jx...",
(uintptr_t)map, hint, length, flags);
@@ -1813,12 +1840,17 @@
uvm_map_check(map, "map_findspace entry");
/*
- * remember the original hint. if we are aligning, then we
- * may have to try again with no alignment constraint if
- * we fail the first time.
+ * Clamp the hint to the VM map's min/max address, and remmeber
+ * the clamped original hint. Remember the original hint,
+ * clamped to the min/max address. If we are aligning, then we
+ * may have to try again with no alignment constraint if we
+ * fail the first time.
+ *
+ * We use the original hint to verify later that the search has
+ * been monotonic -- that is, nonincreasing or nondecreasing,
+ * according to topdown or !topdown respectively. But the
+ * clamping is not monotonic.
*/
-
- orig_hint = hint;
if (hint < vm_map_min(map)) { /* check ranges ... */
if (flags & UVM_FLAG_FIXED) {
UVMHIST_LOG(maphist,"<- VA below map range",0,0,0,0);
@@ -1831,6 +1863,8 @@
hint, vm_map_min(map), vm_map_max(map), 0);
return (NULL);
}
+ orig_hint = hint;
+ INVARIANTS();
UVMHIST_LOG(maphist,"<- VA %#jx vs range [%#jx->%#jx]",
hint, vm_map_min(map), vm_map_max(map), 0);
@@ -1839,8 +1873,10 @@
* hint may not be aligned properly; we need round up or down it
* before proceeding further.
*/
- if ((flags & UVM_FLAG_COLORMATCH) == 0)
+ if ((flags & UVM_FLAG_COLORMATCH) == 0) {
uvm_map_align_va(&hint, align, topdown);
+ INVARIANTS();
+ }
UVMHIST_LOG(maphist,"<- VA %#jx vs range [%#jx->%#jx]",
hint, vm_map_min(map), vm_map_max(map), 0);
@@ -1870,7 +1906,36 @@
* it, there would be four cases).
*/
- if ((flags & UVM_FLAG_FIXED) == 0 && hint == vm_map_min(map)) {
+ if ((flags & UVM_FLAG_FIXED) == 0 &&
+ hint == (topdown ? vm_map_max(map) : vm_map_min(map))) {
+ /*
+ * The uvm_map_findspace algorithm is monotonic -- for
+ * topdown VM it starts with a high hint and returns a
+ * lower free address; for !topdown VM it starts with a
+ * low hint and returns a higher free address. As an
+ * optimization, start with the first (highest for
+ * topdown, lowest for !topdown) free address.
+ *
+ * XXX This `optimization' probably doesn't actually do
+ * much in practice unless userland explicitly passes
+ * the VM map's minimum or maximum address, which
+ * varies from machine to machine (VM_MAX/MIN_ADDRESS,
+ * e.g. 0x7fbfdfeff000 on amd64 but 0xfffffffff000 on
+ * aarch64) and may vary according to other factors
+ * like sysctl vm.user_va0_disable. In particular, if
+ * the user specifies 0 as a hint to mmap, then mmap
+ * will choose a default address which is usually _not_
+ * VM_MAX/MIN_ADDRESS but something else instead like
+ * VM_MAX_ADDRESS - stack size - guard page overhead,
+ * in which case this branch is never hit.
+ *
+ * In fact, this branch appears to have been broken for
+ * two decades between when topdown was introduced in
+ * ~2003 and when it was adapted to handle the topdown
+ * case without violating the monotonicity assertion in
+ * 2022. Maybe Someone^TM should either ditch the
+ * optimization or find a better way to do it.
+ */
entry = map->first_free;
} else {
if (uvm_map_lookup_entry(map, hint, &entry)) {
@@ -1896,8 +1961,10 @@
/*
* See if given hint fits in this gap.
*/
- switch (uvm_map_space_avail(&hint, length,
- uoffset, align, flags, topdown, entry)) {
+ avail = uvm_map_space_avail(&hint, length,
+ uoffset, align, flags, topdown, entry);
+ INVARIANTS();
+ switch (avail) {
case 1:
goto found;
case -1:
@@ -1928,8 +1995,11 @@
/* Check slot before any entry */
hint = topdown ? entry->next->start - length : entry->end;
- switch (uvm_map_space_avail(&hint, length, uoffset, align, flags,
- topdown, entry)) {
+ INVARIANTS();
+ avail = uvm_map_space_avail(&hint, length, uoffset, align, flags,
+ topdown, entry);
+ INVARIANTS();
+ switch (avail) {
case 1:
goto found;
case -1:
@@ -1996,8 +2066,11 @@
if (hint < tmp->end)
hint = tmp->end;
}
- switch (uvm_map_space_avail(&hint, length, uoffset, align,
- flags, topdown, tmp)) {
+ INVARIANTS();
+ avail = uvm_map_space_avail(&hint, length, uoffset, align,
+ flags, topdown, tmp);
+ INVARIANTS();
+ switch (avail) {
case 1:
entry = tmp;
goto found;
@@ -2018,8 +2091,11 @@
KASSERT(orig_hint <= prev->end);
hint = prev->end;
}
- switch (uvm_map_space_avail(&hint, length, uoffset, align,
- flags, topdown, prev)) {
+ INVARIANTS();
+ avail = uvm_map_space_avail(&hint, length, uoffset, align,
+ flags, topdown, prev);
+ INVARIANTS();
+ switch (avail) {
case 1:
entry = prev;
goto found;
@@ -2059,8 +2135,11 @@
KASSERT(orig_hint <= tmp->end);
hint = tmp->end;
}
- switch (uvm_map_space_avail(&hint, length, uoffset, align,
- flags, topdown, tmp)) {
+ INVARIANTS();
+ avail = uvm_map_space_avail(&hint, length, uoffset, align,
+ flags, topdown, tmp);
+ INVARIANTS();
+ switch (avail) {
case 1:
entry = tmp;
goto found;
@@ -2080,13 +2159,17 @@
* entry->next->start = VA of end of current gap
*/
+ INVARIANTS();
for (;;) {
/* Update hint for current gap. */
hint = topdown ? entry->next->start - length : entry->end;
+ INVARIANTS();
/* See if it fits. */
- switch (uvm_map_space_avail(&hint, length, uoffset, align,
- flags, topdown, entry)) {
+ avail = uvm_map_space_avail(&hint, length, uoffset, align,
+ flags, topdown, entry);
+ INVARIANTS();
+ switch (avail) {
case 1:
goto found;
case -1:
@@ -2115,10 +2198,7 @@
SAVE_HINT(map, map->hint, entry);
*result = hint;
UVMHIST_LOG(maphist,"<- got it! (result=%#jx)", hint, 0,0,0);
- KASSERTMSG( topdown || hint >= orig_hint, "hint: %#jx, orig_hint: %#jx",
- (uintmax_t)hint, (uintmax_t)orig_hint);
- KASSERTMSG(!topdown || hint <= orig_hint, "hint: %#jx, orig_hint: %#jx",
- (uintmax_t)hint, (uintmax_t)orig_hint);
+ INVARIANTS();
KASSERT(entry->end <= hint);
KASSERT(hint + length <= entry->next->start);
return (entry);
@@ -2132,6 +2212,7 @@
UVMHIST_LOG(maphist, "<- failed (notfound)", 0,0,0,0);
return (NULL);
+#undef INVARIANTS
}
/*
@@ -5089,12 +5170,13 @@
entry->aref.ar_pageoff);
(*pr)(
"\tsubmap=%c, cow=%c, nc=%c, prot(max)=%d/%d, inh=%d, "
- "wc=%d, adv=%d\n",
+ "wc=%d, adv=%d%s\n",
(entry->etype & UVM_ET_SUBMAP) ? 'T' : 'F',
(entry->etype & UVM_ET_COPYONWRITE) ? 'T' : 'F',
(entry->etype & UVM_ET_NEEDSCOPY) ? 'T' : 'F',
entry->protection, entry->max_protection,
- entry->inheritance, entry->wired_count, entry->advice);
+ entry->inheritance, entry->wired_count, entry->advice,
+ entry == map->first_free ? " (first_free)" : "");
}
}
Index: uvm_mmap.c
===================================================================
RCS file: /cvsroot/src/sys/uvm/uvm_mmap.c,v
retrieving revision 1.179
retrieving revision 1.180
diff -u -r1.179 -r1.180
--- uvm_mmap.c 19 Apr 2022 22:53:34 -0000 1.179
+++ uvm_mmap.c 4 Jun 2022 20:54:03 -0000 1.180
@@ -277,7 +277,8 @@
vsize_t size, pageoff, newsize;
vm_prot_t prot, maxprot, extraprot;
int flags, fd, advice;
- vaddr_t defaddr;
+ vaddr_t defaddr = 0; /* XXXGCC */
+ bool addrhint = false;
struct file *fp = NULL;
struct uvm_object *uobj;
int error;
@@ -349,6 +350,12 @@
addr = MAX(addr, defaddr);
else
addr = MIN(addr, defaddr);
+
+ /*
+ * If addr is nonzero and not the default, then the
+ * address is a hint.
+ */
+ addrhint = (addr != 0 && addr != defaddr);
}
/*
@@ -399,11 +406,30 @@
pax_aslr_mmap(l, &addr, orig_addr, flags);
/*
- * now let kernel internal function uvm_mmap do the work.
+ * Now let kernel internal function uvm_mmap do the work.
+ *
+ * If the user provided a hint, take a reference to uobj in
+ * case the first attempt to satisfy the hint fails, so we can
+ * try again with the default address.
*/
-
+ if (addrhint) {
+ if (uobj)
+ (*uobj->pgops->pgo_reference)(uobj);
+ }
error = uvm_mmap(&p->p_vmspace->vm_map, &addr, size, prot, maxprot,
flags, advice, uobj, pos, p->p_rlimit[RLIMIT_MEMLOCK].rlim_cur);
+ if (addrhint) {
+ if (error) {
+ addr = defaddr;
+ pax_aslr_mmap(l, &addr, orig_addr, flags);
+ error = uvm_mmap(&p->p_vmspace->vm_map, &addr, size,
+ prot, maxprot, flags, advice, uobj, pos,
+ p->p_rlimit[RLIMIT_MEMLOCK].rlim_cur);
+ } else if (uobj) {
+ /* Release the exta reference we took. */
+ (*uobj->pgops->pgo_detach)(uobj);
+ }
+ }
/* remember to add offset */
*retval = (register_t)(addr + pageoff);
@@ -818,9 +844,12 @@
* - used by sys_mmap and various framebuffers
* - uobj is a struct uvm_object pointer or NULL for MAP_ANON
* - caller must page-align the file offset
+ *
+ * XXX This appears to leak the uobj in various error branches? Need
+ * to clean up the contract around uobj reference.
*/
-int
+static int
uvm_mmap(struct vm_map *map, vaddr_t *addr, vsize_t size, vm_prot_t prot,
vm_prot_t maxprot, int flags, int advice, struct uvm_object *uobj,
voff_t foff, vsize_t locklimit)
--XwFBqNPNA03tvv54--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Sun, 26 Jun 2022 21:14:45 +0000
syzbot found a reproducer for what is probably the same problem:
https://syzkaller.appspot.com/bug?id=3De542bcf59b2564cca1cb38c12f076fb08dca=
c37e
The crux of the reproducer at
https://syzkaller.appspot.com/text?tag=3DReproC&x=3D136e190bf00000
is:
syscall(SYS_compat_43_ommap, 0x20ffd000ul, 0x20ffd000ul, 0ul, 2ul, -1, 0u=
l);
Using compat_43_ommap instead of mmap is probably not particularly
significant here; most likely there is just some edge case in the
uvm_map_findspace logic that we're missing -- really, the whole of
uvm_map_findspace is a twisty maze of sharp edge cases waiting to
impale unwary passersby, and the whole thing should be reorganized
more coherently with assertions of invariants.
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Mon, 27 Jun 2022 06:05:16 -0000 (UTC)
riastradh@NetBSD.org (Taylor R Campbell) writes:
> Using compat_43_ommap instead of mmap is probably not particularly
> significant here; most likely there is just some edge case in the
> uvm_map_findspace logic that we're missing -- really, the whole of
> uvm_map_findspace is a twisty maze of sharp edge cases waiting to
> impale unwary passersby, and the whole thing should be reorganized
> more coherently with assertions of invariants.
The "invariants" really don't make sense. These conditions just check
for a heuristic that cannot be enforced without producing the issue
that you try to fix.
The code can be simplified very easily, but you have to define
the "bottom up" strategy. My guess is that there is none, it
just happens to work by chance.
From: "John D. Baker" <jdbaker@consolidated.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Wed, 6 Jul 2022 09:02:06 -0500 (CDT)
I think I've now run into the issue in this PR myself.
While building "lang/openjdk17", the machine panicked with:
[...]
[ 85301.7124678] panic: kernel diagnostic assertion "!topdown || hint <= orig_hi
nt" failed: file "/x/current/src/sys/uvm/uvm_map.c", line 1795 map=0xd0a400f4 hi
nt=0xff900000 orig_hint=0x1524000 length=0xb3f00000 uobj=0x0 uoffset=0xfffffffff
fffffff align=0 flags=0x80710 entry=0xd1dcbbc0 (uvm_map_findspace line 1998)
[ 85301.7124678] cpu1: Begin traceback...
[ 85301.7124678] vpanic(c08b18cc,f507ed44,f507ed8c,c059ecb5,c08b18cc,c0844aef,c0
8b2272,c08b18a8,703,d0a400f4) at netbsd:vpanic+0x196
[ 85301.7124678] kern_assert(c08b18cc,c0844aef,c08b2272,c08b18a8,703,d0a400f4,ff
900000,1524000,b3f00000,0) at netbsd:kern_assert+0x23
[ 85301.7124678] uvm_findspace_invariants(0,ffffffff,ffffffff,0,80710,ff900000,d
1dcbbc0,7ce,f507edd8,f507ede4) at netbsd:uvm_findspace_invariants+0x93
[ 85301.7124678] uvm_map_findspace(d0a400f4,ff900000,b3f00000,f507ee2c,0,fffffff
f,ffffffff,0,80710,d0a400f8) at netbsd:uvm_map_findspace+0x1a2
[ 85301.7124678] uvm_map_prepare(d0a400f4,1524000,b3f00000,0,ffffffff,ffffffff,0
,80710,f507ee50,d1da8d80) at netbsd:uvm_map_prepare+0x1e9
[ 85301.7224689] uvm_map(d0a400f4,f507ef10,b3f00000,0,ffffffff,ffffffff,0,80710,
d1dc0440,80000) at netbsd:uvm_map+0x76
[ 85301.7224689] uvm_mmap.part.0(0,7,1042,0,0,ffffffff,ffffffff,3fd55000,e2f4734
0,c05a1a9d) at netbsd:uvm_mmap.part.0+0x169
[ 85301.7224689] sys_mmap(d1dc0440,f507ef68,f507ef60,e410b188,1,c5,f507ef60,f507
ef68,0,0) at netbsd:sys_mmap+0x522
[ 85301.7224689] syscall() at netbsd:syscall+0x17c
[ 85301.7224689] --- syscall (number 197) ---
[ 85301.7224689] b535e597:
[ 85301.7224689] cpu1: End traceback...
[ 85301.7224689] dumping to dev 0,1 offset 8726319
[ 85301.7224689] dump <4>[ 85353.9914886] coretemp3: workqueue busy: updates sto
pped
System is amd64-class hardware running i386 distribution with custom
PAE-enabled kernel.
NetBSD plex760.technoskunk.fur 9.99.98 NetBSD 9.99.98 (PLEX760) #29: Tue Jun 21 09:36:01 CDT 2022 sysop@plex760.technoskunk.fur:/r0/build/current/obj/i386/sys/arch/i386/compile/PLEX760 i386
# cpuctl identify 0
cpu0: highest basic info 0000000a
cpu0: highest extended info 80000008
cpu0: "Intel(R) Core(TM)2 Quad CPU Q8200 @ 2.33GHz"
cpu0: Intel Xeon 31xx, 33xx, 52xx, 54xx, Core 2 Quad 8xxx and 9xxx (686-class), 2327.50 MHz
cpu0: family 0x6 model 0x17 stepping 0x7 (id 0x10677)
cpu0: features 0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE>
cpu0: features 0xbfebfbff<MCA,CMOV,PAT,PSE36,CLFSH,DS,ACPI,MMX,FXSR,SSE,SSE2>
cpu0: features 0xbfebfbff<SS,HTT,TM,PBE>
cpu0: features1 0x8e39d<SSE3,DTES64,MONITOR,DS-CPL,EST,TM2,SSSE3,CX16,xTPR>
cpu0: features1 0x8e39d<PDCM,SSE41>
cpu0: features2 0x20100000<XD,EM64T>
cpu0: features3 0x1<LAHF>
cpu0: I-cache: 32KB 64B/line 8-way, D-cache: 32KB 64B/line 8-way
cpu0: L2 cache: 2MB 64B/line 8-way
cpu0: 64B prefetching
cpu0: ITLB: 128 4KB entries 4-way, 8 2M & 4 4M entries
cpu0: DTLB: 256 4KB entries 4-way, 16 4MB entries 4-way
cpu0: Initial APIC ID 0
cpu0: Cluster/Package ID 0
cpu0: Core ID 0
cpu0: SMT ID 0
cpu0: MONITOR/MWAIT extensions 0x3<EMX,IBE>
cpu0: monitor-line size 64
cpu0: C1 substates 2
cpu0: DSPM-eax 0x1<DTS>
cpu0: DSPM-ecx 0x1<HWF,NTDC=0>
cpu0: SEF highest subleaf 00000000
cpu0: Power Management features: 0
cpu0: Perfmon: Ver. 2
cpu0: Perfmon: General: bitwidth 40, 2 counters
cpu0: Perfmon: General: avail 0x7f<CORECYCL,INST,REFCYCL,LLCREF,LLCMISS,BRINST>
cpu0: Perfmon: General: avail 0x7f<BRMISPR>
cpu0: Perfmon: Fixed: bitwidth 40, 3 counters
cpu0: Perfmon: Fixed: avail 0x7<INST,CLK_CORETHREAD,CLK_REF_TSC>
cpu0: microcode version 0x70a, platform ID 4
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Thomas Klausner <wiz@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Tue, 2 Aug 2022 13:15:54 +0200
Can we back out this patch until the kernel panics are fixed?
Thomas
From: "John D. Baker" <jdbaker@consolidated.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Mon, 26 Sep 2022 17:40:29 -0500 (CDT)
Any movement on this PR? Hit this again while building "openjdk17" on
quad-core x86_64 hardware running NetBSD/i386 9.99.99 from shortly before
the bump to ".100". Essentially the same backtrace as reported previously.
I've never hit this running NetBSD/amd64 on the same hardware, only when
running NetBSD/i386. I don't currently have any real i386-class hardware
with sufficient speed/memory easily accessible, but once the weather gets
cooler, I can probably arrange to set one up (and heat my house with it).
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: wiz@NetBSD.org
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Tue, 22 Nov 2022 13:32:21 +0000
This is a multi-part message in MIME format.
--=_su1OON3HGWIM8fZuEZsawKeY4iHDSE1Z
Reproducer on amd64
--=_su1OON3HGWIM8fZuEZsawKeY4iHDSE1Z
Content-Type: text/plain; charset="ISO-8859-1"; name="pr56900"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr56900.c"
#include <sys/syscall.h>
#include <unistd.h>
int
main(void)
{
syscall(SYS_mmap, (void *)0x20000000ul, 0x1000000ul,
/*prot*/3ul, /*flags*/0x1012ul, /*fd*/-1, /*offset*/0ul, 0ul);
syscall(SYS_compat_43_ommap, (void *)0x20ffe000ul, 0x20ffe000ul,
/*prot*/0ul, /*flags*/2ul, /*fd*/-1, /*offset*/0ul);
return 0;
}
--=_su1OON3HGWIM8fZuEZsawKeY4iHDSE1Z--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: wiz@NetBSD.org
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Tue, 22 Nov 2022 13:39:06 +0000
This is a multi-part message in MIME format.
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Simpler reproducer, no compat syscalls involved, constants named for
easier reference
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl
Content-Type: text/plain; charset="ISO-8859-1"; name="pr56900-2"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr56900-2.c"
#include <sys/mman.h>
int
main(void)
{
mmap((void *)0x20000000ul, 0x1000000ul, PROT_READ|PROT_WRITE,
MAP_ANON|MAP_FIXED|MAP_SHARED, -1, 0);
mmap((void *)0x20ffe000ul, 0x20ffe000ul, 0, MAP_ANON, -1, 0);
return 0;
}
--=_QSVhpQW7wL2t2ZyM0lNb6kI+m4HN6cIl--
From: Taylor R Campbell <riastradh@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: wiz@NetBSD.org
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Tue, 22 Nov 2022 14:42:03 +0000
This is a multi-part message in MIME format.
--=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz
Can you please try the attached patch?
--=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz
Content-Type: text/plain; charset="ISO-8859-1"; name="pr56900"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr56900.patch"
From dc4aef9f87a74edd401ebb85419cb0b217591108 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell <riastradh@NetBSD.org>
Date: Tue, 22 Nov 2022 14:40:55 +0000
Subject: [PATCH] mmap(2): Avoid arithmetic overflow in search for free spac=
e.
PR kern/56900
Reported-by: syzbot+3833ae1d38037a263d05@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=3De542bcf59b2564cca1cb38c12f076fb08dca=
c37e
---
sys/uvm/uvm_map.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/sys/uvm/uvm_map.c b/sys/uvm/uvm_map.c
index 46b829b478a6..30b5d73dc6f6 100644
--- a/sys/uvm/uvm_map.c
+++ b/sys/uvm/uvm_map.c
@@ -1994,7 +1994,20 @@ uvm_map_findspace(struct vm_map *map, vaddr_t hint, =
vsize_t length,
/* Try to find the space in the red-black tree */
=20
/* Check slot before any entry */
- hint =3D topdown ? entry->next->start - length : entry->end;
+ if (topdown) {
+ KASSERTMSG(entry->next->start >=3D vm_map_min(map),
+ "map=3D%p entry=3D%p entry->next=3D%p"
+ " entry->next->start=3D0x%"PRIxVADDR" min=3D0x%"PRIxVADDR,
+ map, entry, entry->next,
+ entry->next->start, vm_map_min(map));
+ if (length > entry->next->start - vm_map_min(map))
+ hint =3D vm_map_min(map); /* XXX goto wraparound? */
+ else
+ hint =3D entry->next->start - length;
+ KASSERT(hint >=3D vm_map_min(map));
+ } else {
+ hint =3D entry->end;
+ }
INVARIANTS();
avail =3D uvm_map_space_avail(&hint, length, uoffset, align, flags,
topdown, entry);
--=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz--
From: Thomas Klausner <wiz@NetBSD.org>
To: NetBSD bugtracking <gnats-bugs@NetBSD.org>
Cc: Taylor R Campbell <riastradh@NetBSD.org>
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Thu, 24 Nov 2022 00:42:20 +0100
On Tue, Nov 22, 2022 at 02:45:01PM +0000, Taylor R Campbell wrote:
> Can you please try the attached patch?
I've tried a kernel with the patch - I could finish a full bulk build
(didn't work before) and it even survived building openjdk17 in a loop
for 10 hours.
So I think my problem is fixed.
Thank you!
Thomas
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56900 CVS commit: src/sys/uvm
Date: Wed, 23 Nov 2022 23:53:53 +0000
Module Name: src
Committed By: riastradh
Date: Wed Nov 23 23:53:53 UTC 2022
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
mmap(2): Avoid arithmetic overflow in search for free space.
PR kern/56900
Reported-by: syzbot+3833ae1d38037a263d05@syzkaller.appspotmail.com
https://syzkaller.appspot.com/bug?id=e542bcf59b2564cca1cb38c12f076fb08dcac37e
To generate a diff of this commit:
cvs rdiff -u -r1.402 -r1.403 src/sys/uvm/uvm_map.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/56900: panic in uvm_map_findspace
Date: Thu, 24 Nov 2022 16:07:23 +0100
No more crashes observed here also.
Thanks for that fix.
Frank
On 11/22/22 15:45, Taylor R Campbell wrote:
> The following reply was made to PR kern/56900; it has been noted by GNATS.
>
> From: Taylor R Campbell <riastradh@NetBSD.org>
> To: gnats-bugs@NetBSD.org
> Cc: wiz@NetBSD.org
> Subject: Re: kern/56900: panic in uvm_map_findspace
> Date: Tue, 22 Nov 2022 14:42:03 +0000
>
> This is a multi-part message in MIME format.
> --=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz
>
> Can you please try the attached patch?
>
> --=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz
> Content-Type: text/plain; charset="ISO-8859-1"; name="pr56900"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: attachment; filename="pr56900.patch"
>
> From dc4aef9f87a74edd401ebb85419cb0b217591108 Mon Sep 17 00:00:00 2001
> From: Taylor R Campbell <riastradh@NetBSD.org>
> Date: Tue, 22 Nov 2022 14:40:55 +0000
> Subject: [PATCH] mmap(2): Avoid arithmetic overflow in search for free spac=
> e.
>
> PR kern/56900
>
> Reported-by: syzbot+3833ae1d38037a263d05@syzkaller.appspotmail.com
> https://syzkaller.appspot.com/bug?id=3De542bcf59b2564cca1cb38c12f076fb08dca=
> c37e
> ---
> sys/uvm/uvm_map.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/sys/uvm/uvm_map.c b/sys/uvm/uvm_map.c
> index 46b829b478a6..30b5d73dc6f6 100644
> --- a/sys/uvm/uvm_map.c
> +++ b/sys/uvm/uvm_map.c
> @@ -1994,7 +1994,20 @@ uvm_map_findspace(struct vm_map *map, vaddr_t hint, =
> vsize_t length,
> /* Try to find the space in the red-black tree */
> =20
> /* Check slot before any entry */
> - hint =3D topdown ? entry->next->start - length : entry->end;
> + if (topdown) {
> + KASSERTMSG(entry->next->start >=3D vm_map_min(map),
> + "map=3D%p entry=3D%p entry->next=3D%p"
> + " entry->next->start=3D0x%"PRIxVADDR" min=3D0x%"PRIxVADDR,
> + map, entry, entry->next,
> + entry->next->start, vm_map_min(map));
> + if (length > entry->next->start - vm_map_min(map))
> + hint =3D vm_map_min(map); /* XXX goto wraparound? */
> + else
> + hint =3D entry->next->start - length;
> + KASSERT(hint >=3D vm_map_min(map));
> + } else {
> + hint =3D entry->end;
> + }
> INVARIANTS();
> avail =3D uvm_map_space_avail(&hint, length, uoffset, align, flags,
> topdown, entry);
>
> --=_rFLsIlDMAmZS54PhaM3eE2ii5a8qA3Zz--
>
State-Changed-From-To: open->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 25 Nov 2022 13:25:28 +0000
State-Changed-Why:
fix committed to HEAD, probably need same fix on release branches
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org, riastradh@NetBSD.org
Cc:
Subject: Re: kern/56900 (panic in uvm_map_findspace)
Date: Fri, 25 Nov 2022 22:55:59 +0900
Unfortunately, similar panic still takes place on sh3.
Seems like something wrong in sh3/pmap...
----
# cd /usr/tests && atf-run | atf-report
...
bin/sh/t_here (17/926): 11 test cases
do_simple: [9.487045s] Passed.
end_markers: [ 2036.0781860] panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 1795 map=0x8fe48d68 hint=0x7defb000 orig_hint=0x75172000 length=0x1000 uobj=0x8fd5eaa0 uoffset=0 align=0 flags=0x101 entry=0x8dfc6864 (uvm_map_findspace line 2011)
[ 2036.3769339] cpu0: Begin traceback...
[ 2036.4219435] db_panic() at netbsd:vpanic+0x106
[ 2036.4721571] vpanic() at netbsd:kern_assert+0x24
[ 2036.5313130] kern_assert() at netbsd:uvm_findspace_invariants+0x60
[ 2036.6094391] uvm_findspace_invariants() at netbsd:uvm_map_findspace+0x1fc
[ 2036.6875748] uvm_map_findspace() at netbsd:uvm_map_prepare+0x1ac
[ 2036.7557294] uvm_map_prepare() at netbsd:uvm_map+0xaa
[ 2036.8164256] uvm_map() at netbsd:uvm_mmap+0x166
[ 2036.8750653] uvm_mmap() at netbsd:sys_mmap+0x250
[ 2036.9263064] sys_mmap() at netbsd:syscall+0xba
[ 2036.9844405] syscall() at 8c0001b2
[ 2037.0204721] <EXPEVT 160; SSR=00000100> at 7515ad38
[ 2037.0790696] [trapframe 0x3]
[ 2037.1157066] sr=00000100 gbr=00000000 pc=7515ad38 pr=7515ad0c
[ 2037.1973148] r0=000000c5 r1=00000028 r2=00000000 r3=00000000
[ 2037.2789350] r4=00000000 r6=00001000 r7=00000001 r8=00000001
[ 2037.3605556] r5=7514a400 r9=7ff32f90 r10=7ff32ee8 r11=7514a4bc
[ 2037.4421819] r12=75170ec8 r13=7514a47c r14=00000003 sp=r15=7ff32e28
[ 2037.5237959] cpu0: End traceback...
Stopped in pid 26312.26312 (sh) at netbsd:cpu_Debugger+0x6: mov
r14, r15
db>
----
Thanks,
rin
From: Taylor R Campbell <riastradh@NetBSD.org>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/56900 (panic in uvm_map_findspace)
Date: Fri, 25 Nov 2022 14:07:42 +0000
> Date: Fri, 25 Nov 2022 22:55:59 +0900
> From: Rin Okuyama <rokuyama.rk@gmail.com>
>=20
> Unfortunately, similar panic still takes place on sh3.
> Seems like something wrong in sh3/pmap...
>=20
> ----
> # cd /usr/tests && atf-run | atf-report
> ...
> bin/sh/t_here (17/926): 11 test cases
> do_simple: [9.487045s] Passed.
> end_markers: [ 2036.0781860] panic: kernel diagnostic assertion "!to=
pdown || hint <=3D orig_hint" failed: file "../../../../uvm/uvm_map.c", lin=
e 1795 map=3D0x8fe48d68 hint=3D0x7defb000 orig_hint=3D0x75172000 length=3D0=
x1000 uobj=3D0x8fd5eaa0 uoffset=3D0 align=3D0 flags=3D0x101 entry=3D0x8dfc6=
864 (uvm_map_findspace line 2011)
I think this is a different problem with a similar symptom, tracked in
PR kern/51254. The issue that wiz hit with openjdk appears to have
been arithmetic wraparound with a length larger than the orig_hint
address -- and that's what the reproducer I posted triggers.
What you're seeing on sh3 appears to be different: small length, but
hint nevertheless ends up larger than orig_hint.
Can you get into ddb when this happens? Can you do:
db> show map/f 0x8fe48d68
or whatever the `map=3D0x...' address is in the panic message, and
follow up on PR kern/51254 with the output?
State-Changed-From-To: pending-pullups->needs-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 31 Mar 2023 11:31:27 +0000
State-Changed-Why:
pullups needed, not pending
State-Changed-From-To: needs-pullups->pending-pullups
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Fri, 31 Mar 2023 11:31:52 +0000
State-Changed-Why:
pullup-9 #1625 https://releng.netbsd.org/cgi-bin/req-9.cgi?show=1625
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56900 CVS commit: [netbsd-9] src/sys/uvm
Date: Sat, 1 Apr 2023 16:22:15 +0000
Module Name: src
Committed By: martin
Date: Sat Apr 1 16:22:15 UTC 2023
Modified Files:
src/sys/uvm [netbsd-9]: uvm_map.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1625):
sys/uvm/uvm_map.c: revision 1.403
mmap(2): Avoid arithmetic overflow in search for free space.
PR kern/56900
To generate a diff of this commit:
cvs rdiff -u -r1.362.2.4 -r1.362.2.5 src/sys/uvm/uvm_map.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/56900 CVS commit: [netbsd-8] src/sys/uvm
Date: Fri, 4 Aug 2023 13:15:25 +0000
Module Name: src
Committed By: martin
Date: Fri Aug 4 13:15:25 UTC 2023
Modified Files:
src/sys/uvm [netbsd-8]: uvm_map.c
Log Message:
Pull up following revision(s) (requested by riastradh in ticket #1880):
sys/uvm/uvm_map.c: revision 1.403 (patch)
mmap(2): Avoid arithmetic overflow in search for free space.
PR kern/56900
To generate a diff of this commit:
cvs rdiff -u -r1.351.2.5 -r1.351.2.6 src/sys/uvm/uvm_map.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: pending-pullups->closed
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sat, 05 Aug 2023 16:33:16 +0000
State-Changed-Why:
fixed in HEAD, pulled up to 10, 9, 8
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.47 2022/09/11 19:34:41 kim Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2023
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home