linux-kernel - Re: [RFC][PATCH] ftrace/selftests: Add binary test to verify ring buffer timestamps

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20201210110854.73fc08c6a19fdd8588f3e2c0@kernel.org>
Date:   Thu, 10 Dec 2020 11:08:54 +0900
From:   Masami Hiramatsu <mhiramat@...nel.org>
To:     Steven Rostedt <rostedt@...dmis.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Shuah Khan <skhan@...uxfoundation.org>,
        Linux Trace Devel <linux-trace-devel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC][PATCH] ftrace/selftests: Add binary test to verify ring
 buffer timestamps

On Wed, 9 Dec 2020 09:49:19 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Wed, 9 Dec 2020 08:39:54 +0900
> Masami Hiramatsu <mhiramat@...nel.org> wrote:
> 
> > > OK. I'll look at how to make this for both cases (embedded and not).
> > > Because, my current case is to copy the selftests to the machine and run
> > > them there. So my use case requires the build to happen at test time. But I
> > > can make it where it wont build if the binary already exists.  
> > 
> > For that case, what about just "make clean" before copy, then the binary
> > will be removed? 
> 
> I just meant that the binary build should not depend on anything outside
> the directory. It should be able to be built if you just copy the
> ftracetest directory and run there.

Oh I thought you considered the case that the library version differences
between the binary and execute environment.

> > > > (currently I returns UNRESOLVED when the test target kmodule is not found)  
> > > 
> > > I used UNTESTED for a couple of reasons. I figured "UNRESOLVED" was for
> > > lack of kernel features or modules. But this is not a lack of the kernel,
> > > but a lack of user space. If something in user space is lacking (a tool,
> > > library, or binary), then I thought UNTESTED would be a better option. But
> > > if you have a strong opinion on it, I'll change it to UNRESOLVED, otherwise
> > > I'll keep UNTESTED.  
> > 
> > The idea of UNTESTED/UNRESOLVED (and UNSUPPORTED) came from POSIX standard,
> > it is expained in dejagnu's manual:
> > 
> > https://www.gnu.org/software/dejagnu/manual/A-POSIX-Conforming-Test-Framework.html
> > 
> > In this case, user can build the user space binary for the environment but
> > does't, so I think UNRESOLVED will fit to that case.
> > 
> > So strictly speaking, UNTESTED is just a placeholder which will be implemented
> > in the future. (hmm, it will be a good chance to write a document for it)
> 
> OK, I'll change it to UNRESOLVED. One reason I used UNTESTED, is that the
> build wont happen until libtracefs is packaged and released (or you
> download and build it yourself). And it's just getting ready now. So in
> essence, this is currently just a "placeholder" ;-)

Yeah, so now if it can not run, user can solve it by installing libtracefs:)

Thank you,


-- 
Masami Hiramatsu <mhiramat@...nel.org>