[RFC v3 01/23] 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

[RFC v3 07/23] powerpc: use helper functions in __hash_page_4K() for 4K PTE

replace redundant code with helper functions get_hidx_gslot() and set_hidx_slot() Signed-off-by: Ram Pai --- arch/powerpc/mm/hash64_4k.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/mm/hash64_4k.c

[RFC v3 03/23] powerpc: introduce get_hidx_gslot helper

Introduce get_hidx_gslot() which returns the 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. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/hash.h | 3 +++

[RFC v3 05/23] 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. Signed-off-by: Ram Pai --- arch/powerpc/mm/dump_linuxpagetables.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[RFC v3 10/23] mm: provide the ability to disable execute on a key at creation

Currently sys_pkey_create() provides the ability to disable read and write permission on the key, at creation. powerpc has the hardware support to disable execute on a pkey as well.This patch enhances the interface to let disable execute at key creation time. x86 does not allow this.

[RFC v3 08/23] powerpc: use helper functions in flush_hash_page()

replace redundant code in flush_hash_page() with helper functions get_hidx_gslot() and set_hidx_slot() Signed-off-by: Ram Pai --- arch/powerpc/mm/hash_utils_64.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git

[RFC v3 11/23] x86: key creation with PKEY_DISABLE_EXECUTE is disallowed

x86 does not support disabling execute permissions on a pkey. Signed-off-by: Ram Pai --- arch/x86/kernel/fpu/xstate.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index c24ac1e..d582631 100644 ---

[RFC v3 09/23] mm: introduce an additional vma bit for powerpc pkey

Currently there are only 4bits in the vma flags to support 16 keys on x86. powerpc supports 32 keys, which needs 5bits. This patch introduces an addition bit in the vma flags. Signed-off-by: Ram Pai --- fs/proc/task_mmu.c | 6 +- include/linux/mm.h | 18

[RFC v3 12/23] powerpc: Implement sys_pkey_alloc and sys_pkey_free system call

Sys_pkey_alloc() allocates and returns available pkey Sys_pkey_free() frees up the pkey. Total 32 keys are supported on powerpc. However pkey 0,1 and 31 are reserved. So effectively we have 29 pkeys. Each key can be initialized to disable read, write and execute permissions. On powerpc a

[RFC v3 13/23] powerpc: store and restore the pkey state across context switches

Store and restore the AMR, IAMR and UMOR register state of the task before scheduling out and after scheduling in, respectively. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/processor.h | 5 + arch/powerpc/kernel/process.c| 18 ++ 2 files

[RFC v3 14/23] powerpc: Implementation for sys_mprotect_pkey() system call

This system call, associates the pkey with PTE of all pages covering the given address range. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/pgtable.h | 22 ++- arch/powerpc/include/asm/mman.h | 14 - arch/powerpc/include/asm/pkeys.h

[RFC v3 18/23] powerpc: Deliver SEGV signal on pkey violation

The value of the AMR register at the time of exception is made available in gp_regs[PT_AMR] of the siginfo. This field can be used to reprogram the permission bits of any valid pkey. Similarly the value of the pkey, whose protection got violated, is made available at si_pkey field of the siginfo

[RFC v3 16/23] powerpc: Macro the mask used for checking DSI exception

Replace the magic number used to check for DSI exception with a meaningful value. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/reg.h | 7 ++- arch/powerpc/kernel/exceptions-64s.S | 2 +- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git

[RFC v3 15/23] powerpc: Program HPTE key protection bits

Map the PTE protection key bits to the HPTE key protection bits, while creating HPTE entries. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/book3s/64/mmu-hash.h | 5 + arch/powerpc/include/asm/pkeys.h | 7 +++ arch/powerpc/mm/hash_utils_64.c

[RFC v3 20/23] selftest: PowerPC specific test updates to memory protection keys

Abstracted out the arch specific code into the header file, and added powerpc specific changes. a) added 4k-backed hpte, memory allocator, powerpc specific. b) added three test case where the key is associated after the page is accessed/allocated/mapped. c) cleaned up the code to make

[RFC v3 19/23] selftest: 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 | 219 tools/testing/selftests/vm/protection_keys.c | 1395 + tools/testing/selftests/x86/Makefile |2

[RFC v3 21/23] Documentation: 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

[RFC v3 22/23] Documentation: PowerPC specific updates to memory protection keys

