| Message ID | 20180920043858.28773-1-bauerman@linux.ibm.com (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | c716a25b9b70084e1144f77423f5aedd772ea478 |
| Headers | show |
| Series | powerpc/pkeys: Fix reading of ibm, processor-storage-keys property | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | next/apply_patch Successfully applied |
| snowpatch_ozlabs/checkpatch | success | Test checkpatch on branch next |
| snowpatch_ozlabs/build-ppc64le | success | Test build-ppc64le on branch next |
| snowpatch_ozlabs/build-ppc64be | success | Test build-ppc64be on branch next |
| snowpatch_ozlabs/build-ppc64e | success | Test build-ppc64e on branch next |
| snowpatch_ozlabs/build-ppc32 | success | Test build-ppc32 on branch next |
On Thu, Sep 20, 2018 at 01:38:58AM -0300, Thiago Jung Bauermann wrote: > 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 Thanks for the fix. Reviewed-by: Ram Pai <linuxram@us.ibm.com> > > Fixes: cf43d3b26452 ("powerpc: Enable pkey subsystem") > Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> > --- > arch/powerpc/mm/pkeys.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c > index 333b1f80c435..b271b283c785 100644 > --- a/arch/powerpc/mm/pkeys.c > +++ b/arch/powerpc/mm/pkeys.c > @@ -45,7 +45,7 @@ static void scan_pkey_feature(void) > * Since any pkey can be used for data or execute, we will just treat > * all keys as equal and track them as one entity. > */ > - pkeys_total = be32_to_cpu(vals[0]); > + pkeys_total = vals[0]; > pkeys_devtree_defined = true; > }
On Thu, 2018-09-20 at 04:38:58 UTC, Thiago Jung Bauermann wrote: > 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") > Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> Applied to powerpc fixes, thanks. https://git.kernel.org/powerpc/c/c716a25b9b70084e1144f77423f5ae cheers
diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c index 333b1f80c435..b271b283c785 100644 --- a/arch/powerpc/mm/pkeys.c +++ b/arch/powerpc/mm/pkeys.c @@ -45,7 +45,7 @@ static void scan_pkey_feature(void) * Since any pkey can be used for data or execute, we will just treat * all keys as equal and track them as one entity. */ - pkeys_total = be32_to_cpu(vals[0]); + pkeys_total = vals[0]; pkeys_devtree_defined = true; }
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") Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com> --- arch/powerpc/mm/pkeys.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)