bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Sasha Levin" <sashal@kernel.org>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	clang-built-linux@googlegroups.com
Subject: [PATCH AUTOSEL 5.4 186/459] samples/bpf: Set -fno-stack-protector when building BPF programs
Date: Fri, 14 Feb 2020 10:57:16 -0500	[thread overview]
Message-ID: <20200214160149.11681-186-sashal@kernel.org> (raw)
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>

From: Toke Høiland-Jørgensen <toke@redhat.com>

[ Upstream commit 450278977acbf494a20367c22fbb38729772d1fc ]

It seems Clang can in some cases turn on stack protection by default, which
doesn't work with BPF. This was reported once before[0], but it seems the
flag to explicitly turn off the stack protector wasn't added to the
Makefile, so do that now.

The symptom of this is compile errors like the following:

error: <unknown>:0:0: in function bpf_prog1 i32 (%struct.__sk_buff*): A call to built-in function '__stack_chk_fail' is not supported.

[0] https://www.spinics.net/lists/netdev/msg556400.html

Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20191216103819.359535-1-toke@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 samples/bpf/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index e7ad48c605e0f..6d1df7117e117 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -219,6 +219,7 @@ BTF_LLVM_PROBE := $(shell echo "int main() { return 0; }" | \
 			  readelf -S ./llvm_btf_verify.o | grep BTF; \
 			  /bin/rm -f ./llvm_btf_verify.o)
 
+BPF_EXTRA_CFLAGS += -fno-stack-protector
 ifneq ($(BTF_LLVM_PROBE),)
 	EXTRA_CFLAGS += -g
 else
-- 
2.20.1


  parent reply	other threads:[~2020-02-14 16:05 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200214160149.11681-1-sashal@kernel.org>
2020-02-14 15:56 ` [PATCH AUTOSEL 5.4 114/459] bpftool: Don't crash on missing xlated program instructions Sasha Levin
2020-02-14 15:56 ` [PATCH AUTOSEL 5.4 115/459] bpf, sockhash: Synchronize_rcu before free'ing map Sasha Levin
2020-02-14 15:56 ` [PATCH AUTOSEL 5.4 116/459] bpf, sockmap: Check update requirements after locking Sasha Levin
2020-02-14 15:56 ` [PATCH AUTOSEL 5.4 117/459] bpf: Improve bucket_log calculation logic Sasha Levin
2020-02-14 15:56 ` [PATCH AUTOSEL 5.4 118/459] bpf, sockmap: Don't sleep while holding RCU lock on tear-down Sasha Levin
2020-02-14 15:57 ` Sasha Levin [this message]
2020-02-14 15:57 ` [PATCH AUTOSEL 5.4 227/459] bpf: Print error message for bpftool cgroup show Sasha Levin
2020-02-14 15:58 ` [PATCH AUTOSEL 5.4 248/459] tools lib api fs: Fix gcc9 stringop-truncation compilation error Sasha Levin
2020-02-14 15:59 ` [PATCH AUTOSEL 5.4 307/459] bpf: Return -EBADRQC for invalid map type in __bpf_tx_xdp_map Sasha Levin
2020-02-14 16:00 ` [PATCH AUTOSEL 5.4 376/459] bpf, btf: Always output invariant hit in pahole DWARF to BTF transform Sasha Levin
2020-02-14 16:00 ` [PATCH AUTOSEL 5.4 397/459] selftests: bpf: Reset global state between reuseport test runs Sasha Levin
2020-02-14 16:01 ` [PATCH AUTOSEL 5.4 415/459] bpf: map_seq_next should always increase position index Sasha Levin
2020-02-14 16:01 ` [PATCH AUTOSEL 5.4 430/459] powerpc: Do not consider weak unresolved symbol relocations as bad Sasha Levin
2020-02-14 16:01 ` [PATCH AUTOSEL 5.4 455/459] i40e: Relax i40e_xsk_wakeup's return value when PF is busy Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200214160149.11681-186-sashal@kernel.org \
    --to=sashal@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=clang-built-linux@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=toke@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).