NetBSD Problem Report #51254
From martin@duskware.de Sat Jun 18 14:37:43 2016
Return-Path: <martin@duskware.de>
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 "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id A9F3E7A46A
for <gnats-bugs@gnats.NetBSD.org>; Sat, 18 Jun 2016 14:37:43 +0000 (UTC)
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: uvm assertion failed
X-Send-Pr-Version: 3.95
>Number: 51254
>Notify-List: uwe@netbsd.org
>Category: kern
>Synopsis: uvm assertion "!topdown || hint <= orig_hint" failed
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Jun 18 14:40:01 +0000 2016
>Closed-Date:
>Last-Modified: Sun Apr 21 00:22:56 +0000 2024
>Originator: Martin Husemann
>Release: NetBSD 7.99.30
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD thirdstage.duskware.de 7.99.30 NetBSD 7.99.30 (MODULAR) #523: Wed Jun 15 09:17:16 CEST 2016 martin@thirdstage.duskware.de:/usr/src/sys/arch/sparc64/compile/MODULAR sparc64
Architecture: sparc64
Machine: sparc64
>Description:
During a native build on sparc64 (pie + aslr enabled):
panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 2114
db{0}> sh reg
tstate 1d000605
pc 10535e4 cpu_Debugger+0x4
npc 10535e8 cpu_Debugger+0x8
ipl 0
y 0
g0 0
g1 1
g2 48d1
g3 63061
g4 0
g5 0
g6 2f6173002d
g7 0
o0 18688d8 ostype+0x62958
o1 1ce6a40 scratchstr.12077
o2 18060d8 ostype+0x158
o3 1c6aaf918
o4 1ce6b40 pos.12064
o5 1c66c00 ipf_state_tuneables+0x78
o6 1c6aaef21
o7 1526f6c vpanic+0x16c
l0 182e040 ostype+0x280c0
l3 1c6aaf918
l4 1ce6b40 pos.12064
l5 1ce6a40 scratchstr.12077
l6 1c6aaef21
l7 1526fe8 vpanic+0x1e8
i0 15
i1 1c6aafaf8
i2 ffffffffffffffff
i3 1c6aafaf8
i4 1c6aaf001
i5 156ed7c namei+0x1c
i6 8b800
i7 0
db{0}> mach stack
Window 0 frame64 0x1c6aaf720 locals, ins:
0 104d6e0 0 0 0 0 0 ffffffff909148f0
18060d8 1c6aaf918 1ce5400 1ce6a40 1ce6800 104 1c6aaefd1=sp 1611a94=pc:netbsd:kern_assert+0x34
Window 1 frame64 0x1c6aaf7d0 locals, ins:
0 0 0 0 0 0 0 0
18060d8 1806110 1879af8 18794d8 842 40 1c6aaf091=sp 14ab3c8=pc:netbsd:uvm_map_findspace+0x388
Window 2 frame64 0x1c6aaf890 locals, ins:
0 501 1c6aaf9f8 40 ffffffff90916000 116c52190 0 0
116d744a0 40 2000 1c6aafab8 501 0 1c6aaf171=sp 14abad8=pc:netbsd:uvm_map_prepare+0xf8
Window 3 frame64 0x1c6aaf970 locals, ins:
501 1 0 116c521b0 501 0 1c85c00 0
116c52190 116c521a8 2000 107e44950 0 0 1c6aaf231=sp 14abd54=pc:netbsd:uvm_map+0x94
Window 4 frame64 0x1c6aafa30 locals, ins:
501 1c6aafaf0 101051 ffffffff90915340 ffffffff90915668 0 0 ffffffff909148f0
116c52190 1c6aafcd8 2000 107e44950 0 0 1c6aaf321=sp 14b0e0c=pc:netbsd:uvm_mmap.part.0+0x1ac
Window 5 frame64 0x1c6aafb20 locals, ins:
c 501 0 501 0 107e44950 0 ffffffff909148f0
116c52190 1c6aafcd8 2000 1 501 1 1c6aaf3f1=sp 14b1628=pc:netbsd:sys_mmap+0x2c8
Window 6 frame64 0x1c6aafbf0 locals, ins:
116d6d540 3 116e637c0 16 3 1c6aafccc 116c52190 0
116e94220 1000 1c6aafdd0 2000 0 0 1c6aaf4f1=sp 104dac4=pc:netbsd:syscall+0x3e4
>How-To-Repeat:
run build.sh ?
>Fix:
n/a
>Release-Note:
>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/51254: uvm assertion failed
Date: Sun, 19 Jun 2016 08:07:23 +0200
Here is a version with the extended debug message:
panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 2116 hint: fffffffff7ffc000, orig_hint: ffffffffce116000
if I followed correctly, this is /bin/sh and the vmmap should be this:
db{0}> show map /f 113077890
MAP 0x113077890: [0->0xffffffffffffffff]
#ent=11, sz=124854272, ref=1, version=15, flags=0x41
pmap=0x11307a7c0(resident=25, wired=0)
- 0x112b6b630: 0x86f04000->0x86f34000: obj=0x1049202a0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
- 0x1049a5ce0: 0x87034000->0x87038000: obj=0x1049202a0/0x30000, amap=0x113a4c9b0/0
submap=F, cow=T, nc=F, prot(max)=7/7, inh=1, wc=0, adv=0
- 0x1057c0400: 0x87038000->0x8703a000: obj=0x0/0, amap=0x113609410/0
submap=F, cow=T, nc=F, prot(max)=7/7, inh=1, wc=0, adv=0
- 0x1049b4dc0: 0x8703a000->0x8703c000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=7/7, inh=1, wc=0, adv=0
- 0x1050ed740: 0xffffffffcdff8000->0xffffffffce000000: obj=0x0/0, amap=0x113609780/0
submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
- 0x112b657d0: 0xffffffffce000000->0xffffffffce014000: obj=0x1049213b0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
- 0x1135f40b0: 0xffffffffce014000->0xffffffffce114000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=0/7, inh=1, wc=0, adv=0
- 0x10969c410: 0xffffffffce114000->0xffffffffce116000: obj=0x0/0, amap=0x1136098c0/0
submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
- 0x113620a50: 0xfffffffff7ffe000->0xffffffffff3ba000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=0/7, inh=1, wc=0, adv=0
- 0x112b646f0: 0xffffffffff3ba000->0xffffffffff5a0000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=3/7, inh=1, wc=0, adv=0
- 0x113672bd0: 0xffffffffff5a0000->0xffffffffff5ba000: obj=0x0/0, amap=0x1051f1470/0
submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
Martin
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: Chuck Silvers <chuq@chuq.com>
Subject: Re: kern/51254: uvm assertion failed
Date: Sat, 9 Jul 2016 09:37:04 +0200
I reproduced it with UVMHIST on and got the output below, which is either
puzzling (missing the log from right before the KASSERT) - or points
at a gcc issue. Or did I misread the code?
Martin
panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 2116 hint: fffffffff7ffc000, orig_hint: ffffffff91b16000
db{1}> show kernhist maphist
1468019688.316420 uvm_anon_dispose#17626051@0: (anon=0xbd27bc0)
1468019688.316422 uvm_anon_dispose#17626051@0: anon 0xbd27bc0, page 0x1842e50: freed now!
1468019688.316422 uvm_anon_dropswap#17626200@0: called!
1468019688.316422 uvm_anon_dispose#17626051@0: <- done!
1468019688.316422 uvm_anon_dispose#17626052@0: called!
1468019688.316423 uvm_anon_dispose#17626052@0: (anon=0xbef96a0)
1468019688.316424 uvm_anon_dispose#17626052@0: anon 0xbef96a0, page 0x1b0f1d8: freed now!
1468019688.316424 uvm_anon_dropswap#17626201@0: called!
1468019688.316424 uvm_anon_dispose#17626052@0: <- done!
1468019688.316425 amap_free#1231406@0: called!
1468019688.316428 amap_free#1231406@0: <- done, freed amap = 0xbcab770
1468019688.316428 amap_wipeout#1231390@0: <- done!
1468019688.316429 amap_unref#1262721@0: <- done (was last ref)!
1468019688.316429 uvm_mapent_free#3549407@0: called!
1468019688.316429 uvm_mapent_free#3549407@0: <- freeing map entry=0x10bb2f0f0 [flags=0]
1468019688.316430 uvm_unmap_detach#1036330@0: detach 0x10bd15330: amap=0x10b95f9a0, obj=0x104922540, submap?=0
1468019688.316430 amap_unref#1262722@0: called!
1468019688.316430 amap_unref#1262722@0: amap=0xb95f9a0 refs=1, nused=1
1468019688.316431 amap_wipeout#1231391@0: called!
1468019688.316431 amap_wipeout#1231391@0: (amap=0xb95f9a0)
1468019688.316432 amap_wipeout#1231391@0: processing anon 0xbf242e0, ref=1
1468019688.316432 uvm_anon_dispose#17626053@0: called!
1468019688.316432 uvm_anon_dispose#17626053@0: (anon=0xbf242e0)
1468019688.316434 uvm_anon_dispose#17626053@0: anon 0xbf242e0, page 0x169c060: freed now!
1468019688.316435 uvm_anon_dropswap#17626202@0: called!
1468019688.316435 uvm_anon_dispose#17626053@0: <- done!
1468019688.316435 amap_free#1231407@0: called!
1468019688.316437 amap_free#1231407@0: <- done, freed amap = 0xb95f9a0
1468019688.316437 amap_wipeout#1231391@0: <- done!
1468019688.316437 amap_unref#1262722@0: <- done (was last ref)!
1468019688.316438 uvm_mapent_free#3549408@0: called!
1468019688.316438 uvm_mapent_free#3549408@0: <- freeing map entry=0x10bd15330 [flags=0]
1468019688.316438 uvm_unmap_detach#1036330@0: detach 0x10bd154e0: amap=0x0, obj=0x104922540, submap?=0
1468019688.316438 uvm_mapent_free#3549409@0: called!
1468019688.316439 uvm_mapent_free#3549409@0: <- freeing map entry=0x10bd154e0 [flags=0]
1468019688.316439 uvm_unmap_detach#1036330@0: <- done
1468019688.320246 uvm_pagermapout#113903@0: called!
1468019688.320247 uvm_pagermapout#113903@0: (kva=0xaf2b0000, npages=8)
1468019688.320311 uvm_unmap_remove#1036331@0: called!
1468019688.320311 uvm_unmap_remove#1036331@0: (map=0x103b05e08, start=0x1af2b0000, end=0x1af2c0000)
1468019688.320312 uvm_map_lookup_entry#31606530@0: called!
1468019688.320313 uvm_map_lookup_entry#31606530@0: (map=0x103b05e08,addr=0x1af2b0000,ent=0x1b1a91ab8)
1468019688.320314 uvm_map_lookup_entry#31606530@0: <- search got it (0x1065d74e0)
1468019688.320315 uvm_km_pgremove_intrsafe#389133@0: called!
1468019688.320321 uvm_unmap_remove#1036331@0: removed map entry 0x10595c390
1468019688.320326 uvm_unmap_remove#1036331@0: <- done!
1468019688.320327 uvm_unmap_detach#1036331@0: called!
1468019688.320327 uvm_unmap_detach#1036331@0: detach 0x10595c390: amap=0x0, obj=0x0, submap?=0
1468019688.320328 uvm_mapent_free#3549410@0: called!
1468019688.320328 uvm_mapent_free#3549410@0: <- freeing map entry=0x10595c390 [flags=8]
1468019688.320329 uvm_unmap_detach#1036331@0: <- done
1468019688.320329 uvm_pagermapout#113903@0: <- done
1468019688.325047 uvm_pagermapout#113904@0: called!
1468019688.325047 uvm_pagermapout#113904@0: (kva=0xaf1f0000, npages=8)
1468019688.325111 uvm_unmap_remove#1036332@0: called!
1468019688.325112 uvm_unmap_remove#1036332@0: (map=0x103b05e08, start=0x1af1f0000, end=0x1af200000)
1468019688.325112 uvm_map_lookup_entry#31606531@0: called!
1468019688.325113 uvm_map_lookup_entry#31606531@0: (map=0x103b05e08,addr=0x1af1f0000,ent=0x1b1a91ab8)
1468019688.325114 uvm_map_lookup_entry#31606531@0: <- search got it (0x1065eb850)
1468019688.325114 uvm_km_pgremove_intrsafe#389134@0: called!
1468019688.325120 uvm_unmap_remove#1036332@0: removed map entry 0x106500820
1468019688.325123 uvm_unmap_remove#1036332@0: <- done!
1468019688.325123 uvm_unmap_detach#1036332@0: called!
1468019688.325124 uvm_unmap_detach#1036332@0: detach 0x106500820: amap=0x0, obj=0x0, submap?=0
1468019688.325124 uvm_mapent_free#3549411@0: called!
1468019688.325125 uvm_mapent_free#3549411@0: <- freeing map entry=0x106500820 [flags=8]
1468019688.325126 uvm_unmap_detach#1036332@0: <- done
1468019688.325127 uvm_pagermapout#113904@0: <- done
1468019688.330127 uvm_pagermapout#113905@0: called!
1468019688.330127 uvm_pagermapout#113905@0: (kva=0xaf220000, npages=8)
1468019688.330193 uvm_unmap_remove#1036333@0: called!
1468019688.330193 uvm_unmap_remove#1036333@0: (map=0x103b05e08, start=0x1af220000, end=0x1af230000)
1468019688.330194 uvm_map_lookup_entry#31606532@0: called!
1468019688.330194 uvm_map_lookup_entry#31606532@0: (map=0x103b05e08,addr=0x1af220000,ent=0x1b1a91ab8)
1468019688.330195 uvm_map_lookup_entry#31606532@0: <- search got it (0x1058fa550)
1468019688.330195 uvm_km_pgremove_intrsafe#389135@0: called!
1468019688.330202 uvm_unmap_remove#1036333@0: removed map entry 0x10591ea30
1468019688.330204 uvm_unmap_remove#1036333@0: <- done!
1468019688.330204 uvm_unmap_detach#1036333@0: called!
1468019688.330205 uvm_unmap_detach#1036333@0: detach 0x10591ea30: amap=0x0, obj=0x0, submap?=0
1468019688.330205 uvm_mapent_free#3549412@0: called!
1468019688.330205 uvm_mapent_free#3549412@0: <- freeing map entry=0x10591ea30 [flags=8]
1468019688.330206 uvm_unmap_detach#1036333@0: <- done
1468019688.330206 uvm_pagermapout#113905@0: <- done
1468019688.336577 uvm_pagermapout#113906@0: called!
1468019688.336578 uvm_pagermapout#113906@0: (kva=0xaf20a000, npages=8)
1468019688.336643 uvm_unmap_remove#1036334@0: called!
1468019688.336644 uvm_unmap_remove#1036334@0: (map=0x103b05e08, start=0x1af20a000, end=0x1af21a000)
1468019688.336644 uvm_map_lookup_entry#31606533@0: called!
1468019688.336645 uvm_map_lookup_entry#31606533@0: (map=0x103b05e08,addr=0x1af20a000,ent=0x1b1a91ab8)
1468019688.336645 uvm_map_lookup_entry#31606533@0: <- got it via hint (0x106501e10)
1468019688.336646 uvm_km_pgremove_intrsafe#389136@0: called!
1468019688.336652 uvm_unmap_remove#1036334@0: removed map entry 0x106501e10
1468019688.336655 uvm_unmap_remove#1036334@0: <- done!
1468019688.336655 uvm_unmap_detach#1036334@0: called!
1468019688.336656 uvm_unmap_detach#1036334@0: detach 0x106501e10: amap=0x0, obj=0x0, submap?=0
1468019688.336656 uvm_mapent_free#3549413@0: called!
1468019688.336656 uvm_mapent_free#3549413@0: <- freeing map entry=0x106501e10 [flags=8]
1468019688.336657 uvm_unmap_detach#1036334@0: <- done
1468019688.336657 uvm_pagermapout#113906@0: <- done
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/51254: uvm assertion failed
Date: Tue, 22 Nov 2016 13:52:51 +0100
I enhanced the KASSERTMSG and got this:
kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 2118 hint: fffffffff7ffc000, orig_hint: ffffffff91d16000, map: 0x105098d00, uobj: 0x1049182a0, uoffset: 0, align: 0, flags: 501
db{1}> show map 0x105098d00
MAP 0x105098d00: [0x2000->0xffffffffffffffff]
#ent=11, sz=128155648, ref=1, version=15, flags=0x41
pmap=0x10509e140(resident=25, wired=0)
db{1}> show map /f 0x105098d00
MAP 0x105098d00: [0x2000->0xffffffffffffffff]
#ent=11, sz=128155648, ref=1, version=15, flags=0x41
pmap=0x10509e140(resident=25, wired=0)
- 0x105c46b80: 0x82f06000->0x82f36000: obj=0x10895c6d0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
- 0x107506540: 0x83036000->0x8303a000: obj=0x10895c6d0/0x30000, amap=0x10650e56
0/0
submap=F, cow=T, nc=F, prot(max)=7/7, inh=1, wc=0, adv=0
- 0x1102df2a0: 0x8303a000->0x8303c000: obj=0x0/0, amap=0x1070f9420/0
submap=F, cow=T, nc=F, prot(max)=7/7, inh=1, wc=0, adv=0
- 0x105898630: 0x8303c000->0x8303e000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=7/7, inh=1, wc=0, adv=0
- 0x107506f60: 0xffffffff91bf8000->0xffffffff91c00000: obj=0x0/0, amap=0x1105f1
e70/0
submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
- 0x105c6a750: 0xffffffff91c00000->0xffffffff91c14000: obj=0x10898eff0/0, amap=
0x0/0
submap=F, cow=T, nc=T, prot(max)=5/7, inh=1, wc=0, adv=0
- 0x107168130: 0xffffffff91c14000->0xffffffff91d14000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=0/7, inh=1, wc=0, adv=0
- 0x10fe43ba0: 0xffffffff91d14000->0xffffffff91d16000: obj=0x0/0, amap=0x105296
3e0/0
submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
- 0x107507aa0: 0xfffffffff7ffe000->0xffffffffff6e0000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=0/7, inh=1, wc=0, adv=0
- 0x1059c64b0: 0xffffffffff6e0000->0xffffffffff8c0000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=3/7, inh=1, wc=0, adv=0
- 0x1102dfb10: 0xffffffffff8c0000->0xffffffffff8e0000: obj=0x0/0, amap=0x10650e
380/0
submap=F, cow=T, nc=F, prot(max)=3/7, inh=1, wc=0, adv=0
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/51254: uvm assertion failed
Date: Sat, 14 Oct 2017 02:28:44 +0300
I get this on my landisk regularly since sh3 has been switched to
top-down vm and aslr.
panic: kernel diagnostic assertion "!topdown || hint <= orig_hint" failed: file "../../../../uvm/uvm_map.c", line 2171 hint: 7defc000, orig_hint: 6fba2000
Stopped in pid 16112.1 (atrun) at netbsd:cpu_Debugger+0x2: rts
-uwe
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/51254: uvm assertion failed
Date: Tue, 1 Oct 2019 15:57:26 +0300
Just for completeness and cross-reference purposes - this bug is most
likely _not_ a duplicate of kern/54395 as hint and orig_hint here are
wildly diffrent and in the extra info collected by martin align = 0.
-uwe
State-Changed-From-To: open->feedback
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Sat, 04 Jun 2022 23:25:10 +0000
State-Changed-Why:
Next time this happens, can you please do `show map /f ...' in ddb?
I added some diagnostics to get more info out of this.
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51254 CVS commit: src/sys/uvm
Date: Sat, 4 Jun 2022 23:26:06 +0000
Module Name: src
Committed By: riastradh
Date: Sat Jun 4 23:26:06 UTC 2022
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
uvm(9): Sprinkle more info into hint/orig_hint assertions.
May help to diagnose PR kern/51254.
To generate a diff of this commit:
cvs rdiff -u -r1.397 -r1.398 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: 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,
martin@NetBSD.org
Cc: uwe@netbsd.org
Subject: Re: kern/51254 (uvm assertion "!topdown || hint <= orig_hint" failed)
Date: Sun, 5 Jun 2022 10:30:02 +0900
Thank you very much for working on this problem.
That KASSERT fired for sh3 during ATF run:
https://gist.github.com/rokuyama/659aa325757645338308351cc54e5c75
Thanks,
rin
From: "Taylor R Campbell" <riastradh@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51254 CVS commit: src/sys/uvm
Date: Sun, 5 Jun 2022 13:45:28 +0000
Module Name: src
Committed By: riastradh
Date: Sun Jun 5 13:45:28 UTC 2022
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
uvm(9): Sprinkle assertions into uvm_map_findspace.
May help to diagnose PR kern/51254.
To generate a diff of this commit:
cvs rdiff -u -r1.399 -r1.400 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: Rin Okuyama <rokuyama.rk@gmail.com>
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
Cc: uwe@netbsd.org
Subject: Re: PR/51254 CVS commit: src/sys/uvm
Date: Mon, 6 Jun 2022 00:05:18 +0900
I could reproduce panic with the latest uvm_map.c (rev 1.400):
https://gist.github.com/rokuyama/dc137b66bdc30440c49d8dedb95b95ea
Here, I added "entry" argument for uvm_findspace_invariants():
https://gist.github.com/rokuyama/fbd90c433e4fbc0f505f3b85d47b6f74
Thanks,
rin
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>,
Taylor R Campbell <riastradh@NetBSD.org>
Cc:
Subject: Re: PR/51254 CVS commit: src/sys/uvm
Date: Mon, 6 Jun 2022 07:21:12 +0900
Resending... Why gnats hates my message?
-------- Forwarded Message --------
Subject: Re: PR/51254 CVS commit: src/sys/uvm
Date: Mon, 6 Jun 2022 00:40:10 +0900
From: Rin Okuyama <rokuyama.rk@gmail.com>
Reply-To: gnats-bugs@netbsd.org
To: kern-bug-people@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, martin@NetBSD.org
CC: uwe@netbsd.org
Ah, it seems like PMAP_PREFER() changes "hint" unexpectedly.
Both sh3 and sparc64 (the original target of this PR) have
PMAP_PREFER().
We had a similar bug before: kern/54395. In this case, non-zero
"align" caused the KASSERT failure. We fixed the problem by aligning
"hint" at the beginning of uvm_map():
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/uvm/uvm_map.c#rev1.365
Thanks,
rin
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51254 CVS commit: src/sys/uvm
Date: Mon, 6 Jun 2022 07:00:03 +0000
Module Name: src
Committed By: rin
Date: Mon Jun 6 07:00:02 UTC 2022
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
PR kern/51254
uvm_map_findspace(): Output current value of "entry" when KASSERT fires.
To generate a diff of this commit:
cvs rdiff -u -r1.400 -r1.401 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: Rin Okuyama <rokuyama.rk@gmail.com>
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc: Taylor R Campbell <riastradh@NetBSD.org>,
Martin Husemann <martin@NetBSD.org>, uwe@NetBSD.org
Subject: Re: kern/51254 (uvm assertion "!topdown || hint <= orig_hint" failed)
Date: Mon, 6 Jun 2022 16:27:08 +0900
Now, I'm testing this patch:
https://gist.github.com/rokuyama/62f4b8b3eb486109629358df9ca31e62
Fix for kern/54395 was insufficient. It addressed a case where hint
is modified in uvm_map_space_avail() due to (1) alignment constraint.
However, hint can also be modified in that function due to
(2) PMAP_PREFER and (3) color constraint, and these cases also
result in KASSERT failures similar to one reported in kern/54395.
This PR, kern/51254 is case (2) itself.
In this patch, in addition to (1), (2) and (3) are taking into
account; hint is adjusted at the beginning of uvm_map_findspace()
according to these requirements. Also, I've added check for
(flags & UVM_FLAG_FIXED) == 0 before hint is modified.
With this patch, aarch64eb machine (ncolors=4) successfully
completes full ATF run without regressions.
Now, I'm carrying out stress tests on two sh3 machines with
DIAGNOSTIC kernel; one for building pkgsrc's and one for full
ATF run. Their uptime exceeds 4 hours without problems.
Thanks,
rin
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: "gnats-bugs@NetBSD.org" <gnats-bugs@NetBSD.org>
Cc:
Subject: Re: kern/51254 (uvm assertion "!topdown || hint <= orig_hint" failed)
Date: Tue, 7 Jun 2022 21:07:35 +0900
Resend to gnats...
On 2022/06/06 16:30, Rin Okuyama wrote:
> Now, I'm carrying out stress tests on two sh3 machines with
> DIAGNOSTIC kernel; one for building pkgsrc's and one for full
> ATF run. Their uptime exceeds 4 hours without problems.
Now, uptime exceeds 30 hours. Packages including perl5 and
python39 were built, and ATF run was completed without any
regression.
These were impossible for DIAGNOSTIC kernel before. So,
the problem should be fixed.
I will commit the patch if there's no objection.
Thanks,
rin
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
netbsd-bugs@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/51254 (uvm assertion "!topdown || hint <= orig_hint" failed)
Date: Fri, 25 Nov 2022 23:24:00 +0900
Switched from kern/56900.
Panic still takes place even with uvm_map.c rev 1.403.
On 2022/11/25 23:07, Taylor R Campbell wrote:
>> Date: Fri, 25 Nov 2022 22:55:59 +0900
>> From: Rin Okuyama <rokuyama.rk@gmail.com>
>>
>> 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)
>
> 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.
Thanks for your comment. Agreed. Your reproducer does not trigger panic on
sh3 with uvm_map.c rev 1.403.
> Can you get into ddb when this happens? Can you do:
>
> db> show map/f 0x8fe48d68
>
> or whatever the `map=0x...' address is in the panic message, and
> follow up on PR kern/51254 with the output?
Yes, and this DDB session is still living:
----
db> show map/f 0x8fe48d68
MAP 0x8fe48d68: [0x1000->0x7ffff000]
#ent=12, sz=34136064, ref=1, version=31, flags=0x41
pmap=0x8fe47e00(resident=26, wired=0)
- 0x8f54b530: 0x400000->0x42a000: obj=0x8fd5e718/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=5/5, inh=1, wc=0, adv=0
- 0x8e432b2c: 0x439000->0x43a000: obj=0x8fd5e718/0x29000, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=3/3, inh=1, wc=0, adv=0
- 0x8f54bad0: 0x43a000->0x43b000: obj=0x0/0, amap=0x8e01bb54/0
submap=F, cow=T, nc=F, prot(max)=3/3, inh=1, wc=0, adv=0
- 0x8c8ebb6c: 0x43b000->0x43d000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=3/3, inh=1, wc=0, adv=0
- 0x8c8ebbbc: 0x75148000->0x75150000: obj=0x0/0, amap=0x8e01e978/0
submap=F, cow=T, nc=F, prot(max)=3/3, inh=1, wc=0, adv=0
- 0x8c8eb3ec: 0x75150000->0x75161000: obj=0x8fdb6004/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=5/5, inh=1, wc=0, adv=0
- 0x8cdb7b74: 0x75161000->0x75170000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=0/0, inh=1, wc=0, adv=0
- 0x8dfc6864: 0x75170000->0x75172000: obj=0x0/0, amap=0x8e01e32c/0
submap=F, cow=T, nc=F, prot(max)=3/3, inh=1, wc=0, adv=0
- 0x8fb5b7a8: 0x7defc000->0x7defd000: obj=0x8fe517c0/0, amap=0x0/0
submap=F, cow=F, nc=F, prot(max)=5/5, inh=0, wc=0, adv=1
- 0x8dfc60e4: 0x7deff000->0x7fd34000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=0/0, inh=1, wc=0, adv=0
- 0x8dec4f48: 0x7fd34000->0x7ff30000: obj=0x0/0, amap=0x0/0
submap=F, cow=T, nc=T, prot(max)=3/3, inh=1, wc=0, adv=0
- 0x8de908f8: 0x7ff30000->0x7ff34000: obj=0x0/0, amap=0x8ce10dc0/0
submap=F, cow=T, nc=F, prot(max)=3/3, inh=1, wc=0, adv=0
db>
----
I just forgot it, but my comment to this PR dated 2022-06-06 suggests
that this is due to MI bug. Patch provided in the message has never
been committed (and also not applied for this kernel in problem).
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/51254 (uvm assertion "!topdown || hint <= orig_hint" failed)
Date: Fri, 25 Nov 2022 14:52:58 +0000
This is a multi-part message in MIME format.
--=_3LM3Qr5snjR6jwWdKR2eeC80vJ4rOpBA
Content-Transfer-Encoding: quoted-printable
> Date: Fri, 25 Nov 2022 23:24:00 +0900
> From: Rin Okuyama <rokuyama.rk@gmail.com>
>=20
> >> end_markers: [ 2036.0781860] panic: kernel diagnostic assertion =
"!topdown || hint <=3D orig_hint" failed: file "../../../../uvm/uvm_map.c",=
line 1795 map=3D0x8fe48d68 hint=3D0x7defb000 orig_hint=3D0x75172000 length=
=3D0x1000 uobj=3D0x8fd5eaa0 uoffset=3D0 align=3D0 flags=3D0x101 entry=3D0x8=
dfc6864 (uvm_map_findspace line 2011)
> [...]
> - 0x8dfc6864: 0x75170000->0x75172000: obj=3D0x0/0, amap=3D0x8e01e32c/0
> submap=3DF, cow=3DT, nc=3DF, prot(max)=3D3/3, inh=3D1, wc=3D0, a=
dv=3D0
> - 0x8fb5b7a8: 0x7defc000->0x7defd000: obj=3D0x8fe517c0/0, amap=3D0x0/0
> submap=3DF, cow=3DF, nc=3DF, prot(max)=3D5/5, inh=3D0, wc=3D0, a=
dv=3D1
What's happening is that, at uvm_map.c rev. 1.403 line 2006, we have
entry=3D0x8dfc6864 covering [0x75170000, 0x75172000), followed by
0x8fb5b7a8 covering [0x7defc000, 0x7defd000). But orig_hint is
0x75172000. So we have (addresses growing down):
0x75170000 entry@0x8dfc6864->start
...
0x75172000 entry@0x8dfc6864->end; orig_hint
...
0x7defb000 entry->next->start - length; new hint
...
0x7defc000 entry->next->start
...
0x7defd000 entry->next->end
How we got here must be:
1. condition on lines 1911 false (orig hint is not vm map min/max)
2. condition on line 1942 false (orig hint is not in a mapped entry),
but this sets entry=3D0x8dfc6864 to be the highest-address entry
before the orig hint (0x75172000)
3. condition on line 1951 false (not asking for fixed mapping)
=3D> if we had taken this branch, then the conditions on lines
1954-1955 would have covered this and gone to found, so we must
not have taken this branch
4. uvm_map_space_avail on lines 1964-1965 must have failed to find
space in this gap, even though there appears to be space here for a
single page
Then we get to the (newly modified) logic on lines 1997-2010, which
sets hint =3D entry->next->start - length =3D 0x7defb000 which lives above
orig_hint and trips over the assertion.
Now here I'm a bit puzzled. We started with orig_hint=3D0x75172000.
Why didn't uvm_map_space_avail find any space in the gap [0x75172000,
0x7defc000) between entry and entry->next? Is this something about
PMAP_PREFER on sh3, or what?
If it is legitimate for uvm_map_space_avail to have failed in that
scenario, then we need some mechanism to ensure that we don't move to
higher addresses in the gap after it fails (because that certainly
won't help in the search, since it makes the gap smaller than the one
that already failed, and will violate the monotonicity that this
search is supposed to follow).
Can you try the attached patch?
--=_3LM3Qr5snjR6jwWdKR2eeC80vJ4rOpBA
Content-Type: text/plain; charset="ISO-8859-1"; name="pr51254"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="pr51254.patch"
From 9b46875ee5560b45989709b0e1f378b2c6e9c6a3 Mon Sep 17 00:00:00 2001
From: Taylor R Campbell <riastradh@NetBSD.org>
Date: Fri, 25 Nov 2022 14:50:42 +0000
Subject: [PATCH] uvm: Ensure topdown search through gap only tries lower
addresses.
Otherwise (a) we might waste time checking for space in smaller gap
after a larger one already failed, and (b) we violate the monotonic
search.
PR kern/51254
---
sys/uvm/uvm_map.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sys/uvm/uvm_map.c b/sys/uvm/uvm_map.c
index 2d6ff6c83eb7..4fb68ac80541 100644
--- a/sys/uvm/uvm_map.c
+++ b/sys/uvm/uvm_map.c
@@ -2003,7 +2003,7 @@ uvm_map_findspace(struct vm_map *map, vaddr_t hint, v=
size_t length,
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;
+ hint =3D MIN(orig_hint, entry->next->start - length);
KASSERT(hint >=3D vm_map_min(map));
} else {
hint =3D entry->end;
--=_3LM3Qr5snjR6jwWdKR2eeC80vJ4rOpBA--
From: "Rin Okuyama" <rin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/51254 CVS commit: src/sys/uvm
Date: Thu, 3 Aug 2023 03:15:48 +0000
Module Name: src
Committed By: rin
Date: Thu Aug 3 03:15:48 UTC 2023
Modified Files:
src/sys/uvm: uvm_map.c
Log Message:
uvm_findspace(): For sh3, convert a KASSERTMSG(9) into printf(9)
XXX
Work around for PR kern/51254 until it gets fixed.
With this change, landisk survives full ATF with DIAGNOSTIC enabled.
To generate a diff of this commit:
cvs rdiff -u -r1.406 -r1.407 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: Taylor R Campbell <riastradh@NetBSD.org>
To: Rin Okuyama <rokuyama.rk@gmail.com>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/51254: uvm assertion "!topdown || hint <= orig_hint" failed
Date: Thu, 7 Sep 2023 13:02:19 +0000
Were you able to test the patch I suggested last year, or did you find
some flaw in the analysis I posted it with?
- hint = entry->next->start - length;
+ hint = MIN(orig_hint, entry->next->start - length);
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: Re: kern/51254: uvm assertion failed
Date: Thu, 7 Sep 2023 18:07:05 +0200
I tested with Taylor's patch on landisk:
[ 2531.7121850] map=3D0x8d041708 hint=3D0x7defe000 orig_hint=3D0x7defd000 l=
ength=3D0x1000 uobj=3D0x8fd98e28 uoffset=3D0 align=3D0 flags=3D0x101 entry=
=3D0x8c78fe80 (uvm_map_findspace line 2187)map=3D0x8d041708 hint=3D0x7defe0=
00 orig_hint=3D0x7defd000 length=3D0x1000 uobj=3D0x8fd981e8 uoffset=3D0 ali=
gn=3D0 flags=3D0x101 entry=3D0x8c78fe80 (uvm_map_findspace line 2187)map=3D=
0x8d041708 hint=3D0x7defe000 orig_hint=3D0x7defd000 length=3D0x1000 uobj=3D=
0x8fdf4e24 uoffset=3D0 align=3D0 flags=3D0x101 entry=3D0x8c78fe80 (uvm_map_=
findspace line 2187)map=3D0x8d041708 hint=3D0x7defb000 orig_hint=3D0x738b60=
00 length=3D0x1000 uobj=3D0x8fd98e28 uoffset=3D0 align=3D0 flags=3D0x101 en=
try=3D0x8d088dcc (uvm_map_findspace line 2187)map=3D0x8d041708 hint=3D0x7de=
f8000 orig_hint=3D0x738b6000 length=3D0x1000 uobj=3D0x8fd98e28 uoffset=3D0 =
align=3D0 flags=3D0x101 entry=3D0x8d088dcc (uvm_map_findspace line 2192)map=
=3D0x8d041708 hint=3D0x7def8000 orig_hint=3D0x738b6000 length=3D0x1000 uobj=
=3D0x8fd98e28 uoffset=3D0 align=3D0 flags=3D0x101 entry=3D0x8d088dcc (uvm_m=
ap_findspace line 2222)map=3D0x8d041708 hint=3D0x7def7000 orig_hint=3D0x738=
b6000 length=3D0x1000 uobj=3D0x8fd981e8 uoffset=3D0 align=3D0 flags=3D0x101=
entry=3D0x8d088dcc (uvm_map_findspace line 2187)map=3D0x8d041708 hint=3D0x=
7def4000 orig_hint=3D0x738b6000 length=3D0x1000 uobj=3D0x8fd981e8 uoffset=
=3D0 align=3D0 flags=3D0x101 entry=3D0x8d088dcc (uvm_map_findspace line 219=
2)map=3D0x8d041708 hint=3D0x7def4000 orig_hint=3D0x738b6000 length=3D0x1000=
uobj=3D0x8fd981e8 uoffset=3D0 align=3D0 flags=3D0x101 entry=3D0x8d088dcc (=
uvm_map_findspace line 2222)map=3D0x8d041708 hint=3D0x7def3000 orig_hint=3D=
0x738b6000 length=3D0x1000 uobj=3D0x8fdf4e24 uoffset=3D0 align=3D0 flags=3D=
0x101 entry=3D0x8d088dcc (uvm_map_findspace line 2187)map=3D0x8d041708 hint=
=3D0x7def0000 orig_hint=3D0x738b6000 length=3D0x1000 uobj=3D0x8fdf4e24 ....
Martin
From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Taylor R Campbell <riastradh@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
Martin Husemann <martin@duskware.de>
Subject: Re: kern/51254: uvm assertion "!topdown || hint <= orig_hint" failed
Date: Sun, 10 Sep 2023 19:50:48 +0900
On 2023/09/07 22:02, Taylor R Campbell wrote:
> Were you able to test the patch I suggested last year, or did you find
> some flaw in the analysis I posted it with?
>
> - hint = entry->next->start - length;
> + hint = MIN(orig_hint, entry->next->start - length);
Oops, sorry, I didn't notice your message somehow.
Even with this patch, that KASSERT fires unfortunately.
Full log with UVMHIST is provided here:
https://gist.github.com/rokuyama/b812a0f27c0354f6fc5f67c0c0be2929
Thanks,
rin
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 21 Apr 2024 00:22:56 +0000
State-Changed-Why:
feedback received
>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-2024
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home