[PATCH RESEND] arm: drop unused includes of <linux/personality.h>

[Will Deacon]

On Fri, Feb 25, 2022 at 02:08:16PM -0500, Sagar Patel wrote:
> On Fri, Feb 25, 2022 at 8:56 AM Will Deacon <will at kernel.org> wrote:
> >
> > On Wed, Feb 23, 2022 at 12:36:36PM -0500, Sagar Patel wrote:
> > > Drop several includes of <linux/personality.h> which are not used.
> > > git-blame indicates they were used at some point, but they're not needed
> > > anymore.
> > >
> > > Signed-off-by: Sagar Patel <sagarmp at cs.unc.edu>
> > > ---
> > >  arch/arm/mm/mmap.c             | 1 -
> > >  arch/arm64/include/asm/page.h  | 1 -
> > >  arch/arm64/kernel/signal.c     | 1 -
> > >  arch/arm64/kernel/sys_compat.c | 1 -
> > >  arch/arm64/kernel/traps.c      | 1 -
> > >  5 files changed, 5 deletions(-)
> >
> > Please can you send separate patches for arch/arm/ and arch/arm64?
> 
> Sure, I can do that.
> 
> > Also, how did you determine that these includes are redundant?
> 
> Including linux/personality.h only brings in a total of three macros,
> and two enums. I manually checked whether any of the included symbols
> are used in the changed files.
> 
> For arch/arm64/include/asm/page.h (the only changed header file), "not
> being used" is not very reassuring. So, I also tested this patch by
> building the arm64 kernel with defconfig based on v5.17-rc5.
> 
> However, on further investigation, I have found that the macro
> VM_DATA_FLAGS_TSK_EXEC (which is used by
> arch/arm64/include/asm/page.h) does use personality.h. The build
> probably works since another header is pulling in personality.h. How
> should this be handled? The right thing to do seems to be to include
> personality.h in include/linux/mm.h since that is the header that
> defines VM_DATA_FLAGS_TSK_EXEC, and directly uses personality.h.
> Should I:
> 
> - send the include/linux/mm.h patch to the -mm tree, or
> - include the change to include/linux/mm.h in the patches I send you, or
> - leave the include in arch/arm64/include/asm/page.h in the patches I
> will send you, or

I'd go with this option ^^ for now, and then if you want to tackle the
riskier core change afterwards, please feel free.

Will