On 3/29/20 5:48 PM, Liu Yiding wrote:
> Add attachment.
>
Your BTF seems to be invalid. It has struct perf_ibs, which has a first
field `struct pmu pmu` field with valid-looking size of 296 bytes,
**but** the type that field points to is not a complete `struct pmu`
definition, but rather just forward declaration. The way it is it
shouldn't be even compilable, because forward declaration of a struct
doesn't specify the size of a struct, so compiler should have rejected
it. So it must be that either DWARF generated by compiler isn't correct,
or there is DWARF -> BTF conversion bug somewhere. Are you using any
special DWARF Kconfig settings? Maybe you can share your full .config
and I might try to repro it on my machine.
But either way, that warning you get is a valid one, it should be
illegal to have non-pointer forward-declared struct as a type for a
struct member.
>
> On 3/30/20 8:46 AM, Liu Yiding wrote:
>> Something wrong with my smtp and this email missed.
>>
>> Send again.
>>
>>
>> On 3/27/20 11:09 AM, Liu Yiding wrote:
>>> Hi, Andrii.
>>>
>>> Thanks for your prompt reply!
>>>
>>> Please check attatchment for my_btf.bin.
>>>
>>>
>>> On 3/27/20 4:28 AM, Andrii Nakryiko wrote:
>>>> Would you be able to share BTF of vmlinux that is used to generate
>>>> vmlinux.h? Please run in verbose mode: `make V=1` and search for
>>>> `bpftool btf dump file` command. It should point either to
>>>> /sys/kernel/btf/vmlinux or some other location, depending on how
>>>> things are set up on your side.
>>>>
>>>> If it's /sys/kernel/btf/vmlinux, you can just `cat
>>>> /sys/kernel/btf/vmlinux > my_btf.bin`. If it's some other file,
>>>> easiest would be to just share that file. If not, it's possible to
>>>> extract .BTF ELF section, let me know if you need help with that.
>>>
Something wrong with my smtp and this email missed.
Send again.
On 3/27/20 11:09 AM, Liu Yiding wrote:
> Hi, Andrii.
>
> Thanks for your prompt reply!
>
> Please check attatchment for my_btf.bin.
>
>
> On 3/27/20 4:28 AM, Andrii Nakryiko wrote:
>> Would you be able to share BTF of vmlinux that is used to generate
>> vmlinux.h? Please run in verbose mode: `make V=1` and search for
>> `bpftool btf dump file` command. It should point either to
>> /sys/kernel/btf/vmlinux or some other location, depending on how
>> things are set up on your side.
>>
>> If it's /sys/kernel/btf/vmlinux, you can just `cat
>> /sys/kernel/btf/vmlinux > my_btf.bin`. If it's some other file,
>> easiest would be to just share that file. If not, it's possible to
>> extract .BTF ELF section, let me know if you need help with that.
>
--
Best Regards.
Liu Yiding
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
A new file was added to the tracing directory that will allow a user to
place a PID into it and the task associated to that PID will not be traced
by the function tracer. If the function-fork option is enabled, then neither
will the children of that task be traced by the function tracer.
Cc: linux-kselftest(a)vger.kernel.org
Cc: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
.../test.d/ftrace/func-filter-notrace-pid.tc | 108 ++++++++++++++++++
1 file changed, 108 insertions(+)
create mode 100644 tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
new file mode 100644
index 000000000000..8aa46a2ea133
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func-filter-notrace-pid.tc
@@ -0,0 +1,108 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# description: ftrace - function pid notrace filters
+# flags: instance
+
+# Make sure that function pid matching filter with notrace works.
+
+if ! grep -q function available_tracers; then
+ echo "no function tracer configured"
+ exit_unsupported
+fi
+
+if [ ! -f set_ftrace_notrace_pid ]; then
+ echo "set_ftrace_notrace_pid not found? Is function tracer not set?"
+ exit_unsupported
+fi
+
+if [ ! -f set_ftrace_filter ]; then
+ echo "set_ftrace_filter not found? Is function tracer not set?"
+ exit_unsupported
+fi
+
+do_function_fork=1
+
+if [ ! -f options/function-fork ]; then
+ do_function_fork=0
+ echo "no option for function-fork found. Option will not be tested."
+fi
+
+read PID _ < /proc/self/stat
+
+if [ $do_function_fork -eq 1 ]; then
+ # default value of function-fork option
+ orig_value=`grep function-fork trace_options`
+fi
+
+do_reset() {
+ if [ $do_function_fork -eq 0 ]; then
+ return
+ fi
+
+ echo > set_ftrace_notrace_pid
+ echo $orig_value > trace_options
+}
+
+fail() { # msg
+ do_reset
+ echo $1
+ exit_fail
+}
+
+do_test() {
+ disable_tracing
+
+ echo do_execve* > set_ftrace_filter
+ echo *do_fork >> set_ftrace_filter
+
+ echo $PID > set_ftrace_notrace_pid
+ echo function > current_tracer
+
+ if [ $do_function_fork -eq 1 ]; then
+ # don't allow children to be traced
+ echo nofunction-fork > trace_options
+ fi
+
+ enable_tracing
+ yield
+
+ count_pid=`cat trace | grep -v ^# | grep $PID | wc -l`
+ count_other=`cat trace | grep -v ^# | grep -v $PID | wc -l`
+
+ # count_pid should be 0
+ if [ $count_pid -ne 0 -o $count_other -eq 0 ]; then
+ fail "PID filtering not working? traced task = $count_pid; other tasks = $count_other "
+ fi
+
+ disable_tracing
+ clear_trace
+
+ if [ $do_function_fork -eq 0 ]; then
+ return
+ fi
+
+ # allow children to be traced
+ echo function-fork > trace_options
+
+ # With pid in both set_ftrace_pid and set_ftrace_notrace_pid
+ # there should not be any tasks traced.
+
+ echo $PID > set_ftrace_pid
+
+ enable_tracing
+ yield
+
+ count_pid=`cat trace | grep -v ^# | grep $PID | wc -l`
+ count_other=`cat trace | grep -v ^# | grep -v $PID | wc -l`
+
+ # both should be zero
+ if [ $count_pid -ne 0 -o $count_other -ne 0 ]; then
+ fail "PID filtering not following fork? traced task = $count_pid; other tasks = $count_other "
+ fi
+}
+
+do_test
+
+do_reset
+
+exit 0
--
2.25.1
From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org>
The ftrace selftest "ftrace - test for function traceon/off triggers"
enables all events and reads the trace file. Now that the trace file does
not disable tracing, and will attempt to continually read new data that is
added, the selftest gets stuck reading the trace file. This is because the
data added to the trace file will fill up quicker than the reading of it.
By only enabling scheduling events, the read can keep up with the writes.
Instead of enabling all events, only enable the scheduler events.
Link: http://lkml.kernel.org/r/20200318111345.0516642e@gandalf.local.home
Cc: Shuah Khan <skhan(a)linuxfoundation.org>
Cc: linux-kselftest(a)vger.kernel.org
Acked-by: Masami Hiramatsu <mhiramat(a)kernel.org>
Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org>
---
.../selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc b/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
index 0c04282d33dd..1947387fe976 100644
--- a/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
+++ b/tools/testing/selftests/ftrace/test.d/ftrace/func_traceonoff_triggers.tc
@@ -41,7 +41,7 @@ fi
echo '** ENABLE EVENTS'
-echo 1 > events/enable
+echo 1 > events/sched/enable
echo '** ENABLE TRACING'
enable_tracing
--
2.25.1
Hi, Andrii.
I noticed you had added runqslower tool to tools/bpf, so drop this
problem to you.
Now i failed to run bpf tests since i can't build runqslower.
Testing env: "Debian GNU/Linux 9 (stretch)"
kernel: 5.6.0-rc5
gcc: gcc 6.3
clang: clang-11.
Description: Build runqslower failed due to build error "incomplete
type" and libbpf show unsupported BTF_KIND:7.
Whole build log please see the attatchment.
Error info
```
root@vm-snb-144 ~/linus/tools/bpf# make
Auto-detecting system features:
... libbfd: [ on ]
... disassembler-four-args: [ OFF ]
[snip]
INSTALL bpftool
LINK bpf_asm
GEN vmlinux.h
libbpf: unsupported BTF_KIND:7 (Many unsupported errors)
libbpf: unsupported BTF_KIND:7
libbpf: unsupported BTF_KIND:7
[snip]
(Many incomplete type errors)
.output/vmlinux.h:8401:18: error: field has incomplete type 'struct
idt_bits'
struct idt_bits bits;
^
.output/vmlinux.h:8396:8: note: forward declaration of 'struct idt_bits'
struct idt_bits;
^
.output/vmlinux.h:8598:21: error: field has incomplete type 'struct
trace_entry'
struct trace_entry ent;
^
.output/vmlinux.h:8595:8: note: forward declaration of 'struct trace_entry'
struct trace_entry;
^
.output/vmlinux.h:9006:25: error: array has incomplete element type
'struct cyc2ns_data'
struct cyc2ns_data data[2];
^
.output/vmlinux.h:3669:8: note: forward declaration of 'struct cyc2ns_data'
struct cyc2ns_data;
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
Makefile:56: recipe for target '.output/runqslower.bpf.o' failed
make[1]: *** [.output/runqslower.bpf.o] Error 1
Makefile:119: recipe for target 'runqslower' failed
make: *** [runqslower] Error 2
```
--
Best Regards.
Liu Yiding
Changes for commit 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pagevecs")
break this test expectations on the behavior of mlock syscall family immediately
inserting the recently faulted pages into the UNEVICTABLE_LRU, when MCL_ONFAULT is
passed to the syscall as part of its flag-set.
There is no functional error introduced by the aforementioned commit,
but it opens up a time window where the recently faulted and locked pages
might yet not be put back into the UNEVICTABLE_LRU, thus causing a
subsequent and immediate PFN flag check for the UNEVICTABLE bit
to trip on false-negative errors, as it happens with this test.
This patch fix the false negative by forcefully resorting to a code path that
will call a CPU pagevec drain right after the fault but before the PFN flag
check takes place, sorting out the race that way.
Fixes: 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pagevecs")
Signed-off-by: Rafael Aquini <aquini(a)redhat.com>
---
tools/testing/selftests/vm/mlock2-tests.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/tools/testing/selftests/vm/mlock2-tests.c b/tools/testing/selftests/vm/mlock2-tests.c
index 637b6d0ac0d0..26dc320ca3c9 100644
--- a/tools/testing/selftests/vm/mlock2-tests.c
+++ b/tools/testing/selftests/vm/mlock2-tests.c
@@ -7,6 +7,7 @@
#include <sys/time.h>
#include <sys/resource.h>
#include <stdbool.h>
+#include <sched.h>
#include "mlock2.h"
#include "../kselftest.h"
@@ -328,6 +329,22 @@ static int test_mlock_lock()
return ret;
}
+/*
+ * After commit 9c4e6b1a7027f ("mm, mlock, vmscan: no more skipping pagevecs")
+ * changes made by calls to mlock* family might not be immediately reflected
+ * on the LRUs, thus checking the PFN flags might race against pagevec drain.
+ *
+ * In order to sort out that race, and get the after fault checks consistent,
+ * the "quick and dirty" trick below is required in order to force a call to
+ * lru_add_drain_all() to get the recently MLOCK_ONFAULT pages moved to
+ * the unevictable LRU, as expected by the checks in this selftest.
+ */
+static void force_lru_add_drain_all(void)
+{
+ sched_yield();
+ system("echo 1 > /proc/sys/vm/compact_memory");
+}
+
static int onfault_check(char *map)
{
unsigned long page_size = getpagesize();
@@ -343,6 +360,9 @@ static int onfault_check(char *map)
}
*map = 'a';
+
+ force_lru_add_drain_all();
+
page1_flags = get_pageflags((unsigned long)map);
page2_flags = get_pageflags((unsigned long)map + page_size);
@@ -465,6 +485,8 @@ static int test_lock_onfault_of_present()
goto unmap;
}
+ force_lru_add_drain_all();
+
page1_flags = get_pageflags((unsigned long)map);
page2_flags = get_pageflags((unsigned long)map + page_size);
page1_flags = get_kpageflags(page1_flags & PFN_MASK);
--
2.24.1