Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 07:18 AM, Aneesh Kumar K.V wrote: We should not return that address, unless we requested with a hint value of > 128TB. IIRC we discussed this early during the mmap interface change and said, we will return an address > 128T only if the hint address is above 128TB (not hint addr + le

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable, obvious rule. Avoids breaking apps that store some bits in the top of pointers (provided that memory allocator userspace libraries also do the right thing). So brk would simplify f

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer wrote: > On 11/06/2017 07:47 AM, Nicholas Piggin wrote: > > "You get < 128TB unless explicitly requested." > > > > Simple, reasonable, obvious rule. Avoids breaking apps that store > > some bits in the top of pointers (provided that memory allocat

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 01:55 PM, Nicholas Piggin wrote: On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer wrote: On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable, obvious rule. Avoids breaking apps that store some bits in the top of poi

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 09:30 AM, Aneesh Kumar K.V wrote: On 11/06/2017 01:55 PM, Nicholas Piggin wrote: On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer wrote: On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable, obvious rule. Avoids break

[PATCH v9 0/8] powerpc: Free up RPAGE_RSV bits

RPAGE_RSV0..4 PTE bits are currently used for HPTE slot tracking. We need these bits for memory-protection keys. Luckily these four bits are relatively easier to move among all the other candidate bits. For 64K linux-PTEs backed by 4k HPTEs, these bits are used for tracking the validity of the slo

[PATCH v9 1/8] powerpc: introduce pte_set_hidx() helper

Introduce pte_set_hidx().It sets the (H_PAGE_F_SECOND|H_PAGE_F_GIX) bits at the appropriate location in the PTE of 4K PTE. For 64K PTE, it sets the bits in the second part of the PTE. Though the implementation for the former just needs the slot parameter, it does take some additional parameters to

[PATCH v9 2/8] powerpc: introduce pte_get_hash_gslot() helper

Introduce pte_get_hash_gslot()() which returns the global slot number of the HPTE in the global hash table. This function will come in handy as we work towards re-arranging the PTE bits in the later patches. Reviewed-by: Aneesh Kumar K.V Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book

[PATCH v9 3/8] powerpc: Free up four 64K PTE bits in 4K backed HPTE pages

Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6, in the 4K backed HPTE pages.These bits continue to be used for 64K backed HPTE pages in this patch, but will be freed up in the next patch. The bit numbers are big-endian as defined in the ISA3.0 The patch does the following change to the 4k HT

[PATCH v9 4/8] powerpc: Free up four 64K PTE bits in 64K backed HPTE pages

Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6 in the 64K backed HPTE pages. This along with the earlier patch will entirely free up the four bits from 64K PTE. The bit numbers are big-endian as defined in the ISA3.0 This patch does the following change to 64K PTE backed by 64K HPTE. H_PAGE

[PATCH v9 5/8] powerpc: shifted-by-one hidx value

0xf is considered invalid hidx value. It indicates absence of a backing HPTE. A PTE is initialized to 0xf either a) when it is new it is newly allocated to hold 4k-backing-HPTE or b) Any time it gets demoted to a 4k-backing-HPTE This patch shifts the representation by one-modulo-0xf; i.e h

[PATCH v9 6/8] powerpc: Swizzle around 4K PTE bits to free up bit 5 and bit 6

We need PTE bits 3 ,4, 5, 6 and 57 to support protection-keys, because these are the bits we want to consolidate on across all configuration to support protection keys. Bit 3,4,5 and 6 are currently used on 4K-pte kernels. But bit 9 and 10 are available. Hence we use the two available bits and fre

[PATCH v9 7/8] powerpc: use helper functions to get and set hash slots

replace redundant code in __hash_page_4K() and flush_hash_page() with helper functions pte_get_hash_gslot() and pte_set_hidx() Reviewed-by: Aneesh Kumar K.V Signed-off-by: Ram Pai --- arch/powerpc/mm/hash64_4k.c | 14 ++ arch/powerpc/mm/hash_utils_64.c | 13 - 2

[PATCH v9 8/8] powerpc: capture the PTE format changes in the dump pte report

