Users must be given an option to discard any constraints set by
bootloaders. For example, consider that a constraint is set for the LCD
controller's supply and the LCD driver isn't loaded by the kernel. If
the user doesn't need to use the LCD device, then he shouldn't be forced
to honour the constr
On Wed, 5 Jul 2017 14:21:52 -0700
Ram Pai wrote:
> 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
On Wed, 5 Jul 2017 14:21:51 -0700
Ram Pai wrote:
> Initial plumbing to manage all the keys supported by the
> hardware.
>
> Total 32 keys are supported on powerpc. However pkey 0,1
> and 31 are reserved. So effectively we have 29 pkeys.
>
> This patch keeps track of reserved keys, allocated k
On Tue, 11 Jul 2017 08:44:15 -0700
Ram Pai wrote:
> On Tue, Jul 11, 2017 at 03:59:59PM +1000, Balbir Singh wrote:
> > On Wed, 5 Jul 2017 14:21:39 -0700
> > Ram Pai wrote:
> >
> > > Rearrange 64K PTE bits to free up bits 3, 4, 5 and 6
> > > in the 64K backed HPTE pages. This along with t
On Wed, Jul 12, 2017 at 08:08:56AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > > On 07/05/2017 02:21 PM, Ram Pai
On 07/11/2017 03:14 PM, Ram Pai wrote:
> Now how many does the kernel use to reserve for itself is something
> the kernel knows too and hence can expose it, though the information
> may change dynamically as the kernel reserves and releases the key
> based on its internal needs.
>
> So i think we
On Tue, Jul 11, 2017 at 02:57:30PM -0700, Dave Hansen wrote:
> On 07/11/2017 02:51 PM, Ram Pai wrote:
> > On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> >> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> >>> On 07/05/2017 02:21 PM, Ram Pai wrote:
> Currently
On Tue, 2017-07-11 at 14:51 -0700, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > > Currently sys_pkey_create() provides the ability to disable read
On Tue, 2017-07-11 at 12:32 -0700, Ram Pai wrote:
> Ideally the MMU looks at the PTE for keys, in order to enforce
> protection. This is the case with x86 and is the case with power9 Radix
> page table. Hence the keys have to be programmed into the PTE.
POWER9 radix doesn't currently support keys.
On 07/11/2017 02:51 PM, Ram Pai wrote:
> On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
>> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
>>> On 07/05/2017 02:21 PM, Ram Pai wrote:
Currently sys_pkey_create() provides the ability to disable read
and write p
On Wed, Jul 12, 2017 at 07:29:37AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> > On 07/05/2017 02:21 PM, Ram Pai wrote:
> > > Currently sys_pkey_create() provides the ability to disable read
> > > and write permission on the key, at creation. powe
On Tue, 2017-07-11 at 11:11 -0700, Dave Hansen wrote:
> On 07/05/2017 02:21 PM, Ram Pai wrote:
> > 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 pat
On Tue, 11 Jul 2017, Roman Gushchin wrote:
> > Yes, the original motivation was to limit killing to a single process, if
> > possible. To do that, we kill the process with the largest rss to free
> > the most memory and rely on the user to configure /proc/pid/oom_score_adj
> > if something els
On Tue, Jul 11, 2017 at 04:52:46PM +0200, Michal Hocko wrote:
> On Wed 05-07-17 14:21:37, Ram Pai wrote:
> > Memory protection keys enable applications to protect its
> > address space from inadvertent access or corruption from
> > itself.
> >
> > The overall idea:
> >
> > A process allocates a
On 07/05/2017 02:22 PM, Ram Pai wrote:
> Add documentation updates that capture PowerPC specific changes.
>
> Signed-off-by: Ram Pai
> ---
> Documentation/vm/protection-keys.txt | 85
> ++
> 1 files changed, 65 insertions(+), 20 deletions(-)
>
> diff --git a/D
On 07/05/2017 02:22 PM, Ram Pai wrote:
> +#ifdef CONFIG_PPC64_MEMORY_PROTECTION_KEYS
> +void arch_show_smap(struct seq_file *m, struct vm_area_struct *vma)
> +{
> + seq_printf(m, "ProtectionKey: %8u\n", vma_pkey(vma));
> +}
> +#endif /* CONFIG_PPC64_MEMORY_PROTECTION_KEYS */
This seems like k
On 07/05/2017 02:21 PM, Ram Pai wrote:
> x86 does not support disabling execute permissions on a pkey.
>
> Signed-off-by: Ram Pai
> ---
> arch/x86/kernel/fpu/xstate.c |3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/f
On 07/05/2017 02:21 PM, Ram Pai wrote:
> 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 c
On 07/05/2017 02:21 PM, Ram Pai wrote:
> 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 +-
> inc
On 07/05/2017 02:22 PM, Ram Pai wrote:
> 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/allo
Hi Guenter,
> > This allows setting a default value for the watchdog.open_timeout
> > commandline parameter via Kconfig.
> >
> > Some BSPs allow remote updating of the kernel image and root file
> > system, but updating the bootloader requires physical access. Hence, if
> > one has a firmware upd
On 7/11/2017 10:38 AM, Brian Gerst wrote:
On Tue, Jul 11, 2017 at 11:02 AM, Tom Lendacky wrote:
On 7/10/2017 11:58 PM, Brian Gerst wrote:
On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky
wrote:
On 7/8/2017 7:57 AM, Brian Gerst wrote:
On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
wrote:
On Tue, Jul 11, 2017 at 03:59:59PM +1000, Balbir Singh wrote:
> On Wed, 5 Jul 2017 14:21:39 -0700
> Ram Pai wrote:
>
> > 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 64
On Tue, Jul 11, 2017 at 11:02 AM, Tom Lendacky wrote:
> On 7/10/2017 11:58 PM, Brian Gerst wrote:
>>
>> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky
>> wrote:
>>>
>>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
wrote:
>
>
On 7/11/2017 12:56 AM, Borislav Petkov wrote:
On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote:
If I make the scattered feature support conditional on CONFIG_X86_64
(based on comment below) then cpu_has() will always be false unless
CONFIG_X86_64 is enabled. So this won't need to be w
On 7/11/2017 12:07 AM, Brian Gerst wrote:
On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky wrote:
On 7/8/2017 7:50 AM, Brian Gerst wrote:
On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky
wrote:
Update the CPU features to include identifying and reporting on the
Secure Memory Encryption (SME) feat
On 7/10/2017 11:58 PM, Brian Gerst wrote:
On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote:
On 7/8/2017 7:57 AM, Brian Gerst wrote:
On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
wrote:
Currently there is a check if the address being mapped is in the ISA
range (is_ISA_range()), and if it
On Wed 05-07-17 14:21:37, Ram Pai wrote:
> 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
> an address range withinits address
Any comments for this little change? It's passed on 0day testing.
Thanks
Alex
On 07/07/2017 10:52 AM, Alex Shi wrote:
> We don't need to adjust prio before new pi_waiter adding. The prio
> only need update after pi_waiter change or task priority change.
>
> Signed-off-by: Alex Shi
> Cc: Steven
Any comments for this patch? or time to pick it up?
Thanks
Alex
On 07/07/2017 10:52 AM, Alex Shi wrote:
> The rtmutex remove a pending owner bit in in rt_mutex::owner, in
> commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio
> task get lock")
> But the document was changed
On 07/07/2017 10:52 AM, Alex Shi wrote:
>
> -Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and Randy Dunlap
> +Original Reviewers: Ingo Molnar, Thomas Gleixner, Thomas Duetsch, and
> + Randy Dunlap
> +Update (7/6/2017) Reviewers: Steven Rostedt and Sebastian Siewio
On Mon, Jul 10, 2017 at 04:05:49PM -0700, David Rientjes wrote:
> On Wed, 21 Jun 2017, Roman Gushchin wrote:
>
> > 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
On Tue, Jul 11, 2017 at 4:35 AM, Arnd Bergmann wrote:
> On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote:
>> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky
>> wrote:
>>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
>>>
>>> I originally had a check
On 07/10/2017 11:25 AM, Ram Pai wrote:
> On Mon, Jul 10, 2017 at 08:41:30AM +0530, Anshuman Khandual wrote:
>> On 07/06/2017 02:52 AM, Ram Pai wrote:
>>> get_pte_pkey() helper returns the pkey associated with
>>> a address corresponding to a given mm_struct.
>>>
>>> Signed-off-by: Ram Pai
>>> ---
On Tue, Jul 11, 2017 at 6:58 AM, Brian Gerst wrote:
> On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote:
>> On 7/8/2017 7:57 AM, Brian Gerst wrote:
>>> On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky
>>
>> I originally had a check for SME here in a previous version of the
>> patch. Thomas Gleixn
35 matches
Mail list logo
