* [PATCH net-next 2/8] bpf: don't check spilled reg state for non-STACK_SPILLed type slots
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
spilled_regs[] state is only used for stack slots of type STACK_SPILL,
never for STACK_MISC. Right now, in states_equal(), even if we have
old and current stack state of type STACK_MISC, we compare spilled_regs[]
for that particular offset. Just skip these like we do everywhere else.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 14ccb07..d031b3b 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -2828,6 +2828,8 @@ static bool states_equal(struct bpf_verifier_env *env,
return false;
if (i % BPF_REG_SIZE)
continue;
+ if (old->stack_slot_type[i] != STACK_SPILL)
+ continue;
if (memcmp(&old->spilled_regs[i / BPF_REG_SIZE],
&cur->spilled_regs[i / BPF_REG_SIZE],
sizeof(old->spilled_regs[0])))
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 0/8] Misc BPF updates
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
This set contains a couple of misc updates: stack usage reduction
for perf_sample_data in tracing progs, reduction of stale data in
verifier on register state transitions that I still had in my queue
and few selftest improvements as well as bpf_set_hash() helper for
tc programs.
Thanks!
Daniel Borkmann (8):
bpf: avoid excessive stack usage for perf_sample_data
bpf: don't check spilled reg state for non-STACK_SPILLed type slots
bpf: reset id on CONST_IMM transition
bpf: reset id on spilled regs in clear_all_pkt_pointers
bpf, tests: add a test for htab lookup + update traversal
bpf, tests: set rlimit also for test_align, so it doesn't fail
bpf: remove cg_skb_func_proto and use sk_filter_func_proto directly
bpf: add bpf_set_hash helper for tc progs
include/uapi/linux/bpf.h | 8 ++++-
kernel/bpf/verifier.c | 8 +++--
kernel/trace/bpf_trace.c | 10 ++++---
net/core/filter.c | 28 +++++++++++++-----
tools/include/uapi/linux/bpf.h | 8 ++++-
tools/testing/selftests/bpf/test_align.c | 5 ++++
tools/testing/selftests/bpf/test_maps.c | 50 ++++++++++++++++++++++++++++++++
7 files changed, 102 insertions(+), 15 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH net-next 1/8] bpf: avoid excessive stack usage for perf_sample_data
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
perf_sample_data consumes 386 bytes on stack, reduce excessive stack
usage and move it to per cpu buffer. It's allowed due to preemption
being disabled for tracing, xdp and tc programs, thus at all times
only one program can run on a specific CPU and programs cannot run
from interrupt. We similarly also handle bpf_pt_regs.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/trace/bpf_trace.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index 08eb072..051d7fc 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -266,14 +266,16 @@ const struct bpf_func_proto *bpf_get_trace_printk_proto(void)
.arg2_type = ARG_ANYTHING,
};
+static DEFINE_PER_CPU(struct perf_sample_data, bpf_sd);
+
static __always_inline u64
__bpf_perf_event_output(struct pt_regs *regs, struct bpf_map *map,
u64 flags, struct perf_raw_record *raw)
{
struct bpf_array *array = container_of(map, struct bpf_array, map);
+ struct perf_sample_data *sd = this_cpu_ptr(&bpf_sd);
unsigned int cpu = smp_processor_id();
u64 index = flags & BPF_F_INDEX_MASK;
- struct perf_sample_data sample_data;
struct bpf_event_entry *ee;
struct perf_event *event;
@@ -294,9 +296,9 @@ const struct bpf_func_proto *bpf_get_trace_printk_proto(void)
if (unlikely(event->oncpu != cpu))
return -EOPNOTSUPP;
- perf_sample_data_init(&sample_data, 0, 0);
- sample_data.raw = raw;
- perf_event_output(event, &sample_data, regs);
+ perf_sample_data_init(sd, 0, 0);
+ sd->raw = raw;
+ perf_event_output(event, sd, regs);
return 0;
}
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 3/8] bpf: reset id on CONST_IMM transition
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
Whenever we set the register to the type CONST_IMM, we currently don't
reset the id to 0. id member is not used in CONST_IMM case, so don't
let it become stale, where pruning won't be able to match later on.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d031b3b..d195d82 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1952,6 +1952,7 @@ static int check_alu_op(struct bpf_verifier_env *env, struct bpf_insn *insn)
*/
regs[insn->dst_reg].type = CONST_IMM;
regs[insn->dst_reg].imm = insn->imm;
+ regs[insn->dst_reg].id = 0;
regs[insn->dst_reg].max_value = insn->imm;
regs[insn->dst_reg].min_value = insn->imm;
regs[insn->dst_reg].min_align = calc_align(insn->imm);
@@ -2409,6 +2410,7 @@ static int check_ld_imm(struct bpf_verifier_env *env, struct bpf_insn *insn)
regs[insn->dst_reg].type = CONST_IMM;
regs[insn->dst_reg].imm = imm;
+ regs[insn->dst_reg].id = 0;
return 0;
}
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 5/8] bpf, tests: add a test for htab lookup + update traversal
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
Add a test case to track behaviour when traversing and updating the
htab map. We recently used such traversal, so it's quite useful to
keep it as an example in selftests.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/test_maps.c | 50 +++++++++++++++++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selftests/bpf/test_maps.c
index 9331452..79601c8 100644
--- a/tools/testing/selftests/bpf/test_maps.c
+++ b/tools/testing/selftests/bpf/test_maps.c
@@ -239,6 +239,54 @@ static void test_hashmap_percpu(int task, void *data)
close(fd);
}
+static void test_hashmap_walk(int task, void *data)
+{
+ int fd, i, max_entries = 100000;
+ long long key, value, next_key;
+ bool next_key_valid = true;
+
+ fd = bpf_create_map(BPF_MAP_TYPE_HASH, sizeof(key), sizeof(value),
+ max_entries, map_flags);
+ if (fd < 0) {
+ printf("Failed to create hashmap '%s'!\n", strerror(errno));
+ exit(1);
+ }
+
+ for (i = 0; i < max_entries; i++) {
+ key = i; value = key;
+ assert(bpf_map_update_elem(fd, &key, &value, BPF_NOEXIST) == 0);
+ }
+
+ for (i = 0; bpf_map_get_next_key(fd, !i ? NULL : &key,
+ &next_key) == 0; i++) {
+ key = next_key;
+ assert(bpf_map_lookup_elem(fd, &key, &value) == 0);
+ }
+
+ assert(i == max_entries);
+
+ assert(bpf_map_get_next_key(fd, NULL, &key) == 0);
+ for (i = 0; next_key_valid; i++) {
+ next_key_valid = bpf_map_get_next_key(fd, &key, &next_key) == 0;
+ assert(bpf_map_lookup_elem(fd, &key, &value) == 0);
+ value++;
+ assert(bpf_map_update_elem(fd, &key, &value, BPF_EXIST) == 0);
+ key = next_key;
+ }
+
+ assert(i == max_entries);
+
+ for (i = 0; bpf_map_get_next_key(fd, !i ? NULL : &key,
+ &next_key) == 0; i++) {
+ key = next_key;
+ assert(bpf_map_lookup_elem(fd, &key, &value) == 0);
+ assert(value - 1 == key);
+ }
+
+ assert(i == max_entries);
+ close(fd);
+}
+
static void test_arraymap(int task, void *data)
{
int key, next_key, fd;
@@ -464,6 +512,7 @@ static void test_map_stress(void)
run_parallel(100, test_hashmap, NULL);
run_parallel(100, test_hashmap_percpu, NULL);
run_parallel(100, test_hashmap_sizes, NULL);
+ run_parallel(100, test_hashmap_walk, NULL);
run_parallel(100, test_arraymap, NULL);
run_parallel(100, test_arraymap_percpu, NULL);
@@ -549,6 +598,7 @@ static void run_all_tests(void)
{
test_hashmap(0, NULL);
test_hashmap_percpu(0, NULL);
+ test_hashmap_walk(0, NULL);
test_arraymap(0, NULL);
test_arraymap_percpu(0, NULL);
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 4/8] bpf: reset id on spilled regs in clear_all_pkt_pointers
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
Right now, we don't reset the id of spilled registers in case of
clear_all_pkt_pointers(). Given pkt_pointers are highly likely to
contain an id, do so by reusing __mark_reg_unknown_value().
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
kernel/bpf/verifier.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index d195d82..519a614 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1346,8 +1346,8 @@ static void clear_all_pkt_pointers(struct bpf_verifier_env *env)
if (reg->type != PTR_TO_PACKET &&
reg->type != PTR_TO_PACKET_END)
continue;
- reg->type = UNKNOWN_VALUE;
- reg->imm = 0;
+ __mark_reg_unknown_value(state->spilled_regs,
+ i / BPF_REG_SIZE);
}
}
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 7/8] bpf: remove cg_skb_func_proto and use sk_filter_func_proto directly
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
Since cg_skb_func_proto() doesn't do anything else than just calling
into sk_filter_func_proto(), remove it and set sk_filter_func_proto()
directly for .get_func_proto callback.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
net/core/filter.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/net/core/filter.c b/net/core/filter.c
index 946f758..4867391 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2775,12 +2775,6 @@ static unsigned long bpf_xdp_copy(void *dst_buff, const void *src_buff,
}
static const struct bpf_func_proto *
-cg_skb_func_proto(enum bpf_func_id func_id)
-{
- return sk_filter_func_proto(func_id);
-}
-
-static const struct bpf_func_proto *
lwt_inout_func_proto(enum bpf_func_id func_id)
{
switch (func_id) {
@@ -3344,7 +3338,7 @@ static u32 xdp_convert_ctx_access(enum bpf_access_type type,
};
const struct bpf_verifier_ops cg_skb_prog_ops = {
- .get_func_proto = cg_skb_func_proto,
+ .get_func_proto = sk_filter_func_proto,
.is_valid_access = sk_filter_is_valid_access,
.convert_ctx_access = bpf_convert_ctx_access,
.test_run = bpf_prog_test_run_skb,
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 6/8] bpf, tests: set rlimit also for test_align, so it doesn't fail
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
When running all the tests, through 'make run_tests', I had
test_align failing due to insufficient rlimit. Set it the same
way as all other test cases from BPF selftests do, so that
test case properly loads everything.
[...]
Summary: 7 PASSED, 1 FAILED
selftests: test_progs [PASS]
/home/foo/net-next/tools/testing/selftests/bpf
Test 0: mov ... Failed to load program.
FAIL
Test 1: shift ... Failed to load program.
FAIL
Test 2: addsub ... Failed to load program.
FAIL
Test 3: mul ... Failed to load program.
FAIL
Test 4: unknown shift ... Failed to load program.
FAIL
Test 5: unknown mul ... Failed to load program.
FAIL
Test 6: packet const offset ... Failed to load program.
FAIL
Test 7: packet variable offset ... Failed to load program.
FAIL
Results: 0 pass 8 fail
selftests: test_align [PASS]
[...]
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
tools/testing/selftests/bpf/test_align.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_align.c b/tools/testing/selftests/bpf/test_align.c
index 9644d4e..1426594 100644
--- a/tools/testing/selftests/bpf/test_align.c
+++ b/tools/testing/selftests/bpf/test_align.c
@@ -9,6 +9,8 @@
#include <stddef.h>
#include <stdbool.h>
+#include <sys/resource.h>
+
#include <linux/unistd.h>
#include <linux/filter.h>
#include <linux/bpf_perf_event.h>
@@ -432,6 +434,9 @@ static int do_test(unsigned int from, unsigned int to)
int main(int argc, char **argv)
{
unsigned int from = 0, to = ARRAY_SIZE(tests);
+ struct rlimit rinf = { RLIM_INFINITY, RLIM_INFINITY };
+
+ setrlimit(RLIMIT_MEMLOCK, &rinf);
if (argc == 3) {
unsigned int l = atoi(argv[argc - 2]);
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 8/8] bpf: add bpf_set_hash helper for tc progs
From: Daniel Borkmann @ 2017-06-10 22:50 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, Daniel Borkmann
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
Allow for tc BPF programs to set a skb->hash, apart from clearing
and triggering a recalc that we have right now. It allows for BPF
to implement a custom hashing routine for skb_get_hash().
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
include/uapi/linux/bpf.h | 8 +++++++-
net/core/filter.c | 20 ++++++++++++++++++++
tools/include/uapi/linux/bpf.h | 8 +++++++-
3 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 9b2c10b..f94b48b 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -513,6 +513,11 @@ enum bpf_attach_type {
* Get the owner uid of the socket stored inside sk_buff.
* @skb: pointer to skb
* Return: uid of the socket owner on success or overflowuid if failed.
+ *
+ * u32 bpf_set_hash(skb, hash)
+ * Set full skb->hash.
+ * @skb: pointer to skb
+ * @hash: hash to set
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -562,7 +567,8 @@ enum bpf_attach_type {
FN(xdp_adjust_head), \
FN(probe_read_str), \
FN(get_socket_cookie), \
- FN(get_socket_uid),
+ FN(get_socket_uid), \
+ FN(set_hash),
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
diff --git a/net/core/filter.c b/net/core/filter.c
index 4867391..a65a3b2 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -1874,6 +1874,24 @@ int skb_do_redirect(struct sk_buff *skb)
.arg1_type = ARG_PTR_TO_CTX,
};
+BPF_CALL_2(bpf_set_hash, struct sk_buff *, skb, u32, hash)
+{
+ /* Set user specified hash as L4(+), so that it gets returned
+ * on skb_get_hash() call unless BPF prog later on triggers a
+ * skb_clear_hash().
+ */
+ __skb_set_sw_hash(skb, hash, true);
+ return 0;
+}
+
+static const struct bpf_func_proto bpf_set_hash_proto = {
+ .func = bpf_set_hash,
+ .gpl_only = false,
+ .ret_type = RET_INTEGER,
+ .arg1_type = ARG_PTR_TO_CTX,
+ .arg2_type = ARG_ANYTHING,
+};
+
BPF_CALL_3(bpf_skb_vlan_push, struct sk_buff *, skb, __be16, vlan_proto,
u16, vlan_tci)
{
@@ -2744,6 +2762,8 @@ static unsigned long bpf_xdp_copy(void *dst_buff, const void *src_buff,
return &bpf_get_hash_recalc_proto;
case BPF_FUNC_set_hash_invalid:
return &bpf_set_hash_invalid_proto;
+ case BPF_FUNC_set_hash:
+ return &bpf_set_hash_proto;
case BPF_FUNC_perf_event_output:
return &bpf_skb_event_output_proto;
case BPF_FUNC_get_smp_processor_id:
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 9b2c10b..f94b48b 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -513,6 +513,11 @@ enum bpf_attach_type {
* Get the owner uid of the socket stored inside sk_buff.
* @skb: pointer to skb
* Return: uid of the socket owner on success or overflowuid if failed.
+ *
+ * u32 bpf_set_hash(skb, hash)
+ * Set full skb->hash.
+ * @skb: pointer to skb
+ * @hash: hash to set
*/
#define __BPF_FUNC_MAPPER(FN) \
FN(unspec), \
@@ -562,7 +567,8 @@ enum bpf_attach_type {
FN(xdp_adjust_head), \
FN(probe_read_str), \
FN(get_socket_cookie), \
- FN(get_socket_uid),
+ FN(get_socket_uid), \
+ FN(set_hash),
/* integer value in 'imm' field of BPF_CALL instruction selects which helper
* function eBPF program intends to call
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix
From: David Miller @ 2017-06-10 22:58 UTC (permalink / raw)
To: colona; +Cc: eric.dumazet, netdev, linux-kernel
In-Reply-To: <20170610021449.16091-2-colona@arista.com>
From: Ivan Delalande <colona@arista.com>
Date: Fri, 9 Jun 2017 19:14:49 -0700
> Add a flag field and address prefix length at the end of the tcp_md5sig
> structure so users can configure an address prefix length along with a
> key. Make sure shorter option values are still accepted in
> tcp_v4_parse_md5_keys and tcp_v6_parse_md5_keys to maintain backward
> compatibility.
>
> Signed-off-by: Bob Gilligan <gilligan@arista.com>
> Signed-off-by: Eric Mowat <mowat@arista.com>
> Signed-off-by: Ivan Delalande <colona@arista.com>
As I believe was previously stated, the problem with this approach is
that if a new tool requests the prefix length and is run on an older
kernel, the kernel will return success even though the prefix length
was not taken into account.
We do not want to get a success back when the operation requested was
not performed.
^ permalink raw reply
* Re: [PATCH net-next 1/1] net: reflect mark on tcp syn ack packets
From: David Miller @ 2017-06-10 23:02 UTC (permalink / raw)
To: jhs; +Cc: netdev, lorenzo, mrv, hadi
In-Reply-To: <1497101461-20921-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sat, 10 Jun 2017 09:31:01 -0400
> diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
> index 7a3fd25..a8fd5f0 100644
> --- a/net/ipv4/ip_output.c
> +++ b/net/ipv4/ip_output.c
> @@ -173,7 +173,8 @@ int ip_build_and_send_pkt(struct sk_buff *skb, const struct sock *sk,
> }
>
> skb->priority = sk->sk_priority;
> - skb->mark = sk->sk_mark;
> + if (!skb->mark)
> + skb->mark = sk->sk_mark;
Maybe this should both be "inet_request_mark()"?
Also, Lorenzo, please review.
^ permalink raw reply
* Re: [PATCH net-next 0/8] Misc BPF updates
From: David Miller @ 2017-06-10 23:06 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev
In-Reply-To: <cover.1497133948.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Sun, 11 Jun 2017 00:50:39 +0200
> This set contains a couple of misc updates: stack usage reduction
> for perf_sample_data in tracing progs, reduction of stale data in
> verifier on register state transitions that I still had in my queue
> and few selftest improvements as well as bpf_set_hash() helper for
> tc programs.
Series applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
From: David Miller @ 2017-06-10 23:07 UTC (permalink / raw)
To: sharpd; +Cc: netdev, dsahern, Thomas.Winter, nikolay, yotamg, idosch, roopa
In-Reply-To: <20170610203017.4085-1-sharpd@cumulusnetworks.com>
From: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Sat, 10 Jun 2017 16:30:17 -0400
> This patch fixes two issues:
>
> 1) When forwarding on *,G mroutes that are in a vrf, the
> kernel was dropping information about the actual incoming
> interface when calling ip_mr_forward from ip_mr_input.
> This caused ip_mr_forward to send the multicast packet
> back out the incoming interface. Fix this by
> modifying ip_mr_forward to be handed the correctly
> resolved dev.
>
> 2) When a unresolved cache entry is created we store
> the incoming skb on the unresolved cache entry and
> upon mroute resolution from the user space daemon,
> we attempt to forward the packet. Again we were
> not resolving to the correct incoming device for
> a vrf scenario, before calling ip_mr_forward.
> Fix this by resolving to the correct interface
> and calling ip_mr_forward with the result.
>
> Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David, please review.
^ permalink raw reply
* Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
From: David Ahern @ 2017-06-10 23:32 UTC (permalink / raw)
To: Donald Sharp, netdev, Thomas.Winter, nikolay, yotamg, idosch,
roopa
In-Reply-To: <20170610203017.4085-1-sharpd@cumulusnetworks.com>
On 6/10/17 2:30 PM, Donald Sharp wrote:
> This patch fixes two issues:
>
> 1) When forwarding on *,G mroutes that are in a vrf, the
> kernel was dropping information about the actual incoming
> interface when calling ip_mr_forward from ip_mr_input.
> This caused ip_mr_forward to send the multicast packet
> back out the incoming interface. Fix this by
> modifying ip_mr_forward to be handed the correctly
> resolved dev.
>
> 2) When a unresolved cache entry is created we store
> the incoming skb on the unresolved cache entry and
> upon mroute resolution from the user space daemon,
> we attempt to forward the packet. Again we were
> not resolving to the correct incoming device for
> a vrf scenario, before calling ip_mr_forward.
> Fix this by resolving to the correct interface
> and calling ip_mr_forward with the result.
>
> Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> v2: Fixed title
> v3: Addressed Review comments by Andrew Lunn and David Ahern
>
LGTM.
Acked-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
From: David Ahern @ 2017-06-10 23:33 UTC (permalink / raw)
To: David Miller, sharpd
Cc: netdev, Thomas.Winter, nikolay, yotamg, idosch, roopa
In-Reply-To: <20170610.190759.166589591911771854.davem@davemloft.net>
On 6/10/17 5:07 PM, David Miller wrote:
> From: Donald Sharp <sharpd@cumulusnetworks.com>
> Date: Sat, 10 Jun 2017 16:30:17 -0400
>
>> This patch fixes two issues:
>>
>> 1) When forwarding on *,G mroutes that are in a vrf, the
>> kernel was dropping information about the actual incoming
>> interface when calling ip_mr_forward from ip_mr_input.
>> This caused ip_mr_forward to send the multicast packet
>> back out the incoming interface. Fix this by
>> modifying ip_mr_forward to be handed the correctly
>> resolved dev.
>>
>> 2) When a unresolved cache entry is created we store
>> the incoming skb on the unresolved cache entry and
>> upon mroute resolution from the user space daemon,
>> we attempt to forward the packet. Again we were
>> not resolving to the correct incoming device for
>> a vrf scenario, before calling ip_mr_forward.
>> Fix this by resolving to the correct interface
>> and calling ip_mr_forward with the result.
>>
>> Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
>> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
>
> David, please review.
>
Responded. Would be good for the Mellanox team (and Thomas) to chime in
as well.
^ permalink raw reply
* Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
From: Thomas Winter @ 2017-06-10 23:39 UTC (permalink / raw)
To: David Ahern, David Miller, sharpd@cumulusnetworks.com
Cc: netdev@vger.kernel.org, nikolay@cumulusnetworks.com,
yotamg@mellanox.com, idosch@mellanox.com,
roopa@cumulusnetworks.com
In-Reply-To: <a7d1c403-408c-d8ec-d552-ee417be68b50@gmail.com>
I don't think we've seen this issue but patch looks good.
________________________________________
From: David Ahern <dsahern@gmail.com>
Sent: 11 June 2017 11:33
To: David Miller; sharpd@cumulusnetworks.com
Cc: netdev@vger.kernel.org; Thomas Winter; nikolay@cumulusnetworks.com; yotamg@mellanox.com; idosch@mellanox.com; roopa@cumulusnetworks.com
Subject: Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
On 6/10/17 5:07 PM, David Miller wrote:
> From: Donald Sharp <sharpd@cumulusnetworks.com>
> Date: Sat, 10 Jun 2017 16:30:17 -0400
>
>> This patch fixes two issues:
>>
>> 1) When forwarding on *,G mroutes that are in a vrf, the
>> kernel was dropping information about the actual incoming
>> interface when calling ip_mr_forward from ip_mr_input.
>> This caused ip_mr_forward to send the multicast packet
>> back out the incoming interface. Fix this by
>> modifying ip_mr_forward to be handed the correctly
>> resolved dev.
>>
>> 2) When a unresolved cache entry is created we store
>> the incoming skb on the unresolved cache entry and
>> upon mroute resolution from the user space daemon,
>> we attempt to forward the packet. Again we were
>> not resolving to the correct incoming device for
>> a vrf scenario, before calling ip_mr_forward.
>> Fix this by resolving to the correct interface
>> and calling ip_mr_forward with the result.
>>
>> Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
>> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
>
> David, please review.
>
Responded. Would be good for the Mellanox team (and Thomas) to chime in
as well.
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH] i40evf: remove redundant null check on key
From: Alexander Duyck @ 2017-06-10 23:44 UTC (permalink / raw)
To: Dan Carpenter
Cc: Colin King, Netdev, kernel-janitors, intel-wired-lan,
linux-kernel@vger.kernel.org
In-Reply-To: <20170610113342.f4v5j3inpoxwqkhf@mwanda>
On Sat, Jun 10, 2017 at 4:33 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> This patch isn't right...
>
> On Wed, Jun 07, 2017 at 12:54:07AM +0100, Colin King wrote:
>> From: Colin Ian King <colin.king@canonical.com>
>>
>> key has previously been null checked so the subsequent null check
>> is redundant as key can never be null at that point, so remove it.
>>
>
> Actually, it's the reverse. "key" is always NULL. Probably the ||
> should be a &&?
>
> regards,
> dan carpenter
Actually the original code and the patched version are still both
broken, but it is more broken with the patch. With this change I am
pretty sure we will kernel panic if we use the ethtool ioctl for
ETHTOOL_SRXFHINDIR, or don't update the key when updating other fields
in the flow hash.
So the original logic here looks like a bad copy of code from igb.
There it doesn't support updating the key so if key is set we are
supposed to be returning an error since key update isn't currently
supported. So the check for key at the start of this function should
probably be dropped instead of the second check. From what I can tell
the original code prevents key from ever being updated since if key is
non-null it means we want to update the key.
- Alex
^ permalink raw reply
* Re: [PATCH net v3] net: ipmr: Fix some mroute forwarding issues in vrf's
From: Nikolay Aleksandrov @ 2017-06-11 0:21 UTC (permalink / raw)
To: Donald Sharp, netdev, dsahern, Thomas.Winter, yotamg, idosch,
roopa
In-Reply-To: <20170610203017.4085-1-sharpd@cumulusnetworks.com>
On 10/06/17 23:30, Donald Sharp wrote:
> This patch fixes two issues:
>
> 1) When forwarding on *,G mroutes that are in a vrf, the
> kernel was dropping information about the actual incoming
> interface when calling ip_mr_forward from ip_mr_input.
> This caused ip_mr_forward to send the multicast packet
> back out the incoming interface. Fix this by
> modifying ip_mr_forward to be handed the correctly
> resolved dev.
>
> 2) When a unresolved cache entry is created we store
> the incoming skb on the unresolved cache entry and
> upon mroute resolution from the user space daemon,
> we attempt to forward the packet. Again we were
> not resolving to the correct incoming device for
> a vrf scenario, before calling ip_mr_forward.
> Fix this by resolving to the correct interface
> and calling ip_mr_forward with the result.
>
> Fixes: e58e41596811 ("net: Enable support for VRF with ipv4 multicast")
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
> ---
> v2: Fixed title
> v3: Addressed Review comments by Andrew Lunn and David Ahern
>
Looks good, thanks!
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
^ permalink raw reply
* Re: [PATCHv2 net] net/flow: fix fc->percpu NULL pointer dereference
From: Hangbin Liu @ 2017-06-11 1:39 UTC (permalink / raw)
To: Xin Long; +Cc: network dev
In-Reply-To: <CADvbK_dBuJKymP6tT358EEN2Qg6s+f8Sj8z-UN6ypdoDNcp-dA@mail.gmail.com>
On Sat, Jun 10, 2017 at 04:29:23PM +0800, Xin Long wrote:
> It's a xfrm fix, pls also fix the title, like:
> xfrm: move xfrm_garbage_collect out of xfrm_policy_flush
> or
> xfrm: fix ...
Opps, sorry forgot that.
^ permalink raw reply
* [PATCHv3 net] xfrm: move xfrm_garbage_collect out of xfrm_policy_flush
From: Hangbin Liu @ 2017-06-11 1:44 UTC (permalink / raw)
To: netdev; +Cc: David Miller, Xin Long, Steffen Klassert, Hangbin Liu
In-Reply-To: <1497013755-24481-1-git-send-email-liuhangbin@gmail.com>
Now we will force to do garbage collection if any policy removed in
xfrm_policy_flush(). But during xfrm_net_exit(). We call flow_cache_fini()
first and set set fc->percpu to NULL. Then after we call xfrm_policy_fini()
-> frxm_policy_flush() -> flow_cache_flush(), we will get NULL pointer
dereference when check percpu_empty. The code path looks like:
flow_cache_fini()
- fc->percpu = NULL
xfrm_policy_fini()
- xfrm_policy_flush()
- xfrm_garbage_collect()
- flow_cache_flush()
- flow_cache_percpu_empty()
- fcp = per_cpu_ptr(fc->percpu, cpu)
To reproduce, just add ipsec in netns and then remove the netns.
v2:
As Xin Long suggested, since only two other places need to call it. move
xfrm_garbage_collect() outside xfrm_policy_flush().
v3:
Fix subject mismatch after v2 fix.
Fixes: 35db06912189 ("xfrm: do the garbage collection after flushing policy")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
---
net/key/af_key.c | 2 ++
net/xfrm/xfrm_policy.c | 4 ----
net/xfrm/xfrm_user.c | 1 +
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/key/af_key.c b/net/key/af_key.c
index 512dc43..5103f92 100644
--- a/net/key/af_key.c
+++ b/net/key/af_key.c
@@ -2755,6 +2755,8 @@ static int pfkey_spdflush(struct sock *sk, struct sk_buff *skb, const struct sad
int err, err2;
err = xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, true);
+ if (!err)
+ xfrm_garbage_collect(net);
err2 = unicast_flush_resp(sk, hdr);
if (err || err2) {
if (err == -ESRCH) /* empty table - old silent behavior */
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index ed4e52d..643a18f 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1006,10 +1006,6 @@ int xfrm_policy_flush(struct net *net, u8 type, bool task_valid)
err = -ESRCH;
out:
spin_unlock_bh(&net->xfrm.xfrm_policy_lock);
-
- if (cnt)
- xfrm_garbage_collect(net);
-
return err;
}
EXPORT_SYMBOL(xfrm_policy_flush);
diff --git a/net/xfrm/xfrm_user.c b/net/xfrm/xfrm_user.c
index 38614df..86116e9 100644
--- a/net/xfrm/xfrm_user.c
+++ b/net/xfrm/xfrm_user.c
@@ -2027,6 +2027,7 @@ static int xfrm_flush_policy(struct sk_buff *skb, struct nlmsghdr *nlh,
return 0;
return err;
}
+ xfrm_garbage_collect(net);
c.data.type = type;
c.event = nlh->nlmsg_type;
--
2.5.5
^ permalink raw reply related
* (unknown),
From: energi @ 2017-06-11 2:29 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 16633582951.zip --]
[-- Type: application/zip, Size: 3178 bytes --]
^ permalink raw reply
* [PATCH net-next] bpf, arm64: take advantage of stack_depth tracking
From: Daniel Borkmann @ 2017-06-11 1:55 UTC (permalink / raw)
To: davem; +Cc: ast, netdev, linux-arm-kernel, Daniel Borkmann
Make use of recently implemented stack_depth tracking for arm64 JIT,
so that stack usage can be reduced heavily for programs not using
tail calls at least.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
---
arch/arm64/net/bpf_jit_comp.c | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
index 4f95873..73de2c7 100644
--- a/arch/arm64/net/bpf_jit_comp.c
+++ b/arch/arm64/net/bpf_jit_comp.c
@@ -69,6 +69,7 @@ struct jit_ctx {
int epilogue_offset;
int *offset;
u32 *image;
+ u32 stack_size;
};
static inline void emit(const u32 insn, struct jit_ctx *ctx)
@@ -145,16 +146,11 @@ static inline int epilogue_offset(const struct jit_ctx *ctx)
/* Stack must be multiples of 16B */
#define STACK_ALIGN(sz) (((sz) + 15) & ~15)
-#define _STACK_SIZE \
- (MAX_BPF_STACK \
- + 4 /* extra for skb_copy_bits buffer */)
-
-#define STACK_SIZE STACK_ALIGN(_STACK_SIZE)
-
#define PROLOGUE_OFFSET 8
static int build_prologue(struct jit_ctx *ctx)
{
+ const struct bpf_prog *prog = ctx->prog;
const u8 r6 = bpf2a64[BPF_REG_6];
const u8 r7 = bpf2a64[BPF_REG_7];
const u8 r8 = bpf2a64[BPF_REG_8];
@@ -176,9 +172,9 @@ static int build_prologue(struct jit_ctx *ctx)
* | |
* | ... | BPF prog stack
* | |
- * +-----+ <= (BPF_FP - MAX_BPF_STACK)
+ * +-----+ <= (BPF_FP - prog->aux->stack_depth)
* |RSVD | JIT scratchpad
- * current A64_SP => +-----+ <= (BPF_FP - STACK_SIZE)
+ * current A64_SP => +-----+ <= (BPF_FP - ctx->stack_size)
* | |
* | ... | Function call stack
* | |
@@ -202,8 +198,12 @@ static int build_prologue(struct jit_ctx *ctx)
/* Initialize tail_call_cnt */
emit(A64_MOVZ(1, tcc, 0, 0), ctx);
+ /* 4 byte extra for skb_copy_bits buffer */
+ ctx->stack_size = prog->aux->stack_depth + 4;
+ ctx->stack_size = STACK_ALIGN(ctx->stack_size);
+
/* Set up function call stack */
- emit(A64_SUB_I(1, A64_SP, A64_SP, STACK_SIZE), ctx);
+ emit(A64_SUB_I(1, A64_SP, A64_SP, ctx->stack_size), ctx);
cur_offset = ctx->idx - idx0;
if (cur_offset != PROLOGUE_OFFSET) {
@@ -288,7 +288,7 @@ static void build_epilogue(struct jit_ctx *ctx)
const u8 fp = bpf2a64[BPF_REG_FP];
/* We're done with BPF stack */
- emit(A64_ADD_I(1, A64_SP, A64_SP, STACK_SIZE), ctx);
+ emit(A64_ADD_I(1, A64_SP, A64_SP, ctx->stack_size), ctx);
/* Restore fs (x25) and x26 */
emit(A64_POP(fp, A64_R(26), A64_SP), ctx);
@@ -732,7 +732,7 @@ static int build_insn(const struct bpf_insn *insn, struct jit_ctx *ctx)
return -EINVAL;
}
emit_a64_mov_i64(r3, size, ctx);
- emit(A64_SUB_I(1, r4, fp, STACK_SIZE), ctx);
+ emit(A64_SUB_I(1, r4, fp, ctx->stack_size), ctx);
emit_a64_mov_i64(r5, (unsigned long)bpf_load_pointer, ctx);
emit(A64_BLR(r5), ctx);
emit(A64_MOV(1, r0, A64_R(0)), ctx);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops
From: Konrad Rzeszutek Wilk @ 2017-06-11 2:36 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-mips, linux-samsung-soc, linux-ia64, linux-c6x-dev,
linux-s390, linux-sh, linux-hexagon, linux-xtensa, x86,
linux-tegra, linux-kernel, dri-devel, dmaengine, iommu, openrisc,
netdev, sparclinux, xen-devel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20170608132609.32662-8-hch@lst.de>
On Thu, Jun 08, 2017 at 03:25:32PM +0200, Christoph Hellwig wrote:
> ARM and x86 had duplicated versions of the dma_ops structure, the
> only difference is that x86 hasn't wired up the set_dma_mask,
> mmap, and get_sgtable ops yet. On x86 all of them are identical
> to the generic version, so they aren't needed but harmless.
>
> All the symbols used only for xen_swiotlb_dma_ops can now be marked
> static as well.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm/xen/mm.c | 17 --------
> arch/x86/xen/pci-swiotlb-xen.c | 14 -------
> drivers/xen/swiotlb-xen.c | 93 ++++++++++++++++++++++--------------------
> include/xen/swiotlb-xen.h | 62 +---------------------------
> 4 files changed, 49 insertions(+), 137 deletions(-)
Yeeey!
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 08/44] xen-swiotlb: implement ->mapping_error
From: Konrad Rzeszutek Wilk @ 2017-06-11 2:37 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-mips, linux-samsung-soc, linux-ia64, linux-c6x-dev,
linux-s390, linux-sh, linux-hexagon, linux-xtensa, x86,
linux-tegra, linux-kernel, dri-devel, dmaengine, iommu, openrisc,
netdev, sparclinux, xen-devel, linuxppc-dev, linux-arm-kernel
In-Reply-To: <20170608132609.32662-9-hch@lst.de>
On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is going to go away, so don't rely on it.
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH net-next 6/9] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC
From: Andrew Lunn @ 2017-06-11 2:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: Salil Mehta, davem, yisen.zhuang, huangdaode, lipeng321,
mehta.salil.lnk, netdev, linux-kernel, linuxarm
In-Reply-To: <ba416774-9ccc-e6b6-3518-fb492b8b2858@gmail.com>
> > +int hclge_mac_mdio_config(struct hclge_dev *hdev)
> > +{
> > + struct hclge_mac *mac = &hdev->hw.mac;
> > + struct mii_bus *mdio_bus;
> > + struct net_device *ndev = &mac->ndev;
> > + struct phy_device *phy;
> > + bool is_c45;
> > + int ret;
> > +
> > + if (hdev->hw.mac.phy_addr >= PHY_MAX_ADDR)
> > + return 0;
> > +
> > + if (hdev->hw.mac.phy_if == PHY_INTERFACE_MODE_NA)
> > + return 0;
> > + else if (mac->phy_if == PHY_INTERFACE_MODE_SGMII)
> > + is_c45 = 0;
> > + else if (mac->phy_if == PHY_INTERFACE_MODE_XGMII)
> > + is_c45 = 1;
> > + else
> > + return -ENODATA;
>
> Can you consider using a switch () case statement here?
Does this concept even make sense? The Marvell 10G phy will use SGMII
for 10/100/1000Mbs and swap to XGMII for 10Gbps. It however stays a
c45 device all the time.
In general, i don't think PHY mode is related to C22/C45.
Andrew
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox