Re: [PATCH 27/30] mm/vma: correct incorrect vma.h inclusion

[Lorenzo Stoakes <ljs@kernel.org>]

On Thu, Jul 02, 2026 at 12:40:30PM +0100, Pedro Falcato wrote:
> On Mon, Jun 29, 2026 at 01:23:38PM +0100, Lorenzo Stoakes wrote:
> > The only files which should be including vma.h are the implementation files
> > for the core VMA logic - vma.c, vma_init.c, and vma_exec.c.
> >
> > This is in order to allow for userland testing of core VMA logic. In this
> > cases, vma_internal.h and vma.h are included, providing both the
> > dependencies upon which the core VMA logic requires and its declarations.
> >
> > Userland testable VMA logic is achieved by having separate vma_internal.h
> > implementations for userland and kernel.
> >
> > Callers other than the core VMA implementation should include internal.h
> > instead. This header does not need to include vma_internal.h as it only
> > contains the vma.h declarations, for which the includes already present
> > suffice.
> >
> > Update code to reflect this, update comments to reflect the fact there are
> > 3 VMA implementation files and document things more clearly.
> >
> > While we're here, slightly improve the language of the comment describing
> > vma_exec.c.
>
> Two random thoughts:
> 1) perhaps vma.h -> vma_private.h

Not a bad idea thanks!

> 2) https://lore.kernel.org/all/CAHk-=wghMm2c+AYEcwYY7drSVXB27DYqc-ZXpFiq=XFs-w59wA@mail.gmail.com/
>    mm/vma/whatever.c :) would PROBABLY solve the issue of people snooping vma.h

I think a vma/ subdir would probably confuse things further, I think renaming to
vma_private.h neatly solves it actually, along with a comment maybe in the
header itself?

Then again mm/vma/{vma.c,init.c, exec.c, private.h} isn't too crazy
either. Though vma.h is the actual 'shared' bit, and vma_internal.h is the
private bit that the userland changes. But could switch things around vma.h ->
mm/vma/internal.h that mm/internal.h imports, and mm/vma_internal.h becomes
mm/vma/private.h.

I think that could work but definitely a follow-up!

>
> >
> > No functional change intended.
> >
> > Signed-off-by: Lorenzo Stoakes <ljs@kernel.org>
>
> Reviewed-by: Pedro Falcato <pfalcato@suse.de>

Thanks!

Cheers, Lorenzo