Received-SPF: pass (google.com: domain of linux-kernel+bounces-15920-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161;
Precedence: bulk
MIME-Version: 1.0
References: <20231228-extable-v1-1-32a18c66b440@google.com>
In-Reply-To: <20231228-extable-v1-1-32a18c66b440@google.com>
From: Nick Desaulniers <ndesaulniers@google.com>
Date: Wed, 3 Jan 2024 11:36:39 -0800
Message-ID: <CAKwvOdnZPo9FvMtB5jxg9bt5t3BtirzZw92CgrtJuDqVfBNH_Q@mail.gmail.com>
Subject: Re: [PATCH] x86/vdso: shrink vdso/extable.i via IWYU
To: Tanzir Hasan <tanzirh@google.com>
Cc: Andy Lutomirski <luto@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, 
	Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, 
	"H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org, 
	Nick Desaulniers <nnn@google.com>, Alexander Viro <viro@zeniv.linux.org.uk>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 28, 2023 at 12:56=E2=80=AFPM Tanzir Hasan <tanzirh@google.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@google.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 belo=
w).

> +#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.
--=20
Thanks,
~Nick Desaulniers