Add documentation updates that capture PowerPC specific changes. Signed-off-by: Ram Pai --- Documentation/vm/protection-keys.txt | 65 +--- 1 file changed, 45 insertions(+), 20 deletions(-) diff --git a/Documentation/vm/protection-keys.txt

[RFC v3 23/23] procfs: display the protection-key number associated with a vma

Display the pkey number associated with the vma in smaps of a task. The key will be seen as below: VmFlags: rd wr mr mw me dw ac key=0 Signed-off-by: Ram Pai --- Documentation/filesystems/proc.txt | 3 ++- fs/proc/task_mmu.c | 22 +++--- 2

[RFC v3 17/23] powerpc: Handle exceptions caused by violation of pkey protection

Handle Data and Instruction exceptions caused by memory protection-key. Signed-off-by: Ram Pai --- arch/powerpc/include/asm/mmu_context.h | 12 + arch/powerpc/include/asm/pkeys.h | 9 arch/powerpc/include/asm/reg.h | 2 +- arch/powerpc/mm/fault.c

[RFC v3 00/23] powerpc: Memory Protection Keys

Memory protection keys enable applications to protect its address space from inadvertent access or corruption from itself. The overall idea: A process allocates a key and associates it with a address range withinits address space. The process than can dynamically set

Re: [PATCH] kbuild: replace genhdr-y with generated-y, deprecating genhdr-y

2017-06-09 17:29 GMT+09:00 Masahiro Yamada : > Prior to commit fcc8487d477a ("uapi: export all headers under uapi > directories"), genhdr-y was meant to specify generated UAPI headers. > > - generated-y: generated headers (other than asm-generic wrappers) > -

[v3 5/6] mm, oom: don't mark all oom victims tasks with TIF_MEMDIE

We want to limit the number of tasks which are having an access to the memory reserves. To ensure the progress it's enough to have one such process at the time. If we need to kill the whole cgroup, let's give an access to the memory reserves only to the first process in the list, which is

[v3 3/6] mm, oom: cgroup-aware OOM killer debug info

