linux-kernel - Re: [PATCH v15 15/15] tracing: Add hist trigger action 'expected fail' test case

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:   Wed, 20 Feb 2019 12:45:15 -0600
From:   Tom Zanussi <zanussi@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     tglx@...utronix.de, mhiramat@...nel.org, namhyung@...nel.org,
        vedang.patel@...el.com, bigeasy@...utronix.de,
        joel@...lfernandes.org, mathieu.desnoyers@...icios.com,
        julia@...com, linux-kernel@...r.kernel.org,
        linux-rt-users@...r.kernel.org
Subject: Re: [PATCH v15 15/15] tracing: Add hist trigger action 'expected
 fail' test case

On Wed, 2019-02-20 at 13:33 -0500, Steven Rostedt wrote:
> On Wed, 20 Feb 2019 12:10:31 -0600
> Tom Zanussi <zanussi@...nel.org> wrote:
> 
> > 
> > As far as I understand it (there's no other case of an xfail test
> > in
> > the testsuite, so nothing similar to compare it to), the test
> > output is
> >  correct - here we get the expected fail, XFAIL, and not a FAIL as
> > any
> > test, xfail or normal, that failed would produce:
> 
> Yeah, I've been staring at the code, and commit:
> 
> 915de2adb584a ftracetest: Add POSIX.3 standard and XFAIL result codes
> 
> 
> > 
> > tools/testing/selftests/ftrace# ./ftracetest test.d/trigger/
> > === Ftrace unit tests ===
> > [1] event trigger - test inter-event histogram trigger expected
> > fail actions
> > [XFAIL]
> > [2] event trigger - test extended error support
> > [PASS]
> > 
> > And here the summary shows none failed, while we did have one
> > expected
> > xfail, but that's what was expected, and not a failure:
> > 
> > # of passed:  31
> > # of failed:  0
> > # of unresolved:  0
> > # of untested:  0
> > # of unsupported:  0
> > # of xfailed:  1
> 
> Yeah, but it's marked as RED, which is why I thought it was a
> failure.
> 
> > # of undefined(test bug):  0
> > 
> > If that's not correct, I'll fix it but at this point I'm not sure
> > what
> > the output should be if not that.
> 
> OK, so this has nothing to do with your patch set. I've tested
> everything else, and I'm ready to finally push my tree to linux-next.
> 
> I'm thinking that we should get rid of xfail, as it's really
> confusing,
> and I don't understand its purpose. But that shouldn't stop pushing
> your patches.
> 

OK, I'm fine with removing it, if it's too confusing.  IIRC Masami
suggested it to highlight that not all actions and handlers can be used
together, so I guess I'll hold off on a patch removing it until he can
chime in...

Thanks,

Tom 
 
> Thanks,
> 
> -- Steve