Message ID | 1525471183-21277-3-git-send-email-linuxram@us.ibm.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
> 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 "".
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
On 05/04/2018 06:12 PM, Ram Pai wrote: >> 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 Yep, I think that works for me.
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 */ }; size_t i; diff --git a/include/linux/mm.h b/include/linux/mm.h index c6a6f24..cca67d1 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -230,10 +230,16 @@ extern int overcommit_kbytes_handler(struct ctl_table *, int, void __user *, #ifdef CONFIG_ARCH_HAS_PKEYS # define VM_PKEY_SHIFT VM_HIGH_ARCH_BIT_0 -# define VM_PKEY_BIT0 VM_HIGH_ARCH_0 /* A protection key is a 4-bit value */ +/* Protection key is a 4-bit value on x86 and 5-bit value on ppc64 */ +# define VM_PKEY_BIT0 VM_HIGH_ARCH_0 # define VM_PKEY_BIT1 VM_HIGH_ARCH_1 # define VM_PKEY_BIT2 VM_HIGH_ARCH_2 # define VM_PKEY_BIT3 VM_HIGH_ARCH_3 +#if defined(CONFIG_PPC) +# define VM_PKEY_BIT4 VM_HIGH_ARCH_4 +#else +# define VM_PKEY_BIT4 0 +#endif #endif /* CONFIG_ARCH_HAS_PKEYS */ #if defined(CONFIG_X86)