Re: bin/59996: swapctl: SWAP_STATS different to SWAP_NSWAP (1 != 3)

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

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/59996: swapctl: SWAP_STATS different to SWAP_NSWAP (1 != 3)
Date: Thu, 12 Feb 2026 12:47:19 +0700

     Date:        Wed, 11 Feb 2026 23:05:00 +0000 (UTC)
     From:        "wiz%NetBSD.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>
     Message-ID:  <20260211230500.95C061A923D%mollari.NetBSD.org@localhost>
 
   | When running "swapctl -l" in a loop (1/s) on a busy machine (bulk buil=
 d)
   | with 10%-25% of available swap used, I sometimes see errors like
   |
   | swapctl: SWAP_STATS different to SWAP_NSWAP (1 !=3D 3)
 
 The only way that can happen, I believe, is if something is changing the
 order of the swap device list while swapctl is running fetching the stats.
   =
 
   | I changed the code to use warn() instead of warnx(), but errno is not =
 set:
 
 Yes, that was a poor suggestion (waste of your time) - as long as swapctl(=
 2)
 is not returning -1 errno would be meaningless, even if set, and it isn't
 returning -1 it is returning 1 or 2 (for you) in the cases where the warni=
 ng is
 generated.
 
 So, it cannot be copyout() that is failing, that would cause swapctl(2)
 to return -1 - the only way I can see the kernel loop failing to run 3
 times (in your case) would be if the code asked for less than 3 stats
 records (and swapctl(8) does not do that) or if the end of the kernel swap
 device list is reached prematurely.
 
 Since (I gather) after failing, it returns to returning 3 again for a whil=
 e,
 the kernel is obviously not "losing" swap devices, so all I can imagine is
 that the list is being reordered, and the swapctl(2, SWAP_STATS) kernel co=
 de
 is not locking things to prevent that, or detecting when it has happened a=
 nd
 restarting (which would probably be the better solution - stats fetching
 should not usually affect operations in any way at all).
 
 One thing you could try, if you feel inclined, would be to give your 3
 swap devices different priorities - either by adding priority=3DN options
 to /etc/fstab, or by running
 	swapctl -c -p N swapdev-path
 afterwards.
 
 If it is just the list of swap devices at the same priority being reordere=
 d,
 then moving each of them to a different priority should avoid that happeni=
 ng.
 
 Whether this would end up showing anything (as in no more errors) is 100%
 uncertain, but if it did it would be a clear indication of the issue.
 
 kre