The H_PAGE_F_SECOND,H_PAGE_F_GIX are not in the 64K main-PTE. capture these changes in the dump pte report. Reviewed-by: Aneesh Kumar K.V Signed-off-by: Ram Pai --- arch/powerpc/mm/dump_linuxpagetables.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/mm/

[PATCH v9 00/51] powerpc, mm: Memory Protection Keys

Memory protection keys enable applications to protect its address space from inadvertent access from or corruption by itself. These patches along with the pte-bit freeing patch series enables the protection key feature on powerpc; 4k and 64k hashpage kernels. It also changes the generic and x86 co

[PATCH v9 01/51] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS is enabled. Powerpc also needs these bits. Hence lets define the VM_PKEY_BITx bits for any architecture that enables CONFIG_ARCH_HAS_PKEYS. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |4 ++-- include/linux/mm.h |

[PATCH v9 02/51] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

Currently only 4bits are allocated in the vma flags to hold 16 keys. This is sufficient for x86. PowerPC supports 32 keys, which needs 5bits. This patch allocates an additional bit. Acked-by: Balbir Singh Signed-off-by: Ram Pai --- fs/proc/task_mmu.c |1 + include/linux/mm.h |3 ++-

[PATCH v9 03/51] powerpc: initial pkey plumbing

Basic plumbing to initialize the pkey system. Nothing is enabled yet. A later patch will enable it ones all the infrastructure is in place. Signed-off-by: Ram Pai --- arch/powerpc/Kconfig | 15 arch/powerpc/include/asm/mmu_context.h |5 +++ arch/powerpc/i

[PATCH v9 04/51] powerpc: track allocation status of all pkeys

Total 32 keys are available on power7 and above. However pkey 0,1 are reserved. So effectively we have 30 pkeys. On 4K kernels, we do not have 5 bits in the PTE to represent all the keys; we only have 3bits.Two of those keys are reserved; pkey 0 and pkey 1. So effectively we have 6 pkeys

[PATCH v9 05/51] powerpc: helper function to read, write AMR, IAMR, UAMOR registers

Implements helper functions to read and write the key related registers; AMR, IAMR, UAMOR. AMR register tracks the read,write permission of a key IAMR register tracks the execute permission of a key UAMOR register enables and disables a key Acked-by: Balbir Singh Reviewed-by: Thiago Jung Bauerma

[PATCH v9 06/51] powerpc: helper functions to initialize AMR, IAMR and UAMOR registers

Introduce helper functions that can initialize the bits in the AMR, IAMR and UAMOR register; the bits that correspond to the given pkey. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- arch/powerpc/mm/pkeys.c | 47 +++ 1 files changed

[PATCH v9 07/51] powerpc: cleanup AMR, IAMR when a key is allocated or freed

Cleanup the bits corresponding to a key in the AMR, and IAMR register, when the key is newly allocated/activated or is freed. We dont want some residual bits cause the hardware enforce unintended behavior when the key is activated or freed. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pa

[PATCH v9 08/51] powerpc: implementation for arch_set_user_pkey_access()

This patch provides the detailed implementation for a user to allocate a key and enable it in the hardware. It provides the plumbing, but it cannot be used till the system call is implemented. The next patch will do so. Reviewed-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- arch/powerp

[PATCH v9 09/51] powerpc: ability to create execute-disabled pkeys

powerpc has hardware support to disable execute on a pkey. This patch enables the ability to create execute-disabled keys. Signed-off-by: Ram Pai --- arch/powerpc/include/uapi/asm/mman.h |6 ++ arch/powerpc/mm/pkeys.c | 16 2 files changed, 22 insertions(+

[PATCH v9 10/51] powerpc: store and restore the pkey state across context switches

Store and restore the AMR, IAMR and UAMOR register state of the task before scheduling out and after scheduling in, respectively. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |3 ++ arch/powerpc/include/asm/pkeys.h |4 ++ arch/powerpc/include/asm/processor.h

[PATCH v9 11/51] powerpc: introduce execute-only pkey

This patch provides the implementation of execute-only pkey. The architecture-independent layer expects the arch-dependent layer, to support the ability to create and enable a special key which has execute-only permission. Acked-by: Balbir Singh Signed-off-by: Ram Pai --- arch/powerpc/include/a

[PATCH v9 12/51] powerpc: ability to associate pkey to a vma

arch-independent code expects the arch to map a pkey into the vma's protection bit setting. The patch provides that ability. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mman.h |7 ++- arch/powerpc/include/asm/pkeys.h | 11 +++ arch/powerpc/mm/pkeys.c |8

[PATCH v9 13/51] powerpc: implementation for arch_override_mprotect_pkey()

arch independent code calls arch_override_mprotect_pkey() to return a pkey that best matches the requested protection. This patch provides the implementation. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |5 arch/powerpc/include/asm/pkeys.h | 21 +++

[PATCH v9 14/51] powerpc: map vma key-protection bits to pte key bits.

Map the key protection bits of the vma to the pkey bits in the PTE. The PTE bits used for pkey are 3,4,5,6 and 57. The first four bits are the same four bits that were freed up initially in this patch series. remember? :-) Without those four bits this patch wouldn't be possible. BUT, o

