linux-kernel - Re: [PATCH 2/2] selftests: pmtu.sh: improve the test result processing

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]

Date:   Mon, 9 Nov 2020 10:09:11 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Po-Hsu Lin <po-hsu.lin@...onical.com>
Cc:     netdev@...r.kernel.org, linux-kselftest@...r.kernel.org,
        linux-kernel@...r.kernel.org, David Miller <davem@...emloft.net>,
        Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH 2/2] selftests: pmtu.sh: improve the test result
 processing

On Mon, 9 Nov 2020 11:42:33 +0800 Po-Hsu Lin wrote:
> On Sun, Nov 8, 2020 at 7:02 AM Jakub Kicinski <kuba@...nel.org> wrote:
> >
> > On Thu,  5 Nov 2020 18:50:51 +0800 Po-Hsu Lin wrote:  
> > > This test will treat all non-zero return codes as failures, it will
> > > make the pmtu.sh test script being marked as FAILED when some
> > > sub-test got skipped.
> > >
> > > Improve the result processing by
> > >   * Only mark the whole test script as SKIP when all of the
> > >     sub-tests were skipped
> > >   * If the sub-tests were either passed or skipped, the overall
> > >     result will be PASS
> > >   * If any of them has failed, the overall result will be FAIL
> > >   * Treat other return codes (e.g. 127 for command not found) as FAIL
> > >
> > > Signed-off-by: Po-Hsu Lin <po-hsu.lin@...onical.com>  
> >
> > Patch 1 looks like a cleanup while patch 2 is more of a fix, can we
> > separate the two and apply the former to -next and latter to 5.10?
> > They shouldn't conflict, right?
> >  
> 
> Hello Jakub,
> 
> Yes the first patch is just changing return code to $ksft_skip, the
> real fix is the second one. However the second patch was based on the
> first one, if we want to apply them separately we might need to change
> this $ksft_skip handling part in the second patch.

Ah, I misread the situation, ksft_skip is 4, not 2, so the patch is
more than just refactoring.

> What should I do to deal with this?
> Resend the former for -next and rebase + resend the latter (plus the
> fix to remove case 1) for 5.10 without the former patch?

Let's apply both of the patches to net-next if that's fine with you.
Indeed detangling them is may be more effort that it's worth.