Re: [PATCH v13 3/3] mm, powerpc, x86: introduce an additional vma bit for powerpc pkey

From: Ram Pai
Date: Fri May 04 2018 - 21:13:04 EST


On Fri, May 04, 2018 at 03:57:33PM -0700, Dave Hansen wrote:
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 0c9e392..3ddddc7 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -679,6 +679,7 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> > [ilog2(VM_PKEY_BIT1)] = "",
> > [ilog2(VM_PKEY_BIT2)] = "",
> > [ilog2(VM_PKEY_BIT3)] = "",
> > + [ilog2(VM_PKEY_BIT4)] = "",
> > #endif /* CONFIG_ARCH_HAS_PKEYS */
> ...
> > +#if defined(CONFIG_PPC)
> > +# define VM_PKEY_BIT4 VM_HIGH_ARCH_4
> > +#else
> > +# define VM_PKEY_BIT4 0
> > +#endif
> > #endif /* CONFIG_ARCH_HAS_PKEYS */
>
> That new line boils down to:
>
> [ilog2(0)] = "",
>
> on x86. It wasn't *obvious* to me that it is OK to do that. The other
> possibly undefined bits (VM_SOFTDIRTY for instance) #ifdef themselves
> out of this array.
>
> I would just be a wee bit worried that this would overwrite the 0 entry
> ("??") with "".

Yes it would :-( and could potentially break anything that depends on
0th entry being "??"

Is the following fix acceptable?

#if VM_PKEY_BIT4
[ilog2(VM_PKEY_BIT4)] = "",
#endif

--
Ram Pai