[PATCH v9 15/51] powerpc: Program HPTE key protection bits

Map the PTE protection key bits to the HPTE key protection bits, while creating HPTE entries. Acked-by: Balbir Singh Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/mmu-hash.h |5 + arch/powerpc/include/asm/mmu_context.h|6 ++ arch/powerpc/include/asm/pkey

[PATCH v9 16/51] powerpc: helper to validate key-access permissions of a pte

helper function that checks if the read/write/execute is allowed on the pte. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h |4 +++ arch/powerpc/include/asm/pkeys.h |9 arch/powerpc/mm/pkeys.c | 28 +

[PATCH v9 17/51] powerpc: check key protection for user page access

Make sure that the kernel does not access user pages without checking their key-protection. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h

[PATCH v9 18/51] powerpc: implementation for arch_vma_access_permitted()

This patch provides the implementation for arch_vma_access_permitted(). Returns true if the requested access is allowed by pkey associated with the vma. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h |5 +++- arch/powerpc/mm/pkeys.c| 34 ++

[PATCH v9 19/51] powerpc: Handle exceptions caused by pkey violation

Handle Data and Instruction exceptions caused by memory protection-key. The CPU will detect the key fault if the HPTE is already programmed with the key. However if the HPTE is not hashed, a key fault will not be detected by the hardware. The software will detect pkey violation in such a case.

[PATCH v9 20/51] powerpc: introduce get_mm_addr_key() helper

get_mm_addr_key() helper returns the pkey associated with an address corresponding to a given mm_struct. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu.h |9 + arch/powerpc/mm/hash_utils_64.c | 24 2 files changed, 33 insertions(+), 0 deletions(-)

[PATCH v9 21/51] powerpc: Deliver SEGV signal on pkey violation

The value of the pkey, whose protection got violated, is made available in si_pkey field of the siginfo structure. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/bug.h |1 + arch/powerpc/kernel/traps.c| 12 - arch/powerpc/mm/fault.c| 55 ++

[PATCH v9 22/51] powerpc/ptrace: Add memory protection key regset

From: Thiago Jung Bauermann The AMR/IAMR/UAMOR are part of the program context. Allow it to be accessed via ptrace and through core files. Signed-off-by: Ram Pai Signed-off-by: Thiago Jung Bauermann --- arch/powerpc/include/asm/pkeys.h|5 +++ arch/powerpc/include/uapi/asm/elf.h |1

[PATCH v9 23/51] powerpc: Enable pkey subsystem

PAPR defines 'ibm,processor-storage-keys' property. It exports two values. The first value holds the number of data-access keys and the second holds the number of instruction-access keys. Due to a bug in the firmware, instruction-access keys is always reported as zero. However any key can be

[PATCH v9 24/51] powerpc: sys_pkey_alloc() and sys_pkey_free() system calls

Finally this patch provides the ability for a process to allocate and free a protection key. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/systbl.h |2 ++ arch/powerpc/include/asm/unistd.h |4 +--- arch/powerpc/include/uapi/asm/unistd.h |2 ++ 3 files changed, 5 inser

[PATCH v9 25/51] powerpc: sys_pkey_mprotect() system call

