Build date: 1769641203 - Wed Jan 28 23:00:03 UTC 2026
Build cvs date: 1769636763 - Wed Jan 28 21:46:03 UTC 2026
Build id: 2026-01-29.1
Build tags: amd64-regress ports sysupgrade

Applied the following diff(s):
/home/anton/tmp/robsd/src-sys-em.diff
/home/anton/tmp/robsd/src-sys-uhidev-sispm.diff
/home/anton/tmp/robsd/src-sysupgrade.diff

P bin/ls/ls.c
P regress/usr.sbin/rpki-client/test-cert.c
M sys/dev/usb/uhidev.c
P sys/uvm/uvm_pdaemon.c
P sys/uvm/uvm_pmemrange.c
P sys/uvm/uvm_pmemrange.h
M usr.sbin/bgpd/session.c
P usr.sbin/rpki-client/cert.c
P usr.sbin/rpki-client/extern.h
P usr.sbin/rpki-client/filemode.c

commit OpML6UAuHJ2cnPMw
Author: deraadt
Date: 2026/01/28 21:46:03

  In uvm_pdaemon.c 1.121, 1.122, and 1.123, two things happened:

  1. The shortage target inside uvmpd_scan() / uvmpd_scan_inactive() which
  used to be computed using the realtime uvmexp.free value, was replaced with a
  (historic prediction) using the pre-existing pagedaemon "shortage" variable.
  This means the scanner will continue work even if the system recovers
  memory asyncronously and has resolved the scarcity which caused the pagedaemon
  to be summoned.  That's a bad idea. The code should revert to observing
  realtime system conditions.  We don't have a diff for that yet, but the
  other concern is immediate:

  2. The pre-existing calculation of the "shortage" variable was changed
  significally, without verifying correct behaviour.
  size += shortage;
  ...
  shortage -= bufbackoff(&constraint, size * 2);
  since bufbackoff() returns how much it did, and generally succeeds at
  satisfying the full request size * 2, that is effectively "shortage =
  -shortage".  The scan function changes still expect a positive target
  value. The result is uvmpd_scan_inactive() runs the entire list, which
  delays the pagedaemon performing it's other roles (wakeups, looking
  around to choose new targets, and use other cheaper memory recovery
  mechanisms).  This diff works around that by clamping negative to 0.
  ok claudio beck

  sys/uvm/uvm_pdaemon.c

commit s4hCf18TajWxFWUn
Author: deraadt
Date: 2026/01/28 21:09:41

  The pagedaemon inspects the top-most sleeping pmemrange allocation for
  for size and constraint, and passes this information to the inactive
  scanner.  The idea is that an extremely high-size and
  strict-constraint allocation that fails repeatedly would percolate to
  the top of the list.  To ensure the scanner can inspect this
  allocation's constraint via the pointer, it gets locked.  Then we
  release tons of memory from the buffer cache, and run the scanner to
  recover free memory.  At the same time, other running operations free
  and allocate memory and wakeup all the sleeping pmemrange allocations,
  but no, not this one, because it is locked so that the pointer won't
  become invalid.  When the scan is done, we may once again have meager
  memory resources because all the good stuff was allocated by
  asyncronous allocators, potentially creating substantial fragmentation
  not compatible with the constraint.  Now, the sleeping request gets
  unlocked and woken to re-check it's requirements and guess what, the
  constraint fails it goes back to sleep, and we need to go around
  again... In practice this is a hard uvm deadlock.
  Instead, copy the constraint from the request, do not lock the
  allocation request and ignore the pointer.
  Instrumentation is showing this top-most request is ALWAYS satisfied
  during the bufbackoff() sequence, but we'll continue passing the
  constraint to the scanner as a last-ditch effort.
  ok claudio beck kettenis

  sys/uvm/uvm_pdaemon.c
  sys/uvm/uvm_pmemrange.c
  sys/uvm/uvm_pmemrange.h

commit 7k0Y8UCkWnmM0E62
Author: fcambus
Date: 2026/01/28 20:31:49

  ls(1): use correct buffer size for ngroup.

  In numeric long format, ngroup is formatted using sizeof nuser. That's a
  copy-paste bug. It's harmless only because the arrays are the same size
  today; it would become a real truncation/overflow risk if they ever
  diverge.

  From Michal Mazurek (akfaew@), thanks!

  OK kn@, tb@

  bin/ls/ls.c

commit KCgu7FGhWP7mKICr
Author: tb
Date: 2026/01/28 08:42:07

  rpki-client: explain why we do what we do in ta_check_pubkey()

  The base64-encoded SPKI blob in the TAL should really be matched against
  the corresponding part of the cert's DER. Unfortunately, libcrypto only
  stores internal representations in the X509's cert_info field, so what it
  hands back via the X509_* and X509_PUBKEY_* API is at best re-encoded and
  therefore unsuitable for this purpose. Document this so when I will have
  forgotten this the day after tomorrow, I still have a chance of not wasting
  as much time for a third or fourth time next time I revisit this.

  ok claudio

  usr.sbin/rpki-client/cert.c

commit wUMI5k5pQazuVIEC
Author: tb
Date: 2026/01/28 08:29:19

  rpki-client regress: adjust for ta_parse() -> ta_validate() rename

  regress/usr.sbin/rpki-client/test-cert.c

commit 1NXJxhxAD9Ov3iMA
Author: tb
Date: 2026/01/28 08:28:34

  rpki-client: rename ta_parse() to ta_validate() and document it

  ta_parse() only parses the TAL's SPKI, so it is misnamed. What it really
  does is it compares the TA's SPKI to the TAL's SPKI and checks that it is
  a curently valid, self-signed cert.

  ok claudio

  usr.sbin/rpki-client/cert.c
  usr.sbin/rpki-client/extern.h
  usr.sbin/rpki-client/filemode.c