On Tue, Feb 17, 2026 at 09:01:59PM +0100, Claudio Jeker wrote:
> On Tue, Feb 17, 2026 at 09:31:02AM +0100, Martin Pieuchot wrote:
> > The wraparound bug is still alive and hit by syzkaller:
> >   https://syzkaller.appspot.com/bug?extid=db99726653fba0697bd8
> >
> > I'd like to be sure that the amap_copy() in uvm_map_pageable_wire() is not
> > responsible for inserting a new entry with a `wired_count' of 0.
> >
> > ok?
>
> Actually isn't this all because of your commit:
> https://github.com/openbsd/src/commit/834e1ba023872bfbdd8033c621ccc95fcd7617b7
>
>   Push `pageqlock' dances inside uvm_page{de,}activate() & uvm_pagewire().
>
>   Tested during multiple bulks on amd64, i386, arm64 and sparc64 by jca@,
>   phessler@ and sthen@.
>
> At least that commit fits fairly well with the first encounter of those
> asserts and the code does a few strange lock changes right around places
> where the wire counts matter.
>
> Doing a unlock, call function which locks then unlocks and on return lock
> the whole thing again is very error prone since after each unlock call a
> other caller may go in and modify the object you work on.
>
> I'm very unhappy with the pageq and fpageq lock but this diff made it
> worse. IMO we need to revert this and see if that fixes the issue so we
> can stop hunting ghosts that should not exist.
> --
> :wq Claudio
>

given the recent batch of instability introduced by other uvm changes, is there
any reason for NOT reverting this also right away?