Re: powerpc64/pmap.c trouble report

The -stable version "crash1" was reproducible almost every run; each
run is about an hour on this 8-processor Power9 running a load average
about 30. The -current version "crash2" has only happened once so far,
though because of other issues (hitting a user process limit of 126)
it was failing early until I recognized the issue today.

It is certainly not a clean, condensed, reproducible bug and I
ordinarily would not report. But given folks were just in the code, I
thought better to say something just in case. I'm fine with leaving
the kernel unchanged until I can get a more reproducible case. If
there is anything you'd like me to print from ddb upon a crash, if
this becomes one of those annoying every-few-weeks issues, please let
me know. I'm happy to leave the machine sitting at ddb> for a few
hours or days in that case.

On Mon, May 20, 2024 at 6:08=E2=80=AFPM Jeremie Courreges-Anglas <jca@wxcvb=
n.org> wrote:
>
> On Tue, May 21, 2024 at 02:51:39AM +0200, Jeremie Courreges-Anglas wrote:
> > On Sat, May 18, 2024 at 01:11:56PM -0700, Eric Grosse wrote:
> > > The openbsd-ppc64-n2vi Go builder machine is converting over to LUCI
> > > build infrastructure and the new workload may have stepped on a
> > > pagedaemon corner case. While running 7.5-stable I reproducibly get
> > > kernel panics "pmap_enter: failed to allocate pted". I saw recent
> > > powerpc64/pmap.c changes from gkoehler@ and kettenis@, so updated the
> > > machine to 7.5-snapshot and now see "trap type 300" from pmap_remove.
> >
> > Is that also reproducible?  cc'ing bugs@.
> >
> > > In an effort to reproduce this with a more familiar workload, I tried
> > > "/usr/src$ make -j32 build" to pound on the hardware with a similar
> > > load average and temperature, but that runs without crashing. I'd
> > > welcome suggestions on anything I can do to reduce this to a useful
> > > bug report.
> > >
> > > https://n2vi.com/t.dmesg   latest dmesg
> > > https://n2vi.com/t.crash1   ddb serial console from the 7.5-stable pa=
nics
> >
> > This doesn't look powerpc64-specific.  It feels like
> > uvm_km_kmemalloc_pla() should call pmap_enter() with PMAP_CANFAIL and
> > unwind in case of a resource shortage.
>
> The diff below behaves when I inject fake pmap_enter() failures on
> amd64.  It would be nice to test it on -stable and/or -current,
> depending on whether it happens on -stable only or also on -current.
>
>
> diff --git a/sys/uvm/uvm_km.c b/sys/uvm/uvm_km.c
> index a715173529a..3779ea3d7ee 100644
> --- a/sys/uvm/uvm_km.c
> +++ b/sys/uvm/uvm_km.c
> @@ -335,7 +335,7 @@ uvm_km_kmemalloc_pla(struct vm_map *map, struct uvm_o=
bject *obj, vsize_t size,
>         vaddr_t kva, loopva;
>         voff_t offset;
>         struct vm_page *pg;
> -       struct pglist pgl;
> +       struct pglist pgl, pgldone;
>         int pla_flags;
>
>         KASSERT(vm_map_pmap(map) =3D=3D pmap_kernel());
> @@ -372,6 +372,7 @@ uvm_km_kmemalloc_pla(struct vm_map *map, struct uvm_o=
bject *obj, vsize_t size,
>          * whom should ever get a handle on this area of VM.
>          */
>         TAILQ_INIT(&pgl);
> +       TAILQ_INIT(&pgldone);
>         pla_flags =3D 0;
>         KASSERT(uvmexp.swpgonly <=3D uvmexp.swpages);
>         if ((flags & UVM_KMF_NOWAIT) ||
> @@ -396,6 +397,7 @@ uvm_km_kmemalloc_pla(struct vm_map *map, struct uvm_o=
bject *obj, vsize_t size,
>         while (loopva !=3D kva + size) {
>                 pg =3D TAILQ_FIRST(&pgl);
>                 TAILQ_REMOVE(&pgl, pg, pageq);
> +               TAILQ_INSERT_TAIL(&pgldone, pg, pageq);
>                 uvm_pagealloc_pg(pg, obj, offset, NULL);
>                 atomic_clearbits_int(&pg->pg_flags, PG_BUSY);
>                 UVM_PAGE_OWN(pg, NULL);
> @@ -408,9 +410,28 @@ uvm_km_kmemalloc_pla(struct vm_map *map, struct uvm_=
object *obj, vsize_t size,
>                         pmap_kenter_pa(loopva, VM_PAGE_TO_PHYS(pg),
>                             PROT_READ | PROT_WRITE);
>                 } else {
> -                       pmap_enter(map->pmap, loopva, VM_PAGE_TO_PHYS(pg)=
,
> +                       if (pmap_enter(map->pmap, loopva, VM_PAGE_TO_PHYS=
(pg),
>                             PROT_READ | PROT_WRITE,
> -                           PROT_READ | PROT_WRITE | PMAP_WIRED);
> +                           PROT_READ | PROT_WRITE | PMAP_WIRED |
> +                           PMAP_CANFAIL) !=3D 0) {
> +                               pmap_remove(map->pmap, kva, loopva);
> +
> +                               while ((pg =3D TAILQ_LAST(&pgldone, pglis=
t))) {
> +                                       TAILQ_REMOVE(&pgldone, pg, pageq)=
;
> +                                       TAILQ_INSERT_HEAD(&pgl, pg, pageq=
);
> +                                       uvm_lock_pageq();
> +                                       uvm_pageclean(pg);
> +                                       uvm_unlock_pageq();
> +                               }
> +
> +                               if (obj !=3D NULL)
> +                                       rw_exit(obj->vmobjlock);
> +
> +                               uvm_unmap(map, kva, kva + size);
> +                               uvm_pglistfree(&pgl);
> +
> +                               return 0;
> +                       }
>                 }
>                 loopva +=3D PAGE_SIZE;
>                 offset +=3D PAGE_SIZE;
>
>
> --
> jca