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: <564AAF4D.5080902@huawei.com>
Date:	Tue, 17 Nov 2015 12:38:37 +0800
From:	"Wangnan (F)" <wangnan0@...wei.com>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
CC:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Alexei Starovoitov <ast@...nel.org>, <lizefan@...wei.com>,
	Ingo Molnar <mingo@...nel.org>, Jiri Olsa <jolsa@...nel.org>,
	David Ahern <dsahern@...il.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>, <pi3orama@....com>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 12/13] perf test: Test BPF prologue



On 2015/11/17 9:29, Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 16, 2015 at 12:10:14PM +0000, Wang Nan escreveu:
>> This patch introduces a new BPF script to test BPF prologue. The new
>> script probes at null_lseek, which is the function pointer when we try
>> to lseek on '/dev/null'.
>>
>> null_lseek is chosen because it is a function pointer, so we don't need
>> to consider inlining and LTO.
>>
>> By extracting file->f_mode, bpf-script-test-prologue.c should know whether
>> the file is writable or readonly. According to llseek_loop() and
>> bpf-script-test-prologue.c, one forth of total lseeks should be collected.
> So I tentatively changed the section name key=val separator from '\n' to
> ';', applied all the patches up to this one (will review the last one
> tomorrow), and tested it, reproducing your results, for some reason that
> SEC() wasn't working, have to check again, using it expanded, as in my
> previous tests, works, I updated the comments to reflect the tests I
> did, please take a look.
>
> I've pushed everything to my perf/ebpf branch, please let me know if
> what is there is acceptable, then it will be up to Ingo to decide where
> to put this, if in perf/urgent for this merge window, or in perf/core,
> for the next one.
>
> Ah, to extract the output for these BPF sub-tests I had to use -v, i.e.
> just:
>
>    # perf test BPF
>    37: Test BPF filter                                          : Ok
>    #
>
> Ditto for the LLVM one.
>
> Doesn't tell us too much about all those nice sub-tests...
>
> How about:
>
>    # perf test -v BPF
>    37: Test BPF filter:
>    37.1: test a						       : Ok
>    37.2: test b						       : Ok
>    37.3: Test BPF prologue generation			       : Ok
>    37.4: Another...                                             : Ok
>    37: Test BPF filter					       : Ok
>    #
>
> Thanks!

I think what you want is to report state of subtests *without* -v?

That would be nice but changing of perf testing infrastructure is required
because there's no "sub-test" before, and we both agree that testcase
should be silent without '-v', so we need a way to output them in
builtin-test.c.

Let me try it but I think it should not be a blocking problem.

Thank you.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