Y Song, thank you very much for your detailed feedback.

Let me focus on the specific wakeuptime.py failure since that seems to be
my biggest blocker at the moment:

>   File "../../tools/wakeuptime.py", line 216, in <module>
> >     print("    %-16s %s" % ("target:", k.target.decode()))
> > UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0:
> > ordinal not in range(128)
>
> Maybe this is a real issue related to python 2/3 compatibility, could
> you help take a look?
>

It looks like this is a known issue. According to
https://github.com/iovisor/bcc/blob/master/docs/reference_guide.md#7-bpf_get_current_task
:

With Linux 4.13, due to issues with field randomization, you may need two
> #define directives before the includes:
> #define randomized_struct_fields_start  struct {
> #define randomized_struct_fields_end    };
> #include <linux/sched.h>
> int do_trace(void *ctx) {
>     struct task_struct *t = (struct task_struct *)bpf_get_current_task();
> [...]


And indeed that fixed the wakeuptime tool. For now, this patch seems to do
the trick on this kernel (the undefs just get rid of some warnings):

diff --git a/tools/wakeuptime.py b/tools/wakeuptime.py
index cf0ca7d..3f6fd67 100755
--- a/tools/wakeuptime.py
+++ b/tools/wakeuptime.py
@@ -86,6 +86,10 @@ def signal_ignore(signal, frame):

 # define BPF program
 bpf_text = """
+#undef randomized_struct_fields_start
+#undef randomized_struct_fields_end
+#define randomized_struct_fields_start  struct {
+#define randomized_struct_fields_end    };
 #include <uapi/linux/ptrace.h>
 #include <linux/sched.h>

It appears that same workaround is also needed for many other tools in the
repo to work correctly on this kernel.

I was looking around at the kernel 4.13 release notes and I found the
RANDSTRUCT patch <
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=313dd1b629219db50cad532dba6a3b3b22ffe622>
but I'm not sure that is what I'm hitting here since I didn't find a
reference to it in my kernel config. Any ideas about the root cause for
this workaround and if this is a permanent issue with kernels after 4.13?
If so, then I suppose we should find a more maintainable way of injecting
that workaround automatically in the BPF class, or find a more permanent
workaround for bcc.

Thoughts?

Thanks again,
Mike
_______________________________________________
iovisor-dev mailing list
[email protected]
https://lists.iovisor.org/mailman/listinfo/iovisor-dev

Reply via email to