Re: kern/51254 (uvm assertion "!topdown || hint <= orig_hint" failed)

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

The following reply was made to PR kern/51254; it has been noted by GNATS.

From: Rin Okuyama <rokuyama.rk%gmail.com@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, gnats-admin%netbsd.org@localhost
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@localhost>
 >>
 >> 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