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:          feedback
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 18 14:40:01 +0000 2016
>Closed-Date:    
>Last-Modified:  Sun Sep 10 10:55:00 +0000 2023
>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

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(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.