[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <fbfed65c-f40e-bb07-1b82-a6af2cfe3bdf@linux.vnet.ibm.com>
Date: Mon, 6 Nov 2017 10:46:46 +0530
From: Sandipan Das <sandipan@...ux.vnet.ibm.com>
To: "Naveen N. Rao" <naveen.n.rao@...ux.vnet.ibm.com>,
Alexei Starovoitov <ast@...com>, netdev@...r.kernel.org
Cc: daniel@...earbox.net, Martin KaFai Lau <kafai@...com>,
linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
Brendan Gregg <brendan.d.gregg@...il.com>
Subject: Re: [RFC PATCH] bpf: Add helpers to read useful task_struct members
Hi Alexei, Naveen,
On 11/04/2017 11:01 PM, Naveen N. Rao wrote:
>
> I think the offsets described in dwarf were incorrect with CONFIG_GCC_PLUGIN_RANDSTRUCT, but I'll let Sandipan confirm that.
>
I think that the offsets described in dwarf are probably incorrect when
CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled. To verify this, I used perf
to attach a probe to try_to_wake_up() which is the also the function to
which waker() is attached in the previously mentioned kernel sample. So,
if the run the following:
# perf probe "try_to_wake_up" "p->pid"
# perf record -a -e probe:try_to_wake_up
# perf script
The value of p->pid is reported as 0. Similarly, if I try to read
p->comm, it is reported to be an empty string. The same problem is
seen with systemtap as well.
Also, if I do a printk with offsetof(struct task_struct, pid) and
offsetof(struct task_struct, comm) inside the kernel code and then
compare the values with the offsets reported by pahole, they are
completely different.
- Sandipan
Powered by blists - more mailing lists