The bump to MAXCPU 256 makes cpuset_t larger, so minimum setsize checks in cpuset_* fail for binaries compiled against earlier versions (with MAXCPU 64).
I seen one report that 10.1-STABLE instantly reboots after updating to r283303. Could this be the cause of that?
Hmm, the simplest change is to revert MAXCPU for now. Longer term it might be nice to rework the cpusetsize changes so that they only fail if there are CPU IDs that don't fit in the requested size.
I think doing that would involve:
1) Replacing 'sizeof(cpuset_t)' with something like '(mp_maxid + NBBY - 1) / NBBY'
2) When working with a cpuset internally rounding up the size to 'sizeof(cpuset_t)' to pass around internally and then truncating to the requested size when doing a copyout.
A commit references this bug:
Date: Tue Jun 23 06:30:37 UTC 2015
New revision: 284720
Revert part of the r283303 (by jhb):
Revert MFC of r270223, which bumped MAXCPU on amd64 from 64 to 256.
The cpuset_getaffinity(2) and cpuset_setaffinity(2) check minimum set
size, which now fails for binaries compiled on 10.0 with MAXCPU == 64.
Submitted by: jhb
Shouldn't cpuset users be querying the cpuset size from sysctl and using that as their allocation base?
Offending commit has been reverted.