On Fri, Mar 02, 2018 at 12:09:57PM -0800, Gianluca Borello wrote:
> Hello,
>
> While testing bpf-next, I noticed that I was reading garbage when
> accessing some task_struct members, and the issue seems caused by the
> recent commit 2bc2f688fdf8 ("Makefile: move stack-protector
> availability out of Kconfig") which removes CONFIG_CC_STACKPROTECTOR
> from autoconf.h.
>
> When I compile my BPF program, offsetof(struct task_struct, files),
> which is the member I'm dereferencing, returns 1768 (where the garbage
> is), whereas doing it on 4.15 returns 1776 (where the correct member
> is). I believe when compiling with clang this portion of the
> task_struct doesn't get considered anymore:
>
> #ifdef CONFIG_CC_STACKPROTECTOR
> /* Canary value for the -fstack-protector GCC feature: */
> unsigned long stack_canary;
> #endif
>
> I solved it by adding $(KBUILD_CPPFLAGS) to my BPF Makefile (which is
> pretty similar to the one used in samples/bpf/Makefile).
>
> Two questions:
>
> 1) Do you confirm this is the proper way to handle this moving
> forward? Or should there be a better way?
>
> 2) Would you consider useful a simple patch to samples/bpf/Makefile so
> that other developers will not be stuck in a long bisect to figure out
> why they read garbage when dereferencing task_struct? I assume that
> several people use that Makefile as a template to start their project,
> like I did (perhaps I'm assuming wrong though).
good catch!
I wonder why sched.h is using this flag insead of relying on #defines from
autoconf.h
It could have been using CONFIG_HAVE_CC_STACKPROTECTOR
instead of CONFIG_CC_STACKPROTECTOR, no ?
