PR/59996 CVS commit: src/sbin/swapctl

["Robert Elz" <kre%netbsd.org@localhost>]

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

From: "Robert Elz" <kre%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/59996 CVS commit: src/sbin/swapctl
Date: Mon, 16 Feb 2026 20:35:30 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Mon Feb 16 20:35:30 UTC 2026
 
 Modified Files:
 	src/sbin/swapctl: swaplist.c
 
 Log Message:
 PR bin/59996  No more "SWAP_STATS different to SWAP_NSWAP"
 
 That the kernel data structs might have changed between one
 system call and another, later one, does not warrant a warning.
 
 In this case this can happen if a swap device is removed from the
 system while swapctl(8) (swapctl -l or -s) (or pstat(8) (pstat -s),
 which is similarly affected) is running, at just the "wrong" time.
 This isn't an error.   This was always handled correctly, but with
 the meaningless warning added.
 
 There's also the other case, where a swap device has been added, instead
 of removed, at just the same "wrong" time.   Since the kernel won't return
 stats for more devices than requested, which was the number returned from
 the earlier call, the code never noticed this case, and simply printed
 less data than the kernel could have supplied.  That sounds like it is
 just another example of the race above, and could simply be ignored - but
 it isn't quite that simple.  If the kernel was returning the older devices,
 and omitting the newer one(s), then it would be OK, but there is no
 guarantee that is what happens - it might easily return the new device(s)
 (or some of them) along with some of the older ones, omitting others.
 That's not ideal.
 
 To cope, just request a few more swap device stats from the kernel than
 it reported were available.   If it happens that some were added, there
 will be space in the buffer provided for the kernel to add the new
 one(s) - unless many new ones happened to get added in the relatively
 short interval involved.   This way, we should usually get all of them.
 In the normal case where no devices have been added or deleted, a few
 extra bytes (maybe a KB, not a huge amount) will have been malloc()'d.
 That's harmless.
 
 Note that this kind of thing was not the reason for the messages reported
 in the PR - that was a kernel bug, caused by the kernel reordering its
 list of swap devices at an inopportune time (and then potentially returning
 less devices than requested, even though all were still there).
 
 That's fixed, but the kernel list reordering remains - along with its
 effect of returning the swap devices in an almost arbitrary order - it
 returns them in priority order, always, but within one priority, the
 devices will be returned in any random order.
 
 So, while here, deal with that.  Sort the list returned, and thus always
 print the devices in a stable order - sorted by priority, and then by the
 device name (which is more or less arbitrary, the actual order might not
 make much sense, but at least it will be a consistent order).
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.21 -r1.22 src/sbin/swapctl/swaplist.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.