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