hwpmc on non-SMP issue

[br]

Summary

For non-SMP kernel we have sizeof(cpuset_t) == 8 as MAXCPU == 1, but modules always built with MAXCPU >= 1 (e.g. 96 on AArch64), and so sizeof(cpuset_t) is bigger than 8 bytes.

This currently leads to kernel panic when hwpmc module proceed CPU_ZERO(&pmc_cpumask) call as it overwrites memory after pmc_cpumask.

With this patch we building modules tied to kernel as "options SMP" changes KBI

This fixes operation of HWPMC on UP.

Test Plan

kldload ./hwpmc.ko && kldunload ./hwpmc.ko && kldload ./hwpmc.ko && pmccontrol -L

[kib]

I do not think that your statement about modules always build with MAXCPU > 1 is true. Modules, if build properly, are build against opt_*.h set from the configured kernel, and this would provide the right values for SMP and related symbols.

In other words, I believe that your issue is a user error, building modules outside the kernel configuration set and then using it on KBI-incompatible kernel. Yes, options SMP changes KBI.

[br]

In D14353#300792, @kib wrote:

I do not think that your statement about modules always build with MAXCPU > 1 is true. Modules, if build properly, are build against opt_*.h set from the configured kernel, and this would provide the right values for SMP and related symbols.

In other words, I believe that your issue is a user error, building modules outside the kernel configuration set and then using it on KBI-incompatible kernel. Yes, options SMP changes KBI.

No, both of my kernel & hwpmc.ko are product of 'make buildkernel'. And I load hwpmc.ko to the corresponding kernel.
Take a look at amd64/include/param.h, I think KLD_MODULE macro is defined when we build modules, in result MAXCPU is 256 for modules even with non-SMP kernel.

[kib]

In D14353#301078, @br wrote:

In D14353#300792, @kib wrote:

I do not think that your statement about modules always build with MAXCPU > 1 is true. Modules, if build properly, are build against opt_*.h set from the configured kernel, and this would provide the right values for SMP and related symbols.

In other words, I believe that your issue is a user error, building modules outside the kernel configuration set and then using it on KBI-incompatible kernel. Yes, options SMP changes KBI.

No, both of my kernel & hwpmc.ko are product of 'make buildkernel'. And I load hwpmc.ko to the corresponding kernel.
Take a look at amd64/include/param.h, I think KLD_MODULE macro is defined when we build modules, in result MAXCPU is 256 for modules even with non-SMP kernel.

I see. This param.h change came from r177661, and perhaps it is becomes the bug at current time.

I would prefer that modules started following SMP KBI of the kernel. I added John to the discussion.

[br]

Revert r177661 ("When building a kernel module, define MAXCPU the same as SMP so that modules work with and without SMP.").
"option SMP" changes KBI, so r177661 is an issue

[jhb]

Hmmm. This is kind of related to my desire to start inlining atomics on x86, etc. I think I want a new macro to help us distinguish building a "generic" module vs a module tied to a kernel. Simply not defining KLD_MODULE when building modules tied to a kernel doesn't work (I've tried), and I haven't yet decided how I wanted to proceed after that failed. I think I a new macro for the case of a generic module is probably more useful as most places will want to check that instead of KLD_MODULE that wish to differentiate the two. I'd like to see what @kib thinks about maybe adding a new macro for "generic" modules and using that to fix this instead.

sys/sparc64/include/param.h

60

Note that all the comments are stale.

[br]

Fix comments

sys/sparc64/include/param.h

60

Thanks! fixed

[br]

In D14353#306252, @jhb wrote:

Hmmm. This is kind of related to my desire to start inlining atomics on x86, etc. I think I want a new macro to help us distinguish building a "generic" module vs a module tied to a kernel. Simply not defining KLD_MODULE when building modules tied to a kernel doesn't work (I've tried), and I haven't yet decided how I wanted to proceed after that failed. I think I a new macro for the case of a generic module is probably more useful as most places will want to check that instead of KLD_MODULE that wish to differentiate the two. I'd like to see what @kib thinks about maybe adding a new macro for "generic" modules and using that to fix this instead.

And then we say that some modules are not generic (e.g. HWPMC), i.e. tied to kernel, but the rest are generic ?
Just trying to understand your idea

[br]

In D14353#306252, @jhb wrote:

Hmmm. This is kind of related to my desire to start inlining atomics on x86, etc. I think I want a new macro to help us distinguish building a "generic" module vs a module tied to a kernel. Simply not defining KLD_MODULE when building modules tied to a kernel doesn't work (I've tried), and I haven't yet decided how I wanted to proceed after that failed. I think I a new macro for the case of a generic module is probably more useful as most places will want to check that instead of KLD_MODULE that wish to differentiate the two. I'd like to see what @kib thinks about maybe adding a new macro for "generic" modules and using that to fix this instead.

Hi John. Why do you want generic modules? i.e. modules that are not tied to kernel