]> www.infradead.org Git - users/dwmw2/linux.git/commit
powerpc/pkeys: Fix reading of ibm, processor-storage-keys property
authorThiago Jung Bauermann <bauerman@linux.ibm.com>
Thu, 20 Sep 2018 04:38:58 +0000 (01:38 -0300)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 3 Oct 2018 23:59:27 +0000 (16:59 -0700)
commit7f3a5baeacdfbecacfb0bcd147fd30171ea5f9dd
tree747d8b8edadeed4275f4eb0ee0e26ab16509741a
parent4faeadc4f7b5deafc160132c3eb67eb4ae841b38
powerpc/pkeys: Fix reading of ibm, processor-storage-keys property

commit c716a25b9b70084e1144f77423f5aedd772ea478 upstream.

scan_pkey_feature() uses of_property_read_u32_array() to read the
ibm,processor-storage-keys property and calls be32_to_cpu() on the
value it gets. The problem is that of_property_read_u32_array() already
returns the value converted to the CPU byte order.

The value of pkeys_total ends up more or less sane because there's a min()
call in pkey_initialize() which reduces pkeys_total to 32. So in practice
the kernel ignores the fact that the hypervisor reserved one key for
itself (the device tree advertises 31 keys in my test VM).

This is wrong, but the effect in practice is that when a process tries to
allocate the 32nd key, it gets an -EINVAL error instead of -ENOSPC which
would indicate that there aren't any keys available

Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem")
Cc: stable@vger.kernel.org # v4.16+
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arch/powerpc/mm/pkeys.c