On Wed, Aug 19, 2026 at 01:17:09PM +0530, Hemanth Selam wrote:
> On Tue, Aug 18, 2026 at 02:36:00PM +0000, Lorenzo Stoakes (ARM) wrote:
> > But it might be worth checking in this case to see whether the problem here
> > is in fact that we need PKEY_UNRESTRICTED defined over there?
> >
> > Hemanth - could you check please?
>
> Checked. It is already defined over there:
>
> tools/include/uapi/asm-generic/mman-common.h:88:#define PKEY_UNRESTRICTED
> 0x0
>
> and it does reach the mm selftests without "make headers", through
> TOOLS_INCLUDES. The path is not obvious, so for the record:
>
> pkey-helpers.h
> -> <linux/mman.h> tools/include/uapi/linux/mman.h
> -> <asm/mman.h> /usr/include/asm/mman.h
> (tools/include/uapi/asm/mman.h does not exist)
> -> <asm-generic/mman.h> tools/include/uapi/asm-generic/mman.h
> (-isystem puts it ahead of the system one)
> -> <asm-generic/mman-common-tools.h>
> -> <asm-generic/mman-common.h> PKEY_UNRESTRICTED
>
> I built the pkey tests with KHDR_INCLUDES pointing at an empty directory,
> that is, as if "make headers" had never run. They build, and cpp -dD
> says:
>
> defined in: tools/include/uapi/asm-generic/mman-common.h
>
> Pointing TOOLS_INCLUDES at an empty directory as well is what breaks it:
>
> pkey-helpers.h:188:30: error: 'PKEY_UNRESTRICTED' undeclared
>
> So that is where the definition comes from, and dropping the local
> #ifndef does not depend on "make headers" being run.
>
> The one thing worth being aware of is that the redirection into
> tools/include/uapi only happens because the system <asm/mman.h> includes
> <asm-generic/mman.h>.
>
> I had a look at the history you pointed at, thanks, that was the part I
> had wrong. If I read it right this is exactly the mechanism from commit
> e076eaca5906 ("selftests: break the dependency upon local header
> files"), which added TOOLS_INCLUDES to the mm selftests so they build
> without "make headers". So for this particular macro the value comes
> from the in-tree snapshot rather than from whatever the build host has
> installed, which is why it does not vary per system here.
>
> That said, if you would still rather keep the #ifndef as a matter of
> course, I have no objection to dropping the patch, the guard costs
> nothing. I mainly wanted to answer the question with something
> measured rather than assumed.
Thanks, all I care about is if they build so fine to remove then.
>
> > This is incorrect. We explicitly do not have this requirement in mm
> > selftests,
> > and they're often built without having to do this step and tooling has been
> > provided _explicitly_ to allow for that, which is why this kind of thing
> > exists
> > right now.
>
> You are right, the commit message was wrong on that point. v2 drops
> that paragraph and describes the above instead.
>
> On the powerpc header David mentioned, I would rather leave
> tools/testing/selftests/powerpc/include/pkeys.h alone. It is not the
> same construct: it is an unconditional
>
> #undef PKEY_UNRESTRICTED
> #define PKEY_UNRESTRICTED 0x0
>
> next to other powerpc specific overrides such as PKEY_DISABLE_EXECUTE
> 0x4, and that header only includes <sys/mman.h>, never <linux/mman.h>.
> A probe including just <sys/mman.h> does not find PKEY_UNRESTRICTED,
> with or without TOOLS_INCLUDES, so the definition there is load bearing
> and removing it would break the build.
Load-bearing :)) Where have I heard that phrasing before...
>
> Thanks,
> Hemanth
--
Cheers, Lorenzo
