linux-kernel - Re: [PATCH 0/2] selftests/mm: uffd-stress fixes

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: <1634f29f-81a6-46f7-86d4-c9eac953d4f1@arm.com>
Date: Mon, 8 Sep 2025 13:52:05 +0530
From: Dev Jain <dev.jain@....com>
To: akpm@...ux-foundation.org, david@...hat.com, shuah@...nel.org
Cc: lorenzo.stoakes@...cle.com, Liam.Howlett@...cle.com, vbabka@...e.cz,
 rppt@...nel.org, surenb@...gle.com, mhocko@...e.com, npache@...hat.com,
 ryan.roberts@....com, linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] selftests/mm: uffd-stress fixes


On 26/08/25 12:37 pm, Dev Jain wrote:
> This patchset ensures that the number of hugepages is correctly set in the
> system so that the uffd-stress test does not fail due to the racy nature of
> the test. Patch 1 corrects the hugepage constraint in the run_vmtests.sh
> script, whereas patch 2 corrects the constraint in the test itself.
>
> Dev Jain (2):
>    selftests/mm/uffd-stress: Make test operate on less hugetlb memory
>    selftests/mm/uffd-stress: Stricten constraint on free hugepages before
>      the test
>
>   tools/testing/selftests/mm/run_vmtests.sh | 2 +-
>   tools/testing/selftests/mm/uffd-stress.c  | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)

Hi Andrew,

I wanted to make a v2 of this series to replace 10 with min(32, nrcpus - 1)
(see computation of nr_parallel in uffd-stress.c) but I see that it has
been pulled into mm-new, and on top of that, the following patch makes
things complicated to just revert my commits in mm-new and make v2 on top of that -
https://lore.kernel.org/all/20250830033424.8C44FC4CEF0@smtp.kernel.org/

So shall I just send a new separate patch based off mm-new?