linux-kernel - Re: [PATCH v4 7/7] selftests: prctl: introduce tests for disabling THPs except for madvise

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: <a8b0eb8d-442e-4cfc-ab79-3c6bc6a86ff0@lucifer.local>
Date: Thu, 14 Aug 2025 11:53:05 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Usama Arif <usamaarif642@...il.com>
Cc: David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-fsdevel@...r.kernel.org, corbet@....net, rppt@...nel.org,
        surenb@...gle.com, mhocko@...e.com, hannes@...xchg.org,
        baohua@...nel.org, shakeel.butt@...ux.dev, riel@...riel.com,
        ziy@...dia.com, laoar.shao@...il.com, dev.jain@....com,
        baolin.wang@...ux.alibaba.com, npache@...hat.com,
        Liam.Howlett@...cle.com, ryan.roberts@....com, vbabka@...e.cz,
        jannh@...gle.com, Arnd Bergmann <arnd@...db.de>, sj@...nel.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
        kernel-team@...a.com, Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH v4 7/7] selftests: prctl: introduce tests for disabling
 THPs except for madvise

On Thu, Aug 14, 2025 at 11:36:51AM +0100, Usama Arif wrote:
>
>
> On 13/08/2025 19:52, Lorenzo Stoakes wrote:
> > On Wed, Aug 13, 2025 at 06:24:11PM +0200, David Hildenbrand wrote:
> >>>> +
> >>>> +FIXTURE_SETUP(prctl_thp_disable_except_madvise)
> >>>> +{
> >>>> +	if (!thp_available())
> >>>> +		SKIP(return, "Transparent Hugepages not available\n");
> >>>> +
> >>>> +	self->pmdsize = read_pmd_pagesize();
> >>>> +	if (!self->pmdsize)
> >>>> +		SKIP(return, "Unable to read PMD size\n");
> >>>> +
> >>>> +	if (prctl(PR_SET_THP_DISABLE, 1, PR_THP_DISABLE_EXCEPT_ADVISED, NULL, NULL))
> >>>> +		SKIP(return, "Unable to set PR_THP_DISABLE_EXCEPT_ADVISED\n");
> >>>
> >>> This should be a test fail I think, as the only ways this could fail are
> >>> invalid flags, or failure to obtain an mmap write lock.
> >>
> >> Running a kernel that does not support it?
> >
> > I can't see anything in the kernel to #ifdef it out so I suppose you mean
> > running these tests on an older kernel?
> >
>
> It was a fail in my previous revision
> (https://lore.kernel.org/all/9bcb1dee-314e-4366-9bad-88a47d516c79@redhat.com/)

Well it seems it's a debate between me and David then haha :P sorry.

This is a bit of a trivial thing I'm just keen that bugs don't get accidentally
missed because of skips, that's the most important thing I think.

>
> I do believe people (including me :)) get the latest kernel selftest and run it on
> older kernels.
> It might not be the right way to run selftests, but I do think its done.

People can do unsupported things, but then if it breaks that's on them to live
with :)

>
> > But this is an unsupported way of running self-tests, they are tied to the
> > kernel version in which they reside, and test that specific version.
> >
> > Unless I'm missing something here?
> >
> >>
> >> We could check the errno to distinguish I guess.
> >
> > Which one? manpage says -EINVAL, but can also be due to incorrect invocation,
> > which would mean a typo could mean tests pass but your tests do nothing :)
> >
>
> Yeah I dont think we can distinguish between the prctl not being available (i.e. older kernel)
> and the prctl not working as it should.
>
> We just need to decide whether to fail or skip.

I really think it's far worse to miss a bug in the code (or testing) than to
account for people running with different kernels.

>
> If the right way is to always run selftests from the same kernel version as the host
> on which its being run on, we can just fail? I can go back to the older version of
> doing things and move the failure from FIXTURE_SETUP to TEST_F?

Yeah I think it simply should just be a fail.

Why would you move things around though? Think it's fine as-is, if something on
setup fails then all tests should fail.

Cheers, Lorenzo