Re: kern/56764

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/56764; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, wiz%netbsd.org@localhost
Cc: 
Subject: Re: kern/56764
Date: Sun, 22 Feb 2026 00:10:53 +0700

     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!