CVS commit: src/sbin/swapctl

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.