Patch provides the ability for a process to associate a pkey with a address range. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/systbl.h |1 + arch/powerpc/include/asm/unistd.h |4 +--- arch/powerpc/include/uapi/asm/unistd.h |1 + 3 files changed, 3 insertions(+), 3

[PATCH v9 26/51] powerpc: add sys_pkey_modify() system call

sys_pkey_modify() is powerpc specific system call. It enables the ability to modify *any* attribute of a key. Since powerpc disallows modification of IAMR from user space an application is unable to change a key's execute-attribute. This system call helps accomplish the above. Signed-off

[PATCH v9 27/51] mm, x86 : introduce arch_pkeys_enabled()

Arch neutral code needs to know if the architecture supports protection keys to display protection key in smaps. Hence introducing arch_pkeys_enabled(). This patch also provides x86 implementation for arch_pkeys_enabled(). Signed-off-by: Ram Pai --- arch/x86/include/asm/pkeys.h |1 + arc

[PATCH v9 28/51] mm: display pkey in smaps if arch_pkeys_enabled() is true

Currently the architecture specific code is expected to display the protection keys in smap for a given vma. This can lead to redundant code and possibly to divergent formats in which the key gets displayed. This patch changes the implementation. It displays the pkey only if the archite

[PATCH v9 29/51] mm/mprotect, powerpc/mm/pkeys, x86/mm/pkeys: Add sysfs interface

