# fun with upgrading: cpuset panics



## PMc (Dec 6, 2020)

After a clean reboot I have some jails, and they have a cpuset.id attached:

```
# jls jid name cpuset.id
1 gate 3
3 raix 8
4 oper 7
5 admn 6
```
 etcetera etcetera

Now imagine I want to limit the cpu usage for some of these.
`# cpuset -l 1 -j 4`
That one works.
`# cpuset -l 0-3 -j 4
cpuset: setaffinity: Invalid argument`
But then going back again does not work.

Furthermore, as a bonus christmas gift, one gets rewarded with a kernel panic soon after, provided by courtesy of `thread 0, (thread taskq)`:

```
__mtx_lock_sleep() at __mtx_lock_sleep+0xd6/frame 0xfffffe00252a2990
_if_delgroup_locked() at _if_delgroup_locked+0x465/frame 0xfffffe00252a29e0
if_detach_internal() at if_detach_internal+0x24e/frame 0xfffffe00252a2a40
if_vmove() at if_vmove+0x3c/frame 0xfffffe00252a2a90
vnet_if_return() at vnet_if_return+0x50/frame 0xfffffe00252a2ab0
vnet_destroy() at vnet_destroy+0x136/frame 0xfffffe00252a2ae0
prison_deref() at prison_deref+0x27d/frame 0xfffffe00252a2b20
```
etcetera etcetera.

Without looking into details, I might assume this is related to the /usr/tests directory, as this has a simple psychological effect: people do no longer think about what they are doing, instead thinking that they have tests to rely on. The faultline here is that tests can only test for expected faults, whereas faults happen to happen where not expected.[/code]


----------



## PMc (Dec 7, 2020)

Correction: the panic is unrelated to cpuset. It happens always when stopping a jail.

And concerning the cpusets: the cpuset 1 and those defined for the jails have special "features", they are someway related and do not behave as documented.


----------

