linux-kernel - Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKwvOdnZPo9FvMtB5jxg9bt5t3BtirzZw92CgrtJuDqVfBNH_Q@mail.gmail.com>
Date: Wed, 3 Jan 2024 11:36:39 -0800
From: Nick Desaulniers <ndesaulniers@...gle.com>
To: Tanzir Hasan <tanzirh@...gle.com>
Cc: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, 
	Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, 
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org, 
	Nick Desaulniers <nnn@...gle.com>, Alexander Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU

On Thu, Dec 28, 2023 at 12:56 PM Tanzir Hasan <tanzirh@...gle.com> wrote:
>
> This diff uses an open source tool include-what-you-use (IWYU) to modify
> the include list, changing indirect includes to direct includes. IWYU is
> implemented using the IWYUScripts github repository which is a tool that
> is currently undergoing development. These changes seek to improve build
> times.
>
> This change to vdso/extable.c resulted in a preprocessed size of
> vdso/extable.i from 64332 lines to 45377 lines (-27%) for the x86
> defconfig.
>
> Signed-off-by: Tanzir Hasan <tanzirh@...gle.com>
> ---
>  arch/x86/entry/vdso/extable.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/entry/vdso/extable.c b/arch/x86/entry/vdso/extable.c
> index afcf5b65beef..8221231917ec 100644
> --- a/arch/x86/entry/vdso/extable.c
> +++ b/arch/x86/entry/vdso/extable.c
> @@ -1,10 +1,14 @@
>  // SPDX-License-Identifier: GPL-2.0
> -#include <linux/err.h>
>  #include <linux/mm.h>

^ I think we can get more aggressive about avoiding linux/mm.h even.
I think you could replace linux/mm.h with

#include <linux/mm_types.h>  // for mm_struct, mm_struct::(anonymous)
#include <asm/mmu.h>         // for mm_context_t

assuming it's ok to include asm/* files in .c files under arch/* (more below).

> +#include <linux/sched.h>
> +#include <linux/stddef.h>
> +#include <linux/types.h>
>  #include <asm/current.h>
> -#include <asm/traps.h>
> +#include <asm/trapnr.h>
>  #include <asm/vdso.h>
>
> +struct pt_regs;
> +

^ This forward declaration shouldn't be necessary and looks wrong;
pt_regs is not used as an opaque type in this TU.

What I suspect is happening:
1. debug output from your tooling seems to think pt_regs should come
from linux/ptrace.h.
2. your tooling has a rule to replace recommendations for asm/ptrace.h
with linux/ptrace.h.  I may have misunderstood Al's point in an
earlier thread; perhaps it's ok to use asm/*.h in .c files under
arch/*/, but linux/*.h should be used everywhere else?  If that's the
case then perhaps we can break up that table such that asm-generic/*.h
-> asm/*.h is one table that's always used, and asm/*.h -> linux/*.h
is another table that's conditionally used when the .c file is not
under arch/*/?

To avoid pinging maintainers too many times, why don't we do an
internal code review for v2 before sending it publicly?  I appreciate
you making progress by sending a v1 while I was on holiday; for v2,
let's review internally first.
-- 
Thanks,
~Nick Desaulniers