linux-kernel - Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in ksm_functional

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: <7b78974b-6841-4280-89c1-01bd835d4f27@linux.ibm.com>
Date: Thu, 3 Jul 2025 14:21:22 +0530
From: Donet Tom <donettom@...ux.ibm.com>
To: David Hildenbrand <david@...hat.com>,
        Aboorva Devarajan <aboorvad@...ux.ibm.com>, akpm@...ux-foundation.org,
        Liam.Howlett@...cle.com, lorenzo.stoakes@...cle.com, shuah@...nel.org,
        pfalcato@...e.de, ziy@...dia.com, baolin.wang@...ux.alibaba.com,
        npache@...hat.com, ryan.roberts@....com, dev.jain@....com,
        baohua@...nel.org
Cc: linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, ritesh.list@...il.com
Subject: Re: [PATCH v2 5/7] selftests/mm: Fix child process exit codes in
 ksm_functional_tests

Hi David

On 7/3/25 2:03 PM, David Hildenbrand wrote:
> On 03.07.25 08:06, Aboorva Devarajan wrote:
>> In ksm_functional_tests, test_child_ksm() returned negative values
>> to indicate errors. However, when passed to exit(), these were
>> interpreted as large unsigned values (e.g, -2 became 254), leading to
>> incorrect handling in the parent process. As a result, some tests
>> appeared to be skipped or silently failed.
>>
>> This patch changes test_child_ksm() to return positive error codes
>> (1, 2, 3) and updates test_child_ksm_err() to interpret them correctly.
>> This ensures the parent accurately detects and reports child process
>> failures.
>>
>> --------------
>> Before patch:
>> --------------
>> - [RUN] test_unmerge
>> ok 1 Pages were unmerged
>> ...
>> - [RUN] test_prctl_fork
>> - No pages got merged
>> - [RUN] test_prctl_fork_exec
>> ok 7 PR_SET_MEMORY_MERGE value is inherited
>> ...
>> Bail out! 1 out of 8 tests failed
>> - Planned tests != run tests (9 != 8)
>> - Totals: pass:7 fail:1 xfail:0 xpass:0 skip:0 error:0
>>
>> --------------
>> After patch:
>> --------------
>> - [RUN] test_unmerge
>> ok 1 Pages were unmerged
>> ...
>> - [RUN] test_prctl_fork
>> - No pages got merged
>> not ok 7 Merge in child failed
>> - [RUN] test_prctl_fork_exec
>> ok 8 PR_SET_MEMORY_MERGE value is inherited
>> ...
>> Bail out! 2 out of 9 tests failed
>> - Totals: pass:7 fail:2 xfail:0 xpass:0 skip:0 error:0
>>
>> Fixes: 6c47de3be3a0 ("selftest/mm: ksm_functional_tests: extend test 
>> case for ksm fork/exec")
>> Signed-off-by: Aboorva Devarajan <aboorvad@...ux.ibm.com>
>
> BTW, when I run the test, I get this weird output
>
> TAP version 13
> 1..9
> # [RUN] test_unmerge
> ok 1 Pages were unmerged
> # [RUN] test_unmerge_zero_pages
> ok 2 KSM zero pages were unmerged
> # [RUN] test_unmerge_discarded
> ok 3 Pages were unmerged
> # [RUN] test_unmerge_uffd_wp
> ok 4 Pages were unmerged
> # [RUN] test_prot_none
> ok 5 Pages were unmerged
> # [RUN] test_prctl
> ok 6 Setting/clearing PR_SET_MEMORY_MERGE works
> # [RUN] test_prctl_fork
> ok 7 PR_SET_MEMORY_MERGE value is inherited
> # [RUN] test_prctl_fork_exec
>
> ^ where is the test?
>
> # [RUN] test_prctl_unmerge
> ok 8 Pages were unmerged
> # Planned tests != run tests (9 != 8)
> # Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0
>
> ^ what?
>
> ok 8 PR_SET_MEMORY_MERGE value is inherited
> # [RUN] test_prctl_unmerge
> ok 9 Pages were unmerged
> # Totals: pass:9 fail:0 xfail:0 xpass:0 skip:0 error:0
>
> ^ huh, what now?
>

The problem with the exec test is that it uses its own binary to exec.

         } else if (child_pid == 0) {
                 char *prg_name = "./ksm_functional_tests";
                 char *argv_for_program[] = { prg_name, 
FORK_EXEC_CHILD_PRG_NAME, NULL };

                 execv(prg_name, argv_for_program);
                 return;
         }

So we should run it on the same directory where the binary present.