Re: [PATCH 6/9] x86, pkeys: add pkey set/get syscalls

From: Ingo Molnar
Date: Fri Jul 08 2016 - 03:18:27 EST



* Dave Hansen <dave@xxxxxxxx> wrote:

> > Applications that frequently get called will get hammed into the ground with
> > serialisation on mmap_sem not to mention the cost of the syscall entry/exit.
>
> I think we can do both of them without mmap_sem, as long as we resign ourselves
> to this just being fundamentally racy (which it is already, I think). But, is
> it worth performance-tuning things that we don't expect performance-sensitive
> apps to be using in the first place? They'll just use the RDPKRU/WRPKRU
> instructions directly.
>
> Ingo, do you still feel strongly that these syscalls (pkey_set/get()) should be
> included? Of the 5, they're definitely the two with the weakest justification.

Firstly, I'd like to thank Mel for the review, having this kind of high level
interface discussion was exactly what I was hoping for before we merged any ABI
patches.

So my hope was that we'd also grow some debugging features: such as a periodic
watchdog timer clearing all non-allocated pkeys of a task and re-setting them to
their (kernel-)known values and thus forcing user-space to coordinate key
allocation/freeing.

While allocation/freeing of keys is very likely a slow path in any reasonable
workload, _setting_ the values of pkeys could easily be a fast path. The whole
point of pkeys is to allow both thread local and dynamic mapping and unmapping of
memory ranges, without having to touch any page table attributes in the hot path.

Now another, more fundamental question is that pkeys are per-CPU (per thread) on
the hardware side - so why do we even care about the mmap_sem in the syscalls in
the first place? If we want any serialization wouldn't a pair of
get_cpu()/put_cpu() preemption control calls be enough? Those would also be much
cheaper.

The idea behind my suggestion to manage all pkey details via a kernel interface
and 'shadow' the pkeys state in the kernel was that if we don't even offer a
complete system call interface then user-space is _forced_ into using the raw
instructions and into implementing a (potentially crappy) uncoordinated API or not
implementing any API at all but randomly using fixed pkey indices.

My hope was to avoid that, especially since currently _all_ memory mapping details
on x86 are controlled via system calls. If we don't offer that kind of facility
then we force user-space into using the raw instructions and will likely end up
with a poor user-space interface.

So the question is, what is user-space going to do? Do any glibc patches exist?
How are the user-space library side APIs going to look like?

Thanks,

Ingo