I ended up working around this with a pthread_atfork handler disabling my usage of the feature in the child process for the time being. I don't have an easy way to detect if the bug is present within a library so I'm going to need a kernel version check with a table of kernel releases fixing the problem for each stable branch.
It would be helpful if there was a new cpuinfo flag to check if the MPK state is preserved on fork in addition to the existing ospke flag. The problem will fade away over time but in my experience there are a lot of people using distributions with kernels not incorporating all of the stable fixes. I expect other people will run into the problem once hardware with MPK is more widely available and other people try to use it for various things like moving GC or assorted security features. Someone will end up running software adopting it on an older kernel with the problem. The clobbering issue I found with MAP_FIXED_NOREPLACE isn't quite as annoying because it was easy to make a runtime test usable in a library to see if the feature works properly.
