On 05/12/18 09:46, Jiong Wang wrote:
> There is NO processed instruction number regression, either with or without
> -mattr=+alu32.
> Cilium bpf
> ===
> bpf_lb-DLB_L3.o 2110/21101730/1733
That looks like a regression of 3 insns in the 32-bit case.
May be worth investigating why.
> +
On 04/12/18 17:44, Paolo Abeni wrote:
> On Tue, 2018-12-04 at 17:13 +0000, Edward Cree wrote:
>> On 03/12/18 11:40, Paolo Abeni wrote:
>>> This header define a bunch of helpers that allow avoiding the
>>> retpoline overhead when calling builtin functions via function
ree in
__netif_receive_skb_list_core")
Fixes: 7da517a3bc52 ("net: core: Another step of skb receive list processing")
Fixes: a4ca8b7df73c ("net: ipv4: fix drop handling in ip_list_rcv() and
ip_list_rcv_finish()")
Fixes: d8269e2cbf90 ("net: ipv6: listify ipv6_rcv() and ip6
On 03/12/18 11:40, Paolo Abeni wrote:
> This header define a bunch of helpers that allow avoiding the
> retpoline overhead when calling builtin functions via function pointers.
> It boils down to explicitly comparing the function pointers to
> known builtin functions and eventually invoke directly
On 10/11/18 05:21, Jakub Kicinski wrote:
> From: John Hurley
>
> Previously, TC block tunnel decap rules were only offloaded when a
> callback was triggered through registration of the rules egress device.
> This meant that the driver had no access to the ingress netdev and so
> could not verify
and
FLOW_DISSECTOR_KEY_CVLAN to refer to those.
Signed-off-by: Edward Cree
---
include/net/flow_dissector.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index 6a4586dcdede..2b26979efb48 100644
--- a/include/net/flow_dissector.h
On 22/11/18 20:59, David Calavera wrote:
> I noticed that these two new BPF Maps are not defined in bpftool.
> This patch defines those two maps and adds their names to the
> bpftool-map documentation.
>
> Signed-off-by: David Calavera
> ---
Subject line says 'QUEUE' twice, should one of those be
On 20/11/18 00:06, Nikita V. Shirokov wrote:
> idea is pretty simple. for specified map (pointed by struct bpf_map)
> we would provide descriptor of already loaded map, which is going to be
> used as a prototype for inner map. proposed workflow:
> 1) open bpf's object (bpf_object__open)
> 2)
vert dwarf to BTF for ELF files.
>
> This patch added func info support to the kernel so we can
> get better ksym's for bpf function calls. Basically,
> function call types are passed to kernel and the kernel
> extract function names from these types in order to contruct ksym
> for t
On 15/11/18 22:01, Eric Dumazet wrote:
> On 11/15/2018 01:45 PM, Edward Cree wrote:
>> If napi->poll() is only handling one packet, surely GRO can't do anything
>> useful either? (AIUI at the end of the poll the GRO lists get flushed.)
> That is my point.
>
&g
Some corrections as it looks like I didn't proofread this carefully enough
before sending it...
On 14/11/18 18:07, Edward Cree wrote:
> Payload_size in all tests was 8000 bytes.
This was for TCP tests; the UDP test used 1-byte payloads.
> UDP Stream (GRO off):
> net-next: 7.808 Gb/s
&
On 15/11/18 20:08, Eric Dumazet wrote:
> On 11/15/2018 10:43 AM, Edward Cree wrote:
>
> Most of the packet isn't touched and thus won't be brought into cache.
>> Only the headers of each packet (worst-case let's say 256 bytes) will
>> be touched during batch processing, that
On 15/11/18 07:22, Eric Dumazet wrote:
> On 11/14/2018 10:07 AM, Edward Cree wrote:
>> Conclusion:
>> * TCP b/w is 16.5% faster for traffic which cannot be coalesced by GRO.
> But only for traffic that actually was perfect GRO candidate, right ?
>
> Now what happen
Allows GRO-using drivers to get the benefits of batching for non-GROable
traffic.
Signed-off-by: Edward Cree
---
net/core/dev.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 35427167f6fb..65bfe28fbc81 100644
'Good' packets are defined as skbs for which netif_receive_skb() would
have returned %NET_RX_SUCCESS. Thus, drivers can use this number for
adaptive interrupt moderation where they previously reacted to the
return code from netif_receive_skb().
Signed-off-by: Edward Cree
---
include/linux
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx.c| 11 +--
drivers/net/ethernet/sfc/net_driver.h | 1 +
drivers/net/ethernet/sfc/rx.c | 16 +---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b
Also export napi_frags_skb() so that drivers using the napi_gro_frags()
interface can prepare their SKBs properly for submitting on such a list.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 2 ++
net/core/dev.c| 28 +++-
2 files changed, 29
tch #3.
v2: Rebased on latest net-next. Removed RFC tags. Otherwise unchanged
owing to lack of comments on v1.
Edward Cree (4):
net: introduce list entry point for GRO
sfc: use batched receive for GRO
net: make listified RX functions return number of good packets
net/core: handle GRO_NORMA
On 09/11/18 21:14, Alexei Starovoitov wrote:
> same link, but i cannot make it right now.
> have to extinguish few fires.
> may be at 2pm (unlikely) or 3pm (more likely) PST?
Yep I can do either of those, just let me know which when you can.
On 09/11/18 04:35, Alexei Starovoitov wrote:
> On Thu, Nov 08, 2018 at 10:56:55PM +0000, Edward Cree wrote:
>> think this question of maps should be discussed in tomorrow's
>> call, since it is when we start having other kinds of instances
> turned out most of us have a conflic
On 08/11/18 19:42, Alexei Starovoitov wrote:
> same link let's continue at 1pm PST.
So, one thing we didn't really get onto was maps, and you mentioned that it
wasn't really clear what I was proposing there.
What I have in mind comes in two parts:
1) map type. A new BTF_KIND_MAP with metadata
On 08/11/18 20:36, Yonghong Song wrote:
> This patch adds BTF_KIND_FUNC support to the type section.
> BTF_KIND_FUNC is used to specify the signature of a
> defined subprogram or the pointee of a function pointer.
>
> In BTF, the function type related data structures are
> struct bpf_param {
>
As added in 3e59020abf0f ("net: bql: add __netdev_tx_sent_queue()"), which
see for performance rationale.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/tx.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/ne
On 07/11/18 21:49, Alexei Starovoitov wrote:
> On Wed, Nov 07, 2018 at 07:29:31PM +0000, Edward Cree wrote:
>> Whereas I don't, and I don't feel like my core criticisms have
>> been addressed _at all_. The only answer I get to "BTF should
>> store type and instan
On 07/11/18 00:59, Alexei Starovoitov wrote:
> Function name and function argument names are part of the same debug info.
> Splitting them makes no sense.
... except where combining them involves creating pain elsewhere.
Sure the function name *could* go in the type record, but there
still needs
was
accepted or rejected by a Secure NIC.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/ef10.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 7eeac3d6cfe8..b6a50058bb8d 100644
--- a/drivers/net/ethernet/sfc
On 06/11/18 21:56, Alexei Starovoitov wrote:
> that looks very weird to me. Why split func name from argument names?
> The 'function name' as seen by the BTF may not be the symbol name
> as seen in elf file.
The symbol name will be in the symbol table, which is not the same
thing as the functions
On 06/11/18 06:29, Alexei Starovoitov wrote:
> BTF is not pure type information. BTF is everything that verifier needs
> to know to make safety decisions that bpf instruction set doesn't have.
Yes, I'm not disputing that and never have.
I'm just saying that it will be much cleaner and better if
On 03/11/18 22:40, David Miller wrote:
> Series applied, but I wonder how many other commonly used drivers we
> should update the same way mlx4 is here?
Hi David,
I'm doing a patch to update sfc to use this new helper. Is this 'net'
material, or should I wait for 'net-next' to open back up?
On 02/11/18 15:02, Arnaldo Carvalho de Melo wrote:
> Yeah, didn't work as well:
> And the -vv in 'perf trace' didn't seem to map to further details in the
> output of the verifier debug:
Yeah for log_level 2 you probably need to make source-level changes to either
perf or libbpf (I think the
On 02/11/18 10:57, Luca Boccassi wrote:
> ". If" gets interpreted as a macro, so move the period to the previous
> line:
>
> 33: warning: macro `If' not defined
>
> Fixes: 141b55f8544e ("Add SKB Priority qdisc support in tc(8)")
>
> Signed-off-by: Luca Boccassi
> ---
> man/man8/tc-skbprio.8 |
I've spent a bit more time thinking about / sleeping on this, and I
still think there's a major disagreement here. Basically it seems
like I'm saying "the design of BTF is wrong" and you're saying "but
it's the design" (with the possible implication — I'm not entirely
sure — of "but that's
On 01/11/18 18:52, Arnaldo Carvalho de Melo wrote:
> R0=inv(id=0) R1=inv6 R2=inv6 R3=inv(id=0) R6=ctx(id=0,off=0,imm=0) R7=inv64
> R10=fp0,call_-1
> 15: (b7) r2 = 0
> 16: (63) *(u32 *)(r10 -260) = r2
> 17: (67) r1 <<= 32
> 18: (77) r1 >>= 32
> 19: (67) r1 <<= 3
> 20: (bf) r2 = r6
> 21: (0f) r2
ptr_reg->range is just buggy as any new
> map_ptr in the dst_reg is then truncated (or null) for subsequent
> checks. Fix this by adding a raw member and use it for copying state
> over to dst_reg.
>
> Fixes: f1174f77b50c ("bpf/verifier: rework value tracking")
> Sig
On 19/10/18 20:36, Martin Lau wrote:
> On Fri, Oct 19, 2018 at 06:04:11PM +0100, Edward Cree wrote:
>> But you *do* have such a new section.
>> The patch comment talks about a 'FuncInfo Table' which appears to
> Note that the new section, which contains the FuncInfo Table,
On 18/10/18 22:19, Martin Lau wrote:
> As I have mentioned earlier, it is also special to
> the kernel because the BTF verifier and bpf_prog_load()
> need to do different checks for FUNC and FUNC_PROTO to
> ensure they are sane.
>
> First, we need to agree that the kernel needs to verify
> them
On 18/10/18 19:12, Martin Lau wrote:
> The BTF verification and bpf_prog_load() has to treat
> them differently.
>
> Are you suggesting they can be treated the same for
> the kernel verification purpose?
>
> or
>
> The concern is, having two kind, BTF_KIND_FUNC_PROTO and
> BTF_KIND_FUNC, is
On 17/10/18 18:50, Martin Lau wrote:
> On Wed, Oct 17, 2018 at 10:25:21AM -0700, Yonghong Song wrote:
>> What you stated is true, BTF_KIND_FUNC_PROTO corresponds to
>> dwarf subroutine tag which has no name while BTF_KIND_FUNC
>> must have a valid name. The original design is to have both
>> since
On 17/10/18 08:23, Yonghong Song wrote:
> This patch adds BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
> support to the type section. BTF_KIND_FUNC_PROTO is used
> to specify the type of a function pointer. With this,
> BTF has a complete set of C types (except float).
>
> BTF_KIND_FUNC is used to
On 17/10/18 08:24, Yonghong Song wrote:
> This patch added support to print function signature
> if btf func_info is available. Note that ksym
> now uses function name instead of prog_name as
> prog_name has a limit of 16 bytes including
> ending '\0'.
>
> The following is a sample output for
I think the BTF work needs to be better documented; at the moment the only way
to determine how BTF sections are structured is to read through the headers,
and cross-reference with the DWARF spec to guess at the semantics of various
fields. I've been working on adding BTF support to ebpf_asm,
t;)
> Acked-by: Daniel Borkmann
> Signed-off-by: Jann Horn
> ---
Acked-by: Edward Cree
> kernel/bpf/verifier.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index bb07e74b34a2..465952a8e465 10
On 03/10/18 16:36, Jiong Wang wrote:
> On 28/09/2018 14:36, Edward Cree wrote:
> > But what you've described sounds interesting; perhaps it would also
> > help later with loop-variable handling?
>
> Haven't considered how to use this for loop-variable handling, guess you m
On 04/10/18 15:08, John W. Linville wrote:
> Ping?
>
> On Mon, Oct 01, 2018 at 02:59:10PM -0400, John W. Linville wrote:
>> Is this patch still RFC?
Feel free to de-RFC and apply it.
On 28/09/18 17:45, Andrew Lunn wrote:
> Now is a good time to change the API, since we are moving to a netlink
> socket. Which is why these questions were asked in the first place...
OK, well, I've posted sfc's semantics and view-from-the-hardware*; now
patiently waiting for other NIC vendors to
On 28/09/18 16:39, Andrew Lunn wrote:
> I wonder how true that will be in 5 years time, about reading the
> manual? SFP sockets are starting to appear in consumer devices. There
> are some Marvell SoC reference boards with SFP and SFP+. Broadcom also
> have some boards with SFP. With time, SFP
On 26/09/18 23:16, Jiong Wang wrote:
> On 22/08/2018 20:00, Edward Cree wrote:
>> In the future this idea may be extended to form use-def chains.
>
> 1. instruction level use->def chain
>
> - new use->def chains for each instruction. one eBPF insn could have two
On 26/09/18 09:47, Ariel Almog wrote:
> I was won
Truncated sentence? ("... wondering"?)
> I find the ability to set off, auto and specific FEC mode in the same
> command confusing.
I didn't try to define semantics here since each driver currently does
something slightly different. Probably
Instead of commas, just have them as separate argvs.
The parsing state machine might look heavyweight, but it makes it easy to add
more parameters later and distinguish parameter names from encoding names.
Suggested-by: Michal Kubecek
Signed-off-by: Edward Cree
---
ethtool.8.in | 6
On 19/09/18 15:41, Michal Kubecek wrote:
> I'm sorry I didn't notice this before the patch was accepted but as it's
> not in a release yet, maybe it's still not too late.
>
> Could I suggest to make the syntax consistent with other options?
I didn't realise ethtool had any patterns to be
On 07/09/18 03:32, Eric Dumazet wrote:
> Adding this complexity and icache pressure needs more experimental results.
> What about RPC workloads (eg 100 concurrent netperf -t TCP_RR -- -r
> 8000,8000 )
>
> Thanks.
Some more results. Note that the TCP_STREAM figures given in the cover
letter
On 07/09/18 03:32, Eric Dumazet wrote:
> Your performance numbers are not convincing, since TCP stream test should
> get nominal GRO gains.
I'm not quite sure what you mean here, could you explain a bit more?
> Adding this complexity and icache pressure needs more experimental results.
>
> What
On 07/09/18 03:27, Eric Dumazet wrote:
> On 09/06/2018 07:26 AM, Edward Cree wrote:
>> Signed-off-by: Edward Cree
> Lack of changelog here ?
>
> I do not know what is a good packet.
The comment on netif_receive_skb_list() defines this as "skbs for which
netif_receive_sk
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 4 +--
include/net/ip.h | 4 +--
include/net/ipv6.h| 4 +--
net/core/dev.c| 63 +--
net/ipv4/ip_input.c | 39 ++---
net/ipv6
Allows GRO-using drivers to get the benefits of batching for non-GROable
traffic.
Signed-off-by: Edward Cree
---
net/core/dev.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 69e2819994e4..9a937d2ac83b 100644
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx.c| 11 +--
drivers/net/ethernet/sfc/net_driver.h | 1 +
drivers/net/ethernet/sfc/rx.c | 16 +---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b
Also export napi_frags_skb() so that drivers using the napi_gro_frags()
interface can prepare their SKBs properly for submitting on such a list.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 2 ++
net/core/dev.c| 28 +++-
2 files changed, 29
int):
net-next: 4.756 Gbit/s (sigma 0.240)
after #4: 5.355 Gbit/s (sigma 0.232) = datum + 12.6%
v2: Rebased on latest net-next. Removed RFC tags. Otherwise unchanged
owing to lack of comments on v1.
Edward Cree (4):
net: introduce list entry point for GRO
sfc: use batched receive for GRO
-separated list of FEC modes in the 'encoding' argument on the
command line.
Also adds --set-fec tests to test-cmdline.c, and corrects the man page
(the encoding argument is not optional) while updating it.
Signed-off-by: Edward Cree
---
I've CCed the maintainers of the other drivers (cxgb4, nfp
: f1174f77b50c ("bpf/verifier: rework value tracking")
> Debugged-by: Edward Cree
> Signed-off-by: Alexei Starovoitov
Acked-by: Edward Cree
in place. This then caused the memcmp() in regsafe() to fail,
preventing some branches from being pruned (and occasionally causing the
same program to take a varying number of processed insns on repeated
verifier runs).
Signed-off-by: Edward Cree
---
Possibly something might need adding
On 30/08/18 03:18, Alexei Starovoitov wrote:
> I think it's a better base to continue debugging.
> In particular:
> 1. we have instability issue in the verifier.
> from time to time the verifier goes to process extra 7 instructions on one
> of the cilium tests. This was happening before and
Allows GRO-using drivers to get the benefits of batching for non-GROable
traffic.
Signed-off-by: Edward Cree
---
net/core/dev.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index ac9741273c62..f9391f76feb7 100644
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 4 +--
include/net/ip.h | 4 +--
include/net/ipv6.h| 4 +--
net/core/dev.c| 63 +--
net/ipv4/ip_input.c | 39 ++---
net/ipv6
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx.c| 11 +--
drivers/net/ethernet/sfc/net_driver.h | 1 +
drivers/net/ethernet/sfc/rx.c | 16 +---
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/sfc/efx.c b
Also export napi_frags_skb() so that drivers using the napi_gro_frags()
interface can prepare their SKBs properly for submitting on such a list.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 2 ++
net/core/dev.c| 28 +++-
2 files changed, 29
int):
net-next: 4.756 Gbit/s (sigma 0.240)
after #4: 5.355 Gbit/s (sigma 0.232) = datum + 12.6%
Edward Cree (4):
net: introduce list entry point for GRO
sfc: use batched receive for GRO
net: make listified RX functions return number of good packets
net/core: handle GRO_NORMAL skbs as a l
where its first byte was STACK_ZERO.
Instead, print eight characters with either 0 (STACK_ZERO), m (STACK_MISC)
or ? (STACK_INVALID) for any stack slot which is neither STACK_SPILL nor
entirely STACK_INVALID.
Signed-off-by: Edward Cree
---
kernel/bpf/verifier.c | 32
-r5 into the callee as args, and r0 out as the return value) they also
copy the parent pointer.
Signed-off-by: Edward Cree
---
include/linux/bpf_verifier.h | 8 +-
kernel/bpf/verifier.c| 184 +++
2 files changed, 47 insertions(+), 145 deletions
.
The second patch adds information about misc/zero data on the stack to the
state dumps emitted to the log at various points; this information was
found essential in debugging the first patch, and may be useful elsewhere.
Edward Cree (2):
bpf/verifier: per-register parent pointers
bpf/verifier
On 16/08/18 17:44, Petar Penkov wrote:
> From: Petar Penkov
>
> Adds a hook for programs of type BPF_PROG_TYPE_FLOW_DISSECTOR and
> attach type BPF_FLOW_DISSECTOR that is executed in the flow dissector
> path. The BPF program is kept as a global variable so it is
> accessible to all flow
ase for MOV64 dst == src, and dst != src.
>
> Signed-off-by: Arthur Fabre
> ---
> v2: Add mov64 tests, always use DST_OP_NO_MARK
>
> kernel/bpf/verifier.c | 6 +++--
> tools/testing/selftests/bpf/test_verifier.c | 26 +++++
> 2 files changed, 30 insertions(+), 2 deletions(-)
Acked-by: Edward Cree
On 30/07/18 13:03, Daniel Borkmann wrote:
> On 07/30/2018 12:58 PM, Arthur Fabre wrote:
>> The check_alu_op() call handles 32bit and 64bit cases, but then in the
>> 32bit case
>> mark_reg_unknown() is called, discarding all the dst register state.
>> I think this is equivalent to keeping a copy of
On 25/07/18 03:50, Tobin C. Harding wrote:
> In preparation to convert Documentation/network/netdev-FAQ.rst to
> restructured text format we would like to be able to reference 'the
> canonical patch format' section.
>
> Add rest label: 'the_canonical_path_format'.
Here and in the Subject, 'patch'
On 18/07/18 04:54, Alexei Starovoitov wrote:
> I'd like to apply it, but I see the difference in insn_processed.
> Several cilium tests show favorable difference towards new liveness approach.
> selftests/bpf/test_xdp_noinline.o also shows the difference.
> I'm struggling to see why this patch
On 12/07/18 21:10, Or Gerlitz wrote:
> On Wed, Jul 11, 2018 at 11:06 PM, Jesper Dangaard Brouer
> wrote:
>> One reason I didn't "just" send a patch, is that Edward so-fare only
>> implemented netif_receive_skb_list() and not napi_gro_receive_list().
> sfc does't support gro?! doesn't make sense..
o ip_forward.
>
> Fixes: 5fa12739a53d ("net: ipv4: listify ip_rcv_finish")
> Signed-off-by: Jesper Dangaard Brouer
Acked-by: Edward Cree
But it feels weird and asymmetric to only NULL skb->next (not ->prev), and
to have to do this by hand rather than e.g. being able to use
list
__netif_receive_skb_core can free the skb, so we have to use the dequeue-
enqueue model when calling it from __netif_receive_skb_list_core.
Fixes: 88eb1944e18c ("net: core: propagate SKB lists through packet_type
lookup")
Signed-off-by: Edward Cree
---
net/core/dev.c | 9 +++
nf_hook() can free the skb, so we need to remove it from the list before
calling, and add passed skbs to a sublist afterwards.
Fixes: 17266ee93984 ("net: ipv4: listified version of ip_rcv")
Reported-by: Dan Carpenter
Signed-off-by: Edward Cree
---
include/linux/netfilter.h | 10 +++
afterwards.
In the case of enqueue_to_backlog() we have already decided not to pass
when we call the function, so we do not need a sublist.
Fixes: 7da517a3bc52 ("net: core: Another step of skb receive list processing")
Reported-by: Dan Carpenter
Signed-off-by: Edward Cree
---
net/core/
another similar bug in __netif_receive_skb_list_core().
v2: dropped patch #3 (new list.h helper), per DaveM's request.
Edward Cree (3):
net: core: fix uses-after-free in list processing
netfilter: fix use-after-free in NF_HOOK_LIST
net: core: fix use-after-free in __netif_receive_skb_list_core
nf_hook() can free the skb, so we need to remove it from the list before
calling, and add passed skbs to a sublist afterwards.
Fixes: 17266ee93984 ("net: ipv4: listified version of ip_rcv")
Reported-by: Dan Carpenter
Signed-off-by: Edward Cree
---
include/linux/netfilter.h | 10 +++
afterwards.
In the case of enqueue_to_backlog() we have already decided not to pass
when we call the function, so we do not need a sublist.
Fixes: 7da517a3bc52 ("net: core: Another step of skb receive list processing")
Reported-by: Dan Carpenter
Signed-off-by: Edward Cree
---
net/core/
patch #3 (new list.h helper), per DaveM's request.
Edward Cree (2):
net: core: fix uses-after-free in list processing
netfilter: fix use-after-free in NF_HOOK_LIST
include/linux/netfilter.h | 10 +++---
net/core/dev.c| 21 +
2 files changed, 20 insertions
New macro list_for_each_entry_dequeue loops over a list by popping entries
from the head, allowing a more concise expression of the dequeue-enqueue
model of list processing and avoiding the need for a 'next' pointer (as
used in list_for_each_entry_safe).
Signed-off-by: Edward Cree
afterwards.
In the case of enqueue_to_backlog() we have already decided not to pass
when we call the function, so we do not need a sublist.
Fixes: 7da517a3bc52 ("net: core: Another step of skb receive list processing")
Reported-by: Dan Carpenter
Signed-off-by: Edward Cree
---
net/core/
nf_hook() can free the skb, so we need to remove it from the list before
calling, and add passed skbs to a sublist afterwards.
Fixes: 17266ee93984 ("net: ipv4: listified version of ip_rcv")
Reported-by: Dan Carpenter
Signed-off-by: Edward Cree
---
include/linux/netfilter.h | 10 +++
), and then
adds a list.h helper macro to refactor code using the dequeue-enqueue
model.
Edward Cree (3):
net: core: fix uses-after-free in list processing
netfilter: fix use-after-free in NF_HOOK_LIST
net: refactor dequeue-model list processing
include/linux/list.h | 15 +++
include
Essentially the same as the ipv4 equivalents.
Signed-off-by: Edward Cree
---
include/net/ipv6.h | 2 +
net/ipv6/af_inet6.c | 1 +
net/ipv6/ip6_input.c | 131 ---
3 files changed, 118 insertions(+), 16 deletions(-)
diff --git a/include/net
be different in the single packet path (return
NET_RX_SUCCESS) and the list path (forget this packet and continue).
Fixes: 5fa12739a53d net: ipv4: listify ip_rcv_finish
Signed-off-by: Edward Cree
---
net/ipv4/ip_input.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions
While working on IPv6 list processing, I found another bug in the IPv4
version. So this patch series has that fix, and the IPv6 version with
both fixes incorporated.
Edward Cree (2):
net: ipv4: fix list processing on L3 slave devices
net: ipv6: listify ipv6_rcv() and ip6_rcv_finish
ore processing, and add it
to the sublist afterwards if it wasn't freed or stolen.
Fixes: 5fa12739a53d net: ipv4: listify ip_rcv_finish
Fixes: 17266ee93984 net: ipv4: listified version of ip_rcv
Signed-off-by: Edward Cree
---
net/ipv4/ip_input.c | 16 +++-
1 file changed, 11 insertions(+)
On 02/07/18 16:14, Edward Cree wrote:
> +/* Receive a list of IP packets */
> +void ip_list_rcv(struct list_head *head, struct packet_type *pt,
> + struct net_device *orig_dev)
> +{
> + struct net_device *curr_dev = NULL;
> + struct net *curr_net = NULL;
>
On 02/07/18 16:40, David Ahern wrote:
> Nice work. Have you looked at IPv6 support yet?
I hadn't looked at it yet, no. After a quick glance at ip6_rcv() and
ip6_rcv_finish(), it looks like it'd be basically the same as the IPv4
code in patches 7 and 8. I'll probably add it in a followup when
Generally the check should be very cheap, as the sk_buff_head is in cache.
Signed-off-by: Edward Cree
---
net/core/dev.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 4c5ebfab9bc8..d6084b0cd9ce 100644
--- a/net/core/dev.c
+++ b
itting on protocol changes).
Signed-off-by: Edward Cree
---
net/ipv4/ip_input.c | 54 +++--
1 file changed, 48 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/ip_input.c b/net/ipv4/ip_input.c
index 914240830bdf..24b9b0210aeb 100644
--- a/ne
to cause out-of-order receives, so presumably this is
considered OK.
Signed-off-by: Edward Cree
---
include/linux/netdevice.h | 3 +++
include/linux/netfilter.h | 22 +++
include/net/ip.h | 2 ++
net/core/dev.c| 8 +++---
net/ipv4/af_inet.c| 1 +
net
in ptype_base[hash of skb->protocol].
Signed-off-by: Edward Cree
---
net/core/dev.c | 72 +++---
1 file changed, 64 insertions(+), 8 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index d2454678bc82..edd67b1f1e12 100644
--- a/net/core/de
First example of a layer splitting the list (rather than merely taking
individual packets off it).
Involves new list.h function, list_cut_before(), like list_cut_position()
but cuts on the other side of the given entry.
Signed-off-by: Edward Cree
---
include/linux/list.h | 30
Improves packet rate of 1-byte UDP receives by up to 10%.
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/efx.c| 12
drivers/net/ethernet/sfc/net_driver.h | 3 +++
drivers/net/ethernet/sfc/rx.c | 7 ++-
3 files changed, 21 insertions(+), 1 deletion
1 - 100 of 688 matches
Mail list logo
