On Fri, Dec 21, 2018 at 12:19:13AM +1100, Michael Ellerman wrote:
> Hi Ram,
>
> Thanks for fixing this.
>
> Ram Pai writes:
> > diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> > index b271b28..5d65c47 100644
> > --- a/arch/powerpc/mm/pkeys.c
> > +++ b/arch/powerpc/mm/pkeys.c
> >
Hi Ram,
Thanks for fixing this.
Ram Pai writes:
> diff --git a/arch/powerpc/mm/pkeys.c b/arch/powerpc/mm/pkeys.c
> index b271b28..5d65c47 100644
> --- a/arch/powerpc/mm/pkeys.c
> +++ b/arch/powerpc/mm/pkeys.c
> @@ -414,3 +414,10 @@ bool arch_vma_access_permitted(struct vm_area_struct
> *vma, bo
* Ram Pai:
> +void arch_dup_pkeys(struct mm_struct *oldmm, struct mm_struct *mm)
> +{
> + /* Duplicate the oldmm pkey state in mm: */
> + mm_pkey_allocation_map(mm) = mm_pkey_allocation_map(oldmm);
> + mm->context.execute_only_pkey = oldmm->context.execute_only_pkey;
> +}
Looks reason
Ram Pai writes:
> At fork(), the pkey tracking information is not copied over
> to the mm_struct of the child. This can cause the child to erroneously
> allocate keys that were already allocated. Any allocated execute-only
> key is lost aswell.
>
> Add code; called by dup_mmap(), to copy the pk
At fork(), the pkey tracking information is not copied over
to the mm_struct of the child. This can cause the child to erroneously
allocate keys that were already allocated. Any allocated execute-only
key is lost aswell.
Add code; called by dup_mmap(), to copy the pkey state from
parent to child e
