Re: kern/56764

["Thomas Klausner via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Thomas Klausner <wiz%netbsd.org@localhost>
To: Robert Elz <kre%munnari.oz.au@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: kern/56764
Date: Sat, 21 Feb 2026 18:30:55 +0100

 Hi!
 
 Thanks for looking at this.
 
 On Sun, Feb 22, 2026 at 12:10:53AM +0100, Robert Elz wrote:
 > 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.
 
 I thought this was the case because of functions like uvm_swapisfull, in full:
 
  bool
  uvm_swapisfull(void)
  {
          int swpgonly;
          bool rv;
 
          if (uvmexp.swpages == 0) {
                  return true;
          }
 
          mutex_enter(&uvm_swap_data_lock);
          KASSERT(uvmexp.swpgonly <= uvmexp.swpages);
          swpgonly = (int)((uint64_t)uvmexp.swpgonly * 100 /
              uvm_swapisfull_factor);
          rv = (swpgonly >= uvmexp.swpgavail);
          mutex_exit(&uvm_swap_data_lock);
 
          return (rv);
  }
 
 It only accesses uvmexp members and still grabs the lock.
 
 > 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.
 
 If you look closely you'll find that swpginuse is only modified when
 uvm_swap_data_lock is held.
 
 That was the other reason why I thought the same should apply to
 swpgonly.
 
 > 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.
 
 I've hijacked this PR a bit - it was about
 
 kernel diagnostic assertion "uvmexp.swpgonly > 0" failed
 
 while I was hitting
 
 kernel diagnostic assertion "uvmexp.swpgonly < uvmexp.swpginuse" failed
 
 the swpgonly > 0 definitely sounds sane while the other one should
 (according to Chuck) always be true too.
  Thomas