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 ?