From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948196AbcBRUZv (ORCPT ); Thu, 18 Feb 2016 15:25:51 -0500 Received: from terminus.zytor.com ([198.137.202.10]:47238 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1948154AbcBRUZs (ORCPT ); Thu, 18 Feb 2016 15:25:48 -0500 Date: Thu, 18 Feb 2016 12:24:46 -0800 From: tip-bot for Dave Hansen Message-ID: Cc: riel@redhat.com, akpm@linux-foundation.org, peterz@infradead.org, mingo@kernel.org, brgerst@gmail.com, hpa@zytor.com, bp@alien8.de, dvlasenk@redhat.com, tglx@linutronix.de, torvalds@linux-foundation.org, luto@amacapital.net, dave@sr71.net, linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com Reply-To: torvalds@linux-foundation.org, tglx@linutronix.de, dvlasenk@redhat.com, dave.hansen@linux.intel.com, linux-kernel@vger.kernel.org, dave@sr71.net, luto@amacapital.net, peterz@infradead.org, mingo@kernel.org, akpm@linux-foundation.org, riel@redhat.com, bp@alien8.de, hpa@zytor.com, brgerst@gmail.com In-Reply-To: <20160212210228.7E79386C@viggo.jf.intel.com> References: <20160212210228.7E79386C@viggo.jf.intel.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:mm/pkeys] x86/mm/pkeys: Add Kconfig prompt to existing config option Git-Commit-ID: 284244a9876225eb73102aff41d4492f65cb2868 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 284244a9876225eb73102aff41d4492f65cb2868 Gitweb: http://git.kernel.org/tip/284244a9876225eb73102aff41d4492f65cb2868 Author: Dave Hansen AuthorDate: Fri, 12 Feb 2016 13:02:28 -0800 Committer: Ingo Molnar CommitDate: Thu, 18 Feb 2016 19:46:30 +0100 x86/mm/pkeys: Add Kconfig prompt to existing config option I don't have a strong opinion on whether we need this or not. Protection Keys has relatively little code associated with it, and it is not a heavyweight feature to keep enabled. However, I can imagine that folks would still appreciate being able to disable it. Here's the option if folks want it. Signed-off-by: Dave Hansen Reviewed-by: Thomas Gleixner Cc: Andrew Morton Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Dave Hansen Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Rik van Riel Cc: linux-mm@kvack.org Link: http://lkml.kernel.org/r/20160212210228.7E79386C@viggo.jf.intel.com Signed-off-by: Ingo Molnar --- arch/x86/Kconfig | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index fb2ebeb..b875434 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1716,8 +1716,18 @@ config X86_INTEL_MPX If unsure, say N. config X86_INTEL_MEMORY_PROTECTION_KEYS + prompt "Intel Memory Protection Keys" def_bool y + # Note: only available in 64-bit mode depends on CPU_SUP_INTEL && X86_64 + ---help--- + Memory Protection Keys provides a mechanism for enforcing + page-based protections, but without requiring modification of the + page tables when an application changes protection domains. + + For details, see Documentation/x86/protection-keys.txt + + If unsure, say y. config EFI bool "EFI runtime service support"