Page MenuHomeFreeBSD

Define MAXCPU consistently between the kernel and KLDs.
ClosedPublic

Authored by markj on Feb 5 2020, 12:33 AM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Jun 27, 10:59 PM
Unknown Object (File)
Tue, Jun 25, 7:12 PM
Unknown Object (File)
Fri, Jun 21, 10:40 AM
Unknown Object (File)
Fri, Jun 21, 8:45 AM
Unknown Object (File)
Fri, Jun 14, 6:39 AM
Unknown Object (File)
May 10 2024, 8:54 AM
Unknown Object (File)
Feb 26 2024, 2:15 PM
Unknown Object (File)
Jan 28 2024, 10:52 AM

Details

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

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 29176
Build 27108: arc lint + arc unit

Event Timeline

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.

This revision is now accepted and ready to land.Feb 5 2020, 5:30 PM
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.