From: Thiago Jung Bauermann Expose useful information for programs using memory protection keys. Provide implementation for powerpc and x86. On a powerpc system with pkeys support, here is what is shown: $ head /sys/kernel/mm/protection_keys/* ==> /sys/kernel/mm/protection_keys/disable_access_s

[PATCH v9 30/51] Documentation/x86: Move protecton key documentation to arch neutral directory

Since PowerPC and Intel both support memory protection keys, moving the documenation to arch-neutral directory. Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 85 + Documentation/x86/protection-keys.txt | 85

[PATCH v9 31/51] Documentation/vm: PowerPC specific updates to memory protection keys

Add documentation updates that capture PowerPC specific changes. Signed-off-by: Thiago Jung Bauermann Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 126 +++--- 1 files changed, 101 insertions(+), 25 deletions(-) diff --git a/Documentation/vm/pro

[PATCH v9 32/51] selftest/x86: Move protecton key selftest to arch neutral directory

Signed-off-by: Ram Pai --- tools/testing/selftests/vm/Makefile |1 + tools/testing/selftests/vm/pkey-helpers.h | 220 tools/testing/selftests/vm/protection_keys.c | 1395 + tools/testing/selftests/x86/Makefile |2 +- tools/testing/self

[PATCH v9 33/51] selftest/vm: rename all references to pkru to a generic name

some pkru references are named to pkey_reg and some prku references are renamed to pkey Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers.h| 85 +- tools/testing/selftests/vm/protection_keys.c | 227 ++ 2 files changed, 164 insertions(+), 1

[PATCH v9 34/51] selftest/vm: move generic definitions to header file

Moved all the generic definition and helper functions to the header file Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers.h| 62 +++-- tools/testing/selftests/vm/protection_keys.c | 54 -- 2 files changed, 57 insertions(+), 59 del

[PATCH v9 35/51] selftest/vm: typecast the pkey register

This is in preparation to accomadate a differing size register across architectures. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers.h| 27 +- tools/testing/selftests/vm/protection_keys.c | 71 ++ 2 files changed, 52 insertions(+), 46 de

[PATCH v9 36/51] selftest/vm: generic function to handle shadow key register

helper functions to handler shadow pkey register Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers.h| 27 tools/testing/selftests/vm/protection_keys.c | 34 - 2 files changed, 49 insertions(+), 12 deletions(-) diff --git a/to

[PATCH v9 37/51] selftest/vm: fix the wrong assert in pkey_disable_set()

If the flag is 0, no bits will be set. Hence we cant expect the resulting bitmap to have a higher value than what it was earlier. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/testing/selfte

[PATCH v9 38/51] selftest/vm: fixed bugs in pkey_disable_clear()

instead of clearing the bits, pkey_disable_clear() was setting the bits. Fixed it. Also fixed a wrong assertion in that function. When bits are cleared, the resulting bit value will be less than the original. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c |4 ++-- 1

[PATCH v9 39/51] selftest/vm: clear the bits in shadow reg when a pkey is freed.

When a key is freed, the key is no more effective. Clear the bits corresponding to the pkey in the shadow register. Otherwise it will carry some spurious bits which can trigger false-positive asserts. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c |3 +++ 1 fi

[PATCH v9 40/51] selftest/vm: fix alloc_random_pkey() to make it really random

alloc_random_pkey() was allocating the same pkey every time. Not all pkeys were geting tested. fixed it. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c | 10 +++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/vm/protection

[PATCH v9 41/51] selftest/vm: introduce two arch independent abstraction

open_hugepage_file() <- opens the huge page file get_start_key() <-- provides the first non-reserved key. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers.h| 11 +++ tools/testing/selftests/vm/protection_keys.c |6 +++--- 2 files changed, 14 insertions(+), 3

[PATCH v9 42/51] selftest/vm: pkey register should match shadow pkey

expected_pkey_fault() is comparing the contents of pkey register with 0. This may not be true all the time. There could be bits set by default by the architecture which can never be changed. Hence compare the value against shadow pkey register, which is supposed to track the bits accurately all thr

[PATCH v9 43/51] selftest/vm: generic cleanup

cleanup the code to satisfy coding styles. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c | 81 ++ 1 files changed, 43 insertions(+), 38 deletions(-) diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protec

[PATCH v9 44/51] selftest/vm: powerpc implementation for generic abstraction

Introduce powerpc implementation for the different abstactions. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers.h| 109 ++ tools/testing/selftests/vm/protection_keys.c | 38 ++ 2 files changed, 117 insertions(+), 30 deletions(-) diff --g

[PATCH v9 45/51] selftest/vm: fix an assertion in test_pkey_alloc_exhaust()

The maximum number of keys that can be allocated has to take into consideration, that some keys are reserved by the architecture for specific purpose. Hence cannot be allocated. Fix the assertion in test_pkey_alloc_exhaust() Signed-off-by: Ram Pai --- tools/testing/selftests/vm/pkey-helpers

[PATCH v9 46/51] selftest/vm: associate key on a mapped page and detect access violation

detect access-violation on a page to which access-disabled key is associated much after the page is mapped. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c | 19 +++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/tools/testing/selftests/

[PATCH v9 47/51] selftest/vm: associate key on a mapped page and detect write violation

detect write-violation on a page to which write-disabled key is associated much after the page is mapped. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/tools/testing/selftests/vm/protec

[PATCH v9 48/51] selftest/vm: detect write violation on a mapped access-denied-key page

detect write-violation on a page to which access-disabled key is associated much after the page is mapped. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c | 13 + 1 files changed, 13 insertions(+), 0 deletions(-) diff --git a/tools/testing/selftests/vm/prot

[PATCH v9 49/51] selftest/vm: sub-page allocator

introduce a new allocator that allocates 4k hardware-pages to back 64k linux-page. This allocator is only applicable on powerpc. Signed-off-by: Ram Pai --- tools/testing/selftests/vm/protection_keys.c | 30 ++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --gi

[PATCH v9 50/51] selftests/powerpc: Add ptrace tests for Protection Key register

From: Thiago Jung Bauermann This test exercises read and write access to the AMR. Signed-off-by: Thiago Jung Bauermann --- tools/testing/selftests/powerpc/include/reg.h |1 + tools/testing/selftests/powerpc/ptrace/Makefile|5 +- .../testing/selftests/powerpc/ptrace/ptrace-pkey

[PATCH v9 51/51] selftests/powerpc: Add core file test for Protection Key register

From: Thiago Jung Bauermann This test verifies that the AMR is being written to a process' core file. Signed-off-by: Thiago Jung Bauermann --- tools/testing/selftests/powerpc/ptrace/Makefile|2 +- tools/testing/selftests/powerpc/ptrace/core-pkey.c | 438 2 files c

Re: [PATCH v5 06/10] powerpc/opal: Rework the opal-async interface

Cyril Bur writes: > diff --git a/arch/powerpc/platforms/powernv/opal-async.c > b/arch/powerpc/platforms/powernv/opal-async.c > index c43421ab2d2f..fbae8a37ce2c 100644 > --- a/arch/powerpc/platforms/powernv/opal-async.c > +++ b/arch/powerpc/platforms/powernv/opal-async.c > @@ -23,40 +23,45 @@ >

Re: [PATCH v5 07/22] mm: Protect VMA modifications using VMA sequence count

Hi Andrea, On 02/11/2017 21:08, Andrea Arcangeli wrote: > On Thu, Nov 02, 2017 at 06:25:11PM +0100, Laurent Dufour wrote: >> I think there is some memory barrier missing when the VMA is modified so >> currently the modifications done in the VMA structure may not be written >> down at the time the

[PATCH 0/5] VA allocator fixes

Florian found a nasty corner case with the VA allocation logic for crossing from 128TB to 512TB limit on hash, and made a really superb report of the problem -- traces, reproducer recipes, analysis, etc. which already mostly solved it. The first patch in the series should solve Florian's particula

[PATCH 1/5] powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation

When allocating VA space with a hint that crosses 128TB, the SLB addr_limit variable is not expanded if addr is not > 128TB, but the slice allocation looks at task_size, which is 512TB. This results in slice_check_fit() incorrectly succeeding because the slice_count truncates off bit 128 of the req

[PATCH 2/5] powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary

While mapping hints with a length that cross 128TB are disallowed, MAP_FIXED allocations that cross 128TB are allowed. These are failing on hash (on radix they succeed). Add an additional case for fixed mappings to expand the addr_limit when crossing 128TB. Cc: "Aneesh Kumar K.V" Fixes: f4ea6dcb0

[PATCH 3/5] powerpc/64s/hash: Fix fork() with 512TB process address space

Hash unconditionally resets the addr_limit to default (128TB) when the mm context is initialised. If a process has > 128TB mappings when it forks, the child will not get the 512TB addr_limit, so accesses to valid > 128TB mappings will fail in the child. Fix this by only resetting the addr_limit to

[PATCH 4/5] powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation

Radix VA space allocations test addresses against mm->task_size which is 512TB, even in cases where the intention is to limit allocation to below 128TB. This results in mmap with a hint address below 128TB but address + length above 128TB succeeding when it should fail (as hash does after the prev

[PATCH 5/5] powerpc/64s: mm_context.addr_limit is only used on hash

Radix keeps no meaningful state in addr_limit, so remove it from radix code and rename to slb_addr_limit to make it clear it applies to hash only. Signed-off-by: Nicholas Piggin --- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 2 +- arch/powerpc/include/asm/book3s/64/mmu.h | 2 +- arch

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Mon, 6 Nov 2017 09:32:25 +0100 Florian Weimer wrote: > On 11/06/2017 09:30 AM, Aneesh Kumar K.V wrote: > > On 11/06/2017 01:55 PM, Nicholas Piggin wrote: > >> On Mon, 6 Nov 2017 09:11:37 +0100 > >> Florian Weimer wrote: > >> > >>> On 11/06/2017 07:47 AM, Nicholas Piggin wrote: > "Y

Re: [v5,22/22] powerpc/mm: Add speculative page fault

On (11/02/17 15:11), Laurent Dufour wrote: > On 26/10/2017 10:14, kemi wrote: > > Some regression is found by LKP-tools(linux kernel performance) on this > > patch series > > tested on Intel 2s/4s Skylake platform. > > The regression result is sorted by the metric will-it-scale.per_process_ops. >

RE: [PATCH] [net-next,v2] ibmvnic: Feature implementation of Vital Product Data (VPD) for the ibmvnic driver

From: David Miller > Sent: 04 November 2017 13:21 > From: Desnes Augusto Nunes do Rosario > Date: Wed, 1 Nov 2017 19:03:32 -0200 > > > + substr = strnstr(adapter->vpd->buff, "RM", adapter->vpd->len); > > + if (!substr) { > > + dev_info(dev, "No FW level provided by VPD\n"); > > +

Re: [PATCH] powerpc/opal: Fix EBUSY bug in acquiring tokens

William Kennington writes: >> On Nov 4, 2017, at 2:14 AM, Michael Ellerman > > wrote: >> >> "William A. Kennington III" mailto:w...@google.com>> >> writes: >> >>> The current code checks the completion map to look for the first token >>> that is complete. In some ca

Re: [PATCH 1/5] powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation

Nicholas Piggin writes: > When allocating VA space with a hint that crosses 128TB, the SLB addr_limit > variable is not expanded if addr is not > 128TB, but the slice allocation > looks at task_size, which is 512TB. This results in slice_check_fit() > incorrectly succeeding because the slice_coun

Re: powerpc/perf: Fix a sizeof() typo so we allocate less memory

Dan Carpenter writes: > We're allocating the size of the struct which is 32 bytes when we should > be allocating sizeof(void *) which is 4 or 8 bytes depending on the > architecture. > > Fixes: 885dcd709ba9 ("powerpc/perf: Add nest IMC PMU support") > Signed-off-by: Dan Carpenter Thanks. I thi

Re: [PATCH 2/5] powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary

Nicholas Piggin writes: > While mapping hints with a length that cross 128TB are disallowed, > MAP_FIXED allocations that cross 128TB are allowed. These are failing > on hash (on radix they succeed). Add an additional case for fixed > mappings to expand the addr_limit when crossing 128TB. Should

Re: [PATCH kernel] powerpc/powernv/ioda: Relax max DMA window size check

Alexey Kardashevskiy writes: > On 31/10/17 15:04, Alexey Kardashevskiy wrote: >> DMA windows can only have a size of power of two on IODA2 hardware and >> using memory_hotplug_max() to determine the upper limit won't work >> correcly if it returns not power of two value. >> >> This relaxes the c

Re: [PATCH 3/5] powerpc/64s/hash: Fix fork() with 512TB process address space

Nicholas Piggin writes: > Hash unconditionally resets the addr_limit to default (128TB) when > the mm context is initialised. If a process has > 128TB mappings when > it forks, the child will not get the 512TB addr_limit, so accesses to > valid > 128TB mappings will fail in the child. > > Fix thi

Re: [PATCH 1/5] powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation

On Mon, 06 Nov 2017 16:08:06 +0530 "Aneesh Kumar K.V" wrote: > Nicholas Piggin writes: > > > When allocating VA space with a hint that crosses 128TB, the SLB addr_limit > > variable is not expanded if addr is not > 128TB, but the slice allocation > > looks at task_size, which is 512TB. This res

Re: [PATCH 1/5] powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation

On 11/06/2017 04:24 PM, Nicholas Piggin wrote: On Mon, 06 Nov 2017 16:08:06 +0530 "Aneesh Kumar K.V" wrote: Nicholas Piggin writes: When allocating VA space with a hint that crosses 128TB, the SLB addr_limit variable is not expanded if addr is not > 128TB, but the slice allocation looks a

Re: [PATCH 4/5] powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation

Nicholas Piggin writes: > Radix VA space allocations test addresses against mm->task_size which is > 512TB, even in cases where the intention is to limit allocation to below > 128TB. > > This results in mmap with a hint address below 128TB but address + length > above 128TB succeeding when it sho

Re: [PATCH v3 1/2] livepatch: send a fake signal to all blocking tasks

Hi! > --- a/Documentation/ABI/testing/sysfs-kernel-livepatch > +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch > @@ -33,6 +33,15 @@ Contact: live-patch...@vger.kernel.org > An attribute which indicates whether the patch is currently in > transition. > > +What

Re: [PATCH 1/5] powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation

On Mon, 6 Nov 2017 16:35:43 +0530 "Aneesh Kumar K.V" wrote: > On 11/06/2017 04:24 PM, Nicholas Piggin wrote: > > On Mon, 06 Nov 2017 16:08:06 +0530 > > "Aneesh Kumar K.V" wrote: > > > >> Nicholas Piggin writes: > >> > >>> When allocating VA space with a hint that crosses 128TB, the SLB >

Re: [PATCH 4/5] powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation

On Mon, 06 Nov 2017 16:44:48 +0530 "Aneesh Kumar K.V" wrote: > Nicholas Piggin writes: > > > Radix VA space allocations test addresses against mm->task_size which is > > 512TB, even in cases where the intention is to limit allocation to below > > 128TB. > > > > This results in mmap with a hint

Re: [PATCH 2/5] powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary

On Mon, 06 Nov 2017 16:14:10 +0530 "Aneesh Kumar K.V" wrote: > Nicholas Piggin writes: > > > While mapping hints with a length that cross 128TB are disallowed, > > MAP_FIXED allocations that cross 128TB are allowed. These are failing > > on hash (on radix they succeed). Add an additional case f

[PATCH] powerpc/mm: Remove unused flag arg in global_invalidates

Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/kvm/book3s_hv_rm_mmu.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c index 4efe364f1188..d80240ba6de4 100644 --- a/arch/powerpc/kvm/book3s_hv_

Re: [PATCH 0/5] VA allocator fixes

On 11/06/2017 11:03 AM, Nicholas Piggin wrote: Florian found a nasty corner case with the VA allocation logic for crossing from 128TB to 512TB limit on hash, and made a really superb report of the problem -- traces, reproducer recipes, analysis, etc. which already mostly solved it. The first pat

[PATCH v3] ppc64 boot: Wait for boot cpu to show up if nr_cpus limit is about to hit.

From: Mahesh Salgaonkar The kernel boot parameter 'nr_cpus=' allows one to specify number of possible cpus in the system. In the normal scenario the first cpu (cpu0) that shows up is the boot cpu and hence it gets covered under nr_cpus limit. But this assumption will be broken in kdump scenario

Re: [PATCH kernel] powerpc/powernv/ioda: Relax max DMA window size check

Michael Ellerman wrote on 11/06/2017 11:45:34 AM: > From: Michael Ellerman > To: Alexey Kardashevskiy , David Gibson > > Cc: linuxppc-dev@lists.ozlabs.org, Jonas Pfefferle1 > , Nicholas Piggin > Date: 11/06/2017 11:45 AM > Subject: Re: [PATCH kernel] powerpc/powernv/ioda: Relax max DMA > wind

[RFC PATCH for 4.15 06/14] Restartable sequences: powerpc architecture support

From: Boqun Feng Call the rseq_handle_notify_resume() function on return to userspace if TIF_NOTIFY_RESUME thread flag is set. Increment the event counter and perform fixup on the pre-signal when a signal is delivered on top of a restartable sequence critical section. Signed-off-by: Boqun Feng

[RFC PATCH for 4.15 10/14] cpu_opv: Wire up powerpc system call

Signed-off-by: Mathieu Desnoyers CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Michael Ellerman CC: Boqun Feng CC: Peter Zijlstra CC: "Paul E. McKenney" CC: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arc

[RFC PATCH for 4.15 07/14] Restartable sequences: Wire up powerpc system call

From: Boqun Feng Wire up the rseq system call on powerpc. This provides an ABI improving the speed of a user-space getcpu operation on powerpc by skipping the getcpu system call on the fast path, as well as improving the speed of user-space operations on per-cpu data compared to using load-reser

Re: [PATCH v9 00/51] powerpc, mm: Memory Protection Keys

* Ram Pai: > Testing: > --- > This patch series has passed all the protection key > tests available in the selftest directory.The > tests are updated to work on both x86 and powerpc. > The selftests have passed on x86 and powerpc hardware. How do you deal with the key reuse problem? Is it th

Re: [PATCH v5 06/10] powerpc/opal: Rework the opal-async interface

On Mon, 2017-11-06 at 20:41 +1100, Michael Ellerman wrote: > Cyril Bur writes: > > > diff --git a/arch/powerpc/platforms/powernv/opal-async.c > > b/arch/powerpc/platforms/powernv/opal-async.c > > index c43421ab2d2f..fbae8a37ce2c 100644 > > --- a/arch/powerpc/platforms/powernv/opal-async.c > > ++

Re: [PATCH 0/5] VA allocator fixes

On Mon, 6 Nov 2017 16:16:07 +0100 Florian Weimer wrote: > On 11/06/2017 11:03 AM, Nicholas Piggin wrote: > > Florian found a nasty corner case with the VA allocation logic > > for crossing from 128TB to 512TB limit on hash, and made a > > really superb report of the problem -- traces, reproducer

  1   2   >