Re: kern/56764

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sat, 21 Feb 2026 13:20:02 +0000 (UTC)
    From:        "Thomas Klausner via gnats" <gnats-admin%NetBSD.org@localhost>
    Message-ID:  <20260221132002.315021A923D%mollari.NetBSD.org@localhost>

  |  so is something else modifying the values without a proper lock?

I know nothing about the UVM system, so nothing I say should be treated
as being correct, but will perhaps inspire someone who knows more to
correct me.

But I just took a look, and I can see no evidence at all that anything in
uvmexp expects to take any kind of lock before modifications.

Some values (like uvmexp.swpgonly) are only ever modified via atomic
ops (increment/decrement/add) so in theory should be safe, but it isn't
listed as being volatile, so accesses to it could be cached for who
knows how long (in a local register) while the actual value is being
modified by some other thread.   Others (like uvmexp.swpginuse) are
simply modified by regular C += and -= operations.

All of this looks very unsafe to me, for as much as the uvmexp values are
just FYIs, it would all be OK, and many of the values are, though just
being int (for almost all of them) many are very likely to overflow on
a busy system, and I see that the many of the values in your gdb dump of
the struct are negative which almost certainly means they overflowed).

But some of the values (like these two) aren't quite the same, they're
actually tracking the state of the swap system.   But the way things are
done, I don't know that it makes sense to ever compare them, despite the
logic of their uses implying that should be possible (one would expect that
the number of swap pages allocated to pages that are only resident on the
swap device (/dev/drum) must be less than the total number of swap pages
allocated, or at least not greater, as there would often be some pages
resident in both ram and on the swap device, which should make a difference).

WRT your newer message:


gnats-admin%NetBSD.org@localhost (wiz@ really) said:
  |  In uvm_swap_markbad() the change is protected by
  | mutex_enter(&uvm_swap_data_lock),

Not really, that lock is held, but its purpose is to protect the swapdev
lists, it prevents manipulations of those lists while held, it isn't
intended to apply to uvmexp, which as I said above, I don't think anything
is.

I think I'd just remove the KASSERT that is firing for you, and look for
some other way to try and understand the original problem from the PR.

kre

ps: once again, I really have no idea what I am typing about!