> On Oct 26, 2018, at 2:39 PM, Daniel Micay <danielmi...@gmail.com> wrote:
>
> 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
Can you not just make sure that the fix is backported to all relevant kernels?
I suppose we could add a new flag for pkey_get() or something.
> I'm going to need a kernel version check with a table of
> kernel releases fixing the problem for each stable branch.
That won’t work right on district kernels. Please don’t go there.
>
> 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.
