Andrew,
The first patch in this series hits architecture independent code, but the
rest is contained in the powerpc subtree. Could you pick up the first
patch into -mm? I can send the rest of them through the powerpc git tree.
The first patch and the rest of the set are independent and can be merged
in either order.
Changes since I posted on June 10:
- Fixed reversed logic in arch_validate_prot() in include/asm-powerpc/mman.h
- Replace binary & with logical && in arch_validate_prot()
- Got rid of HAVE_ARCH_PROT_BITS
Allow an application to enable Strong Access Ordering on specific pages of
memory on Power 7 hardware. Currently, power has a weaker memory model than
x86. Implementing a stronger memory model allows an emulator to more
efficiently translate x86 code into power code, resulting in faster code
execution.
On Power 7 hardware, storing 0b1110 in the WIMG bits of the hpte enables
strong access ordering mode for the memory page. This patchset allows a
user to specify which pages are thus enabled by passing a new protection
bit through mmap() and mprotect(). I have tentatively defined this bit,
PROT_SAO, as 0x10.
In order to accomplish this, I had to modify the architecture-independent
code to allow the architecture to deal with additional protection bits.
Thanks,
Shaggy
--
This patch defines:
- PROT_SAO, which is passed into mmap() and mprotect() in the prot field
- VM_SAO in vma->vm_flags, and
- _PAGE_SAO, the combination of WIMG bits in the pte that enables strong
access ordering for the page.
NOTE: There doesn't seem to be a precedent for architecture-dependent vm_flags.
It may be better to define VM_SAO somewhere in include/asm-powerpc/. Since
vm_flags is a long, defining it in the high-order word would help prevent a
collision with any newly added values in architecture-independent code.
Signed-off-by: Dave Kleikamp <redacted>
---
include/asm-powerpc/mman.h | 2 ++
include/asm-powerpc/pgtable-ppc64.h | 3 +++
include/linux/mm.h | 1 +
3 files changed, 6 insertions(+)
Index: linux-2.6.26-rc5/include/asm-powerpc/mman.h
===================================================================
This patch applies on top of the patches posted today to linuxppc-dev by
Michael Neuling and Joel Schopp.
Signed-off-by: Joel Schopp <redacted>
Signed-off-by: Dave Kleikamp <redacted>
Index: linux-2.6.26-rc5/include/asm-powerpc/cputable.h
===================================================================
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
Note: vm_get_page_prot() is now pretty ugly. Suggestions?
Signed-off-by: Dave Kleikamp <redacted>
---
include/linux/mman.h | 28 +++++++++++++++++++++++++++-
mm/mmap.c | 5 +++--
mm/mprotect.c | 2 +-
3 files changed, 31 insertions(+), 4 deletions(-)
Index: linux-2.6.26-rc5/include/linux/mman.h
===================================================================
@@ -502,9 +502,8 @@ repeat:new_pte=(new_pte&~_PAGE_HPTEFLAGS)|_PAGE_HASHPTE;/* Add in WIMG bits */-/* XXX We should store these in the pte */-/* --BenH: I think they are ... */-rflags|=_PAGE_COHERENT;+rflags|=(new_pte&(_PAGE_WRITETHRU|_PAGE_NO_CACHE|+_PAGE_COHERENT|_PAGE_GUARDED));/* Insert into the hash table, primary slot */slot=ppc_md.hpte_insert(hpte_group,va,pa,rflags,0,
Allow an application to enable Strong Access Ordering on specific pages of
memory on Power 7 hardware. Currently, power has a weaker memory model than
x86. Implementing a stronger memory model allows an emulator to more
efficiently translate x86 code into power code, resulting in faster code
execution.
On Power 7 hardware, storing 0b1110 in the WIMG bits of the hpte enables
strong access ordering mode for the memory page. This patchset allows a
user to specify which pages are thus enabled by passing a new protection
bit through mmap() and mprotect(). I have tentatively defined this bit,
PROT_SAO, as 0x10.
Signed-off-by: Dave Kleikamp <redacted>
---
arch/powerpc/kernel/syscalls.c | 3 +++
include/asm-powerpc/mman.h | 28 ++++++++++++++++++++++++++++
2 files changed, 31 insertions(+)
Index: linux-2.6.26-rc5/arch/powerpc/kernel/syscalls.c
===================================================================
From: Andrew Morton <akpm@linux-foundation.org> Date: 2008-07-01 08:53:01
On Wed, 18 Jun 2008 17:32:55 -0500 shaggy@linux.vnet.ibm.com wrote:
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
It'd be simpler if Paul were to merge this. It doesn't conflict with
any pending work.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Note: vm_get_page_prot() is now pretty ugly.
It is. But afacit it generates the same code for non-powerpc.
From: Dave Kleikamp <hidden> Date: 2008-07-01 13:55:01
On Tue, 2008-07-01 at 01:53 -0700, Andrew Morton wrote:
On Wed, 18 Jun 2008 17:32:55 -0500 shaggy@linux.vnet.ibm.com wrote:
quoted
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
It'd be simpler if Paul were to merge this. It doesn't conflict with
any pending work.
That works for me. Paul, I'll send you an updated patchset.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
quoted
Note: vm_get_page_prot() is now pretty ugly.
It is. But afacit it generates the same code for non-powerpc.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-03 23:39:52
On Wed, 2008-06-18 at 17:32 -0500, shaggy@linux.vnet.ibm.com wrote:
Andrew,
The first patch in this series hits architecture independent code, but the
rest is contained in the powerpc subtree. Could you pick up the first
patch into -mm? I can send the rest of them through the powerpc git tree.
The first patch and the rest of the set are independent and can be merged
in either order.
../..
I was wondering... how do we inform userspace that this is available ?
Same question with adding the endian bit on 4xx which I plan to do using
your infrastructure...
We haven't defined a user-visible feature bit (and besides, we're really
getting short on these...). This is becoming a bit of concern btw (the
running out of bits). Maybe we should start defining an AT_HWCAP2 for
powerpc and get libc updated to pick it up ?
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-07 05:52:36
On Tue, 2008-07-01 at 13:54 +0000, Dave Kleikamp wrote:
On Tue, 2008-07-01 at 01:53 -0700, Andrew Morton wrote:
quoted
On Wed, 18 Jun 2008 17:32:55 -0500 shaggy@linux.vnet.ibm.com wrote:
quoted
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
It'd be simpler if Paul were to merge this. It doesn't conflict with
any pending work.
That works for me. Paul, I'll send you an updated patchset.
Please, CC me as I'll handle this merge window.
quoted
Acked-by: Andrew Morton <akpm@linux-foundation.org>
quoted
Note: vm_get_page_prot() is now pretty ugly.
It is. But afacit it generates the same code for non-powerpc.
From: Dave Kleikamp <hidden> Date: 2008-07-07 14:05:42
On Fri, 2008-07-04 at 09:39 +1000, Benjamin Herrenschmidt wrote:
On Wed, 2008-06-18 at 17:32 -0500, shaggy@linux.vnet.ibm.com wrote:
quoted
Andrew,
The first patch in this series hits architecture independent code, but the
rest is contained in the powerpc subtree. Could you pick up the first
patch into -mm? I can send the rest of them through the powerpc git tree.
The first patch and the rest of the set are independent and can be merged
in either order.
../..
I was wondering... how do we inform userspace that this is available ?
Same question with adding the endian bit on 4xx which I plan to do using
your infrastructure...
I hadn't really given it much thought. Is there a simple way to
determine if the cpu is power 7 or newer?
It's not elegant, but a program could call mmap() with PROT_SAO set and
check for errno == EINVAL. Then call again without PROT_SAO, if it
needs to.
We haven't defined a user-visible feature bit (and besides, we're really
getting short on these...). This is becoming a bit of concern btw (the
running out of bits). Maybe we should start defining an AT_HWCAP2 for
powerpc and get libc updated to pick it up ?
Joel,
Any thoughts?
Shaggy
--
David Kleikamp
IBM Linux Technology Center
On Tue, 2008-07-01 at 13:54 +0000, Dave Kleikamp wrote:
quoted
On Tue, 2008-07-01 at 01:53 -0700, Andrew Morton wrote:
quoted
On Wed, 18 Jun 2008 17:32:55 -0500 shaggy@linux.vnet.ibm.com wrote:
quoted
This patch allows architectures to define functions to deal with
additional protections bits for mmap() and mprotect().
arch_calc_vm_prot_bits() maps additonal protection bits to vm_flags
arch_vm_get_page_prot() maps additional vm_flags to the vma's vm_page_prot
arch_validate_prot() checks for valid values of the protection bits
It'd be simpler if Paul were to merge this. It doesn't conflict with
any pending work.
That works for me. Paul, I'll send you an updated patchset.
Please, CC me as I'll handle this merge window.
quoted
quoted
Acked-by: Andrew Morton <akpm@linux-foundation.org>
quoted
Note: vm_get_page_prot() is now pretty ugly.
It is. But afacit it generates the same code for non-powerpc.
quoted
Suggestions?
nfi. Let us rub the Hugh-summoning lamp.
Didn't rub hard enough ? :-)
Sorry, Andrew got the wrong pantomime: I was appearing in Aladdin
a couple of years ago, but this year I'm the Sleeping Beauty.
(Did I hear a grumble of dissent from the back stalls?)
I don't find Dave's patch very handsome, but it gets the job done
so I'd better not carp. The ugliness in vm_get_page_prot is just
an inevitable consequence of growing beyond the traditional neat
pairing of VM_xxx flags with VM_MAYxxx flags, along with the way
that opaque pgprot_t type becomes occasionally tiresome, as such
opaque types do: I don't think there's a better way of handling
it than Dave has done.
There is a little inconsistency, that arch_calc_vm_prot_bits
and arch_vm_get_page_prot just handle the exceptional flag (SAO),
whereas arch_validate_prot handles all of them; but I don't feel
so strongly about that to suggest resubmission.
And regarding VM_SAO added to include/linux/mm.h in 3/6: although
it's odd to be weaving back and forth between arch-specific and
common, it's already the case that mman definitions and pgtable
definitions are arch-specific but mm.h common: I'm much happier
to have VM_SAO defined once there as Dave has it, than get into
arch-specific vm_flags.
Is someone going to be asking for PROT_WC shortly?
Hugh
@@ -239,7 +239,7 @@ sys_mprotect(unsigned long start, size_tend=start+len;if(end<=start)return-ENOMEM;-if(prot&~(PROT_READ|PROT_WRITE|PROT_EXEC|PROT_SEM))+if(!arch_validate_prot(prot))return-EINVAL;reqprot=prot;
--
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
From: Joel Schopp <hidden> Date: 2008-07-07 21:23:26
quoted
We haven't defined a user-visible feature bit (and besides, we're really
getting short on these...). This is becoming a bit of concern btw (the
running out of bits). Maybe we should start defining an AT_HWCAP2 for
powerpc and get libc updated to pick it up ?
Joel,
Any thoughts?
Is it a required or optional feature of the 2.06 architecture spec? If it's required you could just use that. It doesn't solve the problem more generically if other archs decide to implement it though.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-07 22:24:28
On Mon, 2008-07-07 at 22:11 +0100, Hugh Dickins wrote:
Sorry, Andrew got the wrong pantomime: I was appearing in Aladdin
a couple of years ago, but this year I'm the Sleeping Beauty.
(Did I hear a grumble of dissent from the back stalls?)
No comment :-)
I don't find Dave's patch very handsome, but it gets the job done
so I'd better not carp. The ugliness in vm_get_page_prot is just
an inevitable consequence of growing beyond the traditional neat
pairing of VM_xxx flags with VM_MAYxxx flags, along with the way
that opaque pgprot_t type becomes occasionally tiresome, as such
opaque types do: I don't think there's a better way of handling
it than Dave has done.
That was also my conclusion. It didn't look pretty but I couldn't come
up with something prettier.
There is a little inconsistency, that arch_calc_vm_prot_bits
and arch_vm_get_page_prot just handle the exceptional flag (SAO),
whereas arch_validate_prot handles all of them; but I don't feel
so strongly about that to suggest resubmission.
And regarding VM_SAO added to include/linux/mm.h in 3/6: although
it's odd to be weaving back and forth between arch-specific and
common, it's already the case that mman definitions and pgtable
definitions are arch-specific but mm.h common: I'm much happier
to have VM_SAO defined once there as Dave has it, than get into
arch-specific vm_flags.
Is someone going to be asking for PROT_WC shortly?
I'll definitely come with PROT_ENDIAN soon :-) (ie, some powerpc
processors can have a per-page endian flag that when set causes all
load/store instructions on this are to be byte-flipped, support for this
feature has been requested for some time, and now I have the
infrastructure to do it).
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-07 22:27:57
On Mon, 2008-07-07 at 16:23 -0500, Joel Schopp wrote:
quoted
quoted
We haven't defined a user-visible feature bit (and besides, we're really
getting short on these...). This is becoming a bit of concern btw (the
running out of bits). Maybe we should start defining an AT_HWCAP2 for
powerpc and get libc updated to pick it up ?
Joel,
Any thoughts?
Is it a required or optional feature of the 2.06 architecture spec? If it's required you could just use that. It doesn't solve the problem more generically if other archs decide to implement it though.
And then we start having to expose 2.06S vs. 2.06E .. nah.
I think for now, for SAO, the idea that one can "try" and if -EINVAL,
try again without might work fine.
Cheers,
Ben.
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2008-07-08 06:18:49
On Tue, 2008-07-08 at 08:24 +1000, Benjamin Herrenschmidt wrote:
quoted
There is a little inconsistency, that arch_calc_vm_prot_bits
and arch_vm_get_page_prot just handle the exceptional flag (SAO),
whereas arch_validate_prot handles all of them; but I don't feel
so strongly about that to suggest resubmission.
And regarding VM_SAO added to include/linux/mm.h in 3/6: although
it's odd to be weaving back and forth between arch-specific and
common, it's already the case that mman definitions and pgtable
definitions are arch-specific but mm.h common: I'm much happier
to have VM_SAO defined once there as Dave has it, than get into
arch-specific vm_flags.
Is someone going to be asking for PROT_WC shortly?
I'll definitely come with PROT_ENDIAN soon :-) (ie, some powerpc
processors can have a per-page endian flag that when set causes all
load/store instructions on this are to be byte-flipped, support for
this
feature has been requested for some time, and now I have the
infrastructure to do it).
BTW. Do we have your ack ?
Andrew, what tree should this go via ? I have further powerpc patches
depending on this one... so on one hand I'd be happy to take it, but
on the other hand, it's more likely to clash with other things...
Maybe I should check how it applies on top of linux-next.
Ben.
On Tue, 2008-07-08 at 08:24 +1000, Benjamin Herrenschmidt wrote:
quoted
quoted
There is a little inconsistency, that arch_calc_vm_prot_bits
and arch_vm_get_page_prot just handle the exceptional flag (SAO),
whereas arch_validate_prot handles all of them; but I don't feel
so strongly about that to suggest resubmission.
And regarding VM_SAO added to include/linux/mm.h in 3/6: although
it's odd to be weaving back and forth between arch-specific and
common, it's already the case that mman definitions and pgtable
definitions are arch-specific but mm.h common: I'm much happier
to have VM_SAO defined once there as Dave has it, than get into
arch-specific vm_flags.
Is someone going to be asking for PROT_WC shortly?
I'll definitely come with PROT_ENDIAN soon :-) (ie, some powerpc
processors can have a per-page endian flag that when set causes all
load/store instructions on this are to be byte-flipped, support for
this
feature has been requested for some time, and now I have the
infrastructure to do it).
BTW. Do we have your ack ?
To PROT_SAO? Okay,
Acked-by: Hugh Dickins <redacted>
Andrew, what tree should this go via ? I have further powerpc patches
depending on this one... so on one hand I'd be happy to take it, but
on the other hand, it's more likely to clash with other things...
Maybe I should check how it applies on top of linux-next.
Ben.
From: Dave Kleikamp <hidden> Date: 2008-07-08 13:35:53
On Tue, 2008-07-08 at 16:18 +1000, Benjamin Herrenschmidt wrote:
Andrew, what tree should this go via ? I have further powerpc patches
depending on this one... so on one hand I'd be happy to take it, but
on the other hand, it's more likely to clash with other things...