Define MAXCPU consistently between the kernel and KLDs.

[markj]

Summary

The current behaviour comes from r177661. I don't quite understand the
logic: if it's a third-party module, then presumably it was compiled
with SMP enabled, so it'll see the default MAXCPU value anyway.
If it was compiled together with the kernel, then KLDs should use the
same value as the kernel.

The current behaviour ensures that KLDs see a different layout for
cpuset_t than a non-SMP kernel. This breaks a few interfaces, notably
smp_rendezvous_cpus(), which takes a cpuset_t by value.

PR: 243711

[jhb]

Hmm, I don't understand the original logic either. Note that at the time we didn't have KLD_TIED, so it would have applied to kernel modules built together with the kernel. Given the author, it must have been dtrace related? I think your change is fine.

[markj]

In D23512#516147, @jhb wrote:

Hmm, I don't understand the original logic either. Note that at the time we didn't have KLD_TIED, so it would have applied to kernel modules built together with the kernel. Given the author, it must have been dtrace related? I think your change is fine.

Interestingly, the problem came up because of dtrace's use of smp_rendezvous_cpus(). smp_rendezvous_cpus() was added a bit later, also by jb@, in r179230, but it took a (fixed width) cpumask_t instead of a cpuset_t. The conversion to cpuset_t happened in r223758.