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

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

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