Dump the cgroup oom badness score, as well as the name of chosen victim cgroup. Here how it looks like in dmesg: [ 18.824495] Choosing a victim memcg because of the system-wide OOM [ 18.826911] Cgroup /A1: 200805 [ 18.827996] Cgroup /A2: 273072 [ 18.828937] Cgroup /A2/B3: 51 [

[v3 1/6] mm, oom: use oom_victims counter to synchronize oom victim selection

Oom killer should avoid unnecessary kills. To prevent them, during the tasks list traverse we check for task which was previously selected as oom victims. If there is such a task, new victim is not selected. This approach is sub-optimal (we're doing costly iteration over the task list every time)

[v3 6/6] mm,oom,docs: describe the cgroup-aware OOM killer

Update cgroups v2 docs. Signed-off-by: Roman Gushchin Cc: Michal Hocko Cc: Vladimir Davydov Cc: Johannes Weiner Cc: Tetsuo Handa Cc: David Rientjes Cc: Tejun

[v3 4/6] mm, oom: introduce oom_score_adj for memory cgroups

Introduce a per-memory-cgroup oom_score_adj setting. A read-write single value file which exits on non-root cgroups. The default is "0". It will have a similar meaning to a per-process value, available via /proc//oom_score_adj. Should be in a range [-1000, 1000]. Signed-off-by: Roman Gushchin

[v3 2/6] mm, oom: cgroup-aware OOM killer

Traditionally, the OOM killer is operating on a process level. Under oom conditions, it finds a process with the highest oom score and kills it. This behavior doesn't suit well the system with many running containers. There are two main issues: 1) There is no fairness between containers. A small

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On 6/21/2017 10:38 AM, Thomas Gleixner wrote: On Wed, 21 Jun 2017, Tom Lendacky wrote: On 6/21/2017 2:16 AM, Thomas Gleixner wrote: Why is this an unconditional function? Isn't the mask simply 0 when the MEM ENCRYPT support is disabled? I made it unconditional because of the call from

Re: [PATCH v6 26/34] iommu/amd: Allow the AMD IOMMU to work with memory encryption

On Wed, Jun 21, 2017 at 05:37:22PM +0200, Joerg Roedel wrote: > > Do you mean this is like the last exception case in that document above: > > > > " > > - Pointers to data structures in coherent memory which might be modified > > by I/O devices can, sometimes, legitimately be volatile. A

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Wed, 21 Jun 2017, Tom Lendacky wrote: > On 6/21/2017 2:16 AM, Thomas Gleixner wrote: > > Why is this an unconditional function? Isn't the mask simply 0 when the MEM > > ENCRYPT support is disabled? > > I made it unconditional because of the call from head_64.S. I can't make > use of the C

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On 6/21/2017 2:16 AM, Thomas Gleixner wrote: On Fri, 16 Jun 2017, Tom Lendacky wrote: diff --git a/arch/x86/include/asm/mem_encrypt.h b/arch/x86/include/asm/mem_encrypt.h index a105796..988b336 100644 --- a/arch/x86/include/asm/mem_encrypt.h +++ b/arch/x86/include/asm/mem_encrypt.h @@ -15,16

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On 6/21/2017 2:37 AM, Thomas Gleixner wrote: On Fri, 16 Jun 2017, Tom Lendacky wrote: Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is then phys_to_virt() is used to perform the mapping. When SME is active, however, this will result in

Re: [PATCH v7 07/36] x86/mm: Don't use phys_to_virt in ioremap() if SME is active

On 6/20/2017 3:55 PM, Thomas Gleixner wrote: On Fri, 16 Jun 2017, Tom Lendacky wrote: Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it is then phys_to_virt() is used to perform the mapping. When SME is active, however, this will result in

Fw: [PATCH v4 3/5] input: add a EV_SW event for ratchet switch

Hi Dmitry, Ping. How do you want to proceed with that? Regards, Mauro Forwarded message: Date: Sat, 15 Apr 2017 19:50:45 -0300 From: Mauro Carvalho Chehab To: Dmitry Torokhov Cc: linux-in...@vger.kernel.org, Benjamin Tissoires

Re: [PATCH v7 06/36] x86/mm: Add Secure Memory Encryption (SME) support

On 6/20/2017 3:49 PM, Thomas Gleixner wrote: On Fri, 16 Jun 2017, Tom Lendacky wrote: +config ARCH_HAS_MEM_ENCRYPT + def_bool y + depends on X86 That one is silly. The config switch is in the x86 KConfig file, so X86 is on. If you intended to move this to some generic place

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

On 31/05/17 17:06, Bartosz Golaszewski wrote: > This series is a follow-up to [1]. > > Some users of irq_alloc_generic_chip() are modules which can be > removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated > generic chip. > > Last time it was suggested to provide

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

2017-06-20 16:14 GMT+02:00 Thomas Gleixner : > On Tue, 20 Jun 2017, Bartosz Golaszewski wrote: >> 2017-06-20 12:41 GMT+02:00 Marc Zyngier : >> > There was a kbuild report from June 1st with worrying warnings on x86_64 >> > (though I couldn't see how that

Re: [PATCH v7 23/36] x86, realmode: Decrypt trampoline area if memory encryption is active

On Fri, Jun 16, 2017 at 01:54:12PM -0500, Tom Lendacky wrote: > When Secure Memory Encryption is enabled, the trampoline area must not > be encrypted. A CPU running in real mode will not be able to decrypt > memory that has been encrypted because it will not be able to use addresses > with the

Re: [PATCH v7 10/36] x86/mm: Provide general kernel support for memory encryption

On Wed, Jun 21, 2017 at 09:18:59AM +0200, Thomas Gleixner wrote: > That looks wrong. It's not decrypted it's rather unencrypted, right? Yeah, it previous versions of the patchset, "decrypted" and "unencrypted" were both present so we settled on "decrypted" for the nomenclature. --

Re: [PATCH v7 08/36] x86/mm: Add support to enable SME in early boot processing

On Fri, 16 Jun 2017, Tom Lendacky wrote: > diff --git a/arch/x86/include/asm/mem_encrypt.h > b/arch/x86/include/asm/mem_encrypt.h > index a105796..988b336 100644 > --- a/arch/x86/include/asm/mem_encrypt.h > +++ b/arch/x86/include/asm/mem_encrypt.h > @@ -15,16 +15,24 @@ > > #ifndef __ASSEMBLY__

Re: [PATCH] docs: add virtualenv to Documentation's build chain

> Am 20.06.2017 um 21:56 schrieb Jonathan Corbet : > > On Tue, 20 Jun 2017 16:51:40 +0200 > Markus Heiser wrote: > >> This add a virtualenv [1] with we can control the versions >> of Documentation's (python) requirements. It also changes the >>