This looks good... but it might be good to have at least a reference FAT image with the mal-formed LFN entry for regression.

Some typo fixes, nothing major.

Address review comments

I thought about reordering the functions, but I didn't want to tinker with them much considering that I am still learning about hwpmc. Reordering could bring newer issues that I couldn't foresee immediately. Even though this is a big hammer, the second-order effects seem to me to be better understood. Also, reordering alone wouldn't close the switch-in race: pmc_process_csw_in() takes the PMC pointer from the process's table without holding a reference, so a release could free the PMC before the runcount increment, whatever the order. Some kind of grace period or locking would still be needed.

In D61482#1409597, @seuros wrote:

https://gist.github.com/seuros/c83b357a2c8c652e3e09016015dd6245

In D61437#1409130, @se wrote:

The patch to use _PATH_LOCALBASE should not have been applied to contrib software that has been imported verbatim.
Therefore, the src/contrib directory (and src/sys/contrib etc.) had been excluded, but the fact that other such files exist below src/crypto had been missed.

Address review

LGTM

Does emulate_inout_port() in the kernel need the same change?

Hm, now that I'm looking at it .. is there really no way to make the pmc_process_csw_in() / pmc_process_csw_out() routines order things in a way that would avoid this?
I don't mind using a big hammer like this right now if there's no neater semantics to fix the refcount vs PMC alloc/dealloc logic, but I do wonder if some better lifecycle definition would make this less costly.

Looks good. Another nit: Let's drop the emoji from the commit message.

A short note on the commit message: Usually in commit message I only put 1) what is the problem, 2) how to solve it, 3) if it's hard to explain in theory, what's an example and I think this deserves having 3). Meanwhile, I think how we got here part (paragraph on initial approach) and how it was reported can be replaced by Differential Revision: and the mailing list thread (Reported by: avg@ <link>) respectively. Then 1), 2), 3) can be more consolidated (I asked LLM to rephrase the commit message and it gave me one shorter and easier to understand). There are few reasons I want to keep commit message concise, one of them is because I don't want my commit message to take too much space when others are scrolling git log.

LGTM

Yes, I like this solution more than fixing in stealing code path.