linux-kernel - Re: [PATCH] selftests/mm: Fix test result reporting in gup

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: <8131ce62-0cee-455f-9eeb-e2bbed244402@redhat.com>
Date: Mon, 19 May 2025 15:28:47 +0200
From: David Hildenbrand <david@...hat.com>
To: Mark Brown <broonie@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>, Shuah Khan <shuah@...nel.org>,
 linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/mm: Fix test result reporting in gup_longterm

On 16.05.25 20:07, Mark Brown wrote:
> On Fri, May 16, 2025 at 04:12:08PM +0200, David Hildenbrand wrote:
>> On 16.05.25 15:09, Mark Brown wrote:
> 
>>>> I'm afraid we have other such tests that report duplicate conditions. cow.c
>>>> is likely another candidate (written by me ;) ).
> 
>>> That one's not come up for me (this was one of four different patches
>>> for mm selftests I sent the other day cleaning up duplicate test names).
> 
>> $ sudo ./cow
> 
> ...
> 
>> 1..778
>> # [INFO] Anonymous memory tests in private mappings
>> # [RUN] Basic COW after fork() ... with base page
>> ok 1 No leak from parent into child
>> # [RUN] Basic COW after fork() ... with swapped out base page
>> ok 2 No leak from parent into child
> 
>> Aren't the duplicate "No leak from parent into child" the problematic bits?
>> But maybe I am getting it wrong, what needs to be "unique" :)
> 
> Ah, yes - that's got the same issue.  I'm not running that program one
> way or another, it's not immediately clear to me why not - I can't see
> any sign of it being invoked by the runner script but I also can't see
> anything that I'd expect to stop that happening.  I'll have to have a
> poke at it, thanks for flagging that.
> 
> [Converting to kselftet_harness]
>>> That'd certainly work, though doing that is more surgery on the test
>>> than I personally have the time/enthusiasm for right now.
> 
>> Same over here.
> 
>> But probably if we touch it, we should just clean it up right away. Well,
>> if we decide that that is the right cleanup. (you mention something like that
>> in your patch description :)
> 
> OTOH there's something to be said for just making incremental
> improvements in the tests where we can, they tend not to get huge
> amounts of love in general which means perfect can very much be the
> enemy of good.  If there's some immediate prospect of someone doing a
> bigger refactoring then that'd be amazing, but if not then it seems
> useful to make things play better with the automation for now.

I would agree if it would be a handful of small changes.

But here we are already at

  1 file changed, 107 insertions(+), 56 deletions(-)

-- 
Cheers,

David / dhildenb