All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: mpe@ellerman.id.au, mingo@redhat.com, akpm@linux-foundation.org
Cc: linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
	x86@kernel.org, linux-arch@vger.kernel.org,
	linux-kernel@vger.kernel.org, dave.hansen@intel.com,
	benh@kernel.crashing.org, paulus@samba.org,
	khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com,
	bsingharora@gmail.com, hbabu@us.ibm.com, mhocko@kernel.org,
	bauerman@linux.vnet.ibm.com, ebiederm@xmission.com,
	linuxram@us.ibm.com, corbet@lwn.net, arnd@arndb.de
Subject: [PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys.
Date: Fri,  4 May 2018 14:59:40 -0700	[thread overview]
Message-ID: <1525471183-21277-1-git-send-email-linuxram@us.ibm.com> (raw)

This patch series provides arch-neutral enhancements to
enable memory-keys on new architecutes, and the corresponding
changes in x86 and powerpc specific code to support that.

a) Provides ability to support upto 32 keys.  PowerPC
        can handle 32 keys and hence needs this.

b) Arch-neutral code; and not the arch-specific code,
   determines the format of the string, that displays the key
   for each vma in smaps.

History:
-------
version 14:
	(1) made VM_PKEY_BIT4 unusable on x86, #defined it to 0
		-- comment by Dave Hansen
	(2) due to some reason this patch series continue to
	      break some or the other build. The last series
	      passed everything but created a merge
	      conflict followed by build failure for
	      Michael Ellermen. :(

version v13:
	(1) fixed a git bisect error. :(

version v12:
	(1) fixed compilation errors seen with various x86
	    configs.
version v11:
	(1) code that displays key in smaps is not any more
	    defined under CONFIG_ARCH_HAS_PKEYS.
		- Comment by Eric W. Biederman and Michal Hocko
	(2) merged two patches that implemented (1).
		- comment by Michal Hocko

version prior to v11:
	(1) used one additional bit from VM_HIGH_ARCH_*
		to support 32 keys.
		- Suggestion by Dave Hansen.
	(2) powerpc specific changes to support memory keys.


Ram Pai (3):
  mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS
    is enabled
  mm, powerpc, x86: introduce an additional vma bit for powerpc pkey
  mm, x86, powerpc: display pkey in smaps only if arch supports pkeys

 arch/powerpc/include/asm/mmu_context.h |    5 -----
 arch/powerpc/include/asm/pkeys.h       |    2 ++
 arch/x86/include/asm/mmu_context.h     |    5 -----
 arch/x86/include/asm/pkeys.h           |    1 +
 arch/x86/kernel/fpu/xstate.c           |    5 +++++
 arch/x86/kernel/setup.c                |    8 --------
 fs/proc/task_mmu.c                     |   16 +++++++++-------
 include/linux/mm.h                     |   15 +++++++++++----
 include/linux/pkeys.h                  |    7 ++++++-
 9 files changed, 34 insertions(+), 30 deletions(-)

             reply	other threads:[~2018-05-04 22:00 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-04 21:59 Ram Pai [this message]
2018-05-04 21:59 ` [PATCH v13 1/3] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled Ram Pai
2018-05-04 21:59 ` [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey Ram Pai
2018-05-04 22:57   ` Dave Hansen
2018-05-05  1:12     ` Ram Pai
2018-05-05  4:42       ` Dave Hansen
2018-05-04 21:59 ` [PATCH v11 3/3] mm, x86, powerpc: display pkey in smaps only if arch supports pkeys Ram Pai
2018-05-08 14:39 ` [PATCH v13 0/3] mm, x86, powerpc: Enhancements to Memory Protection Keys Michael Ellerman
2018-05-08 14:39   ` Michael Ellerman
2018-05-08 14:39   ` Michael Ellerman
  -- strict thread matches above, loose matches on Subject: below --
2018-03-27  9:09 Ram Pai
2018-03-27  9:09 ` Ram Pai
2018-03-27  9:09 ` linuxram
2018-03-27  9:09 ` Ram Pai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1525471183-21277-1-git-send-email-linuxram@us.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=arnd@arndb.de \
    --cc=bauerman@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bsingharora@gmail.com \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@intel.com \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=khandual@linux.vnet.ibm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mhocko@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=paulus@samba.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.