Re: linux networking kernel layer and STREAMS

. Whichever wins in terms of speed depends on many other details. anyway, that's my two cents. And I'm certainly biased. Perhaps someone else will chip in. cheers, Willem de Bruijn http://ffpf.sf.net for more (slightly outdated) info on my project - To unsubscribe from this list: send the line

Re: linux networking kernel layer and STREAMS

Linux TCP/IP doesn't work like this. I never said it did, I said that *functional frameworks* worked like this. For the most part I believe Linux TCP/IP does work like this, though. I'll skip routing when making this point. Although Linux has indirect function calls to choose between a TCP

Re: linux networking kernel layer and STREAMS

Well, if you are doing research you need to know whats out there so you can a) learn from it b) avoid reinventing the wheel That speaks for itself. I'm not completely ignorant and have read most that has been published at decent venues. Thing is, I don't find such publications about

Re: linux networking kernel layer and STREAMS

But you haven't even studied how the Linux networking works, so how would you know? I guess time is better spent reinventing the wheel. Since you don't know, by definition you're spewing. You don't know the Linux networking, and therefore you don't know whether existing mechanisms can solve

Re: linux networking kernel layer and STREAMS

I'm talking about stackable routes, which is in the destination cache and is at the core of how all routing works in the Linux kernel. I misunderstood you there. Stackable routes are interesting, and indeed simple. They are miles apart from my work, and certainly not innovative. They are

[PATCH net-next v2 2/6] packet: rollover prepare: per-socket state

From: Willem de Bruijn will...@google.com Replace rollover state per fanout group with state per socket. Future patches will add fields to the new structure. Signed-off-by: Willem de Bruijn will...@google.com --- net/packet/af_packet.c | 21 ++--- net/packet/internal.h | 6

[PATCH net-next v2 3/6] packet: rollover only to socket with headroom

From: Willem de Bruijn will...@google.com Only migrate flows to sockets that have sufficient headroom, where sufficient is defined as having at least 25% empty space. The kernel has three different buffer types: a regular socket, a ring with frames (TPACKET_V[12]) or a ring with blocks

[PATCH net-next] net-packet: fix null pointer exception in rollover mode

not expect the new headroom (ROOM_NORMAL) requirement. I will send a separate patch to the test. Fixes: 0648ab70afe6 (packet: rollover prepare: per-socket state) Signed-off-by: Willem de Bruijn will...@google.com I should have run this test and caught this before submission, of course

[PATCH net-next v3 5/6] packet: rollover huge flows before small flows

From: Willem de Bruijn will...@google.com Migrate flows from a socket to another socket in the fanout group not only when the socket is full. Start migrating huge flows early, to divert possible 4-tuple attacks without affecting normal traffic. Introduce fanout_flow_is_huge(). This detects huge

[PATCH net-next] net: replace last open coded skb_orphan_frags with function call

From: Willem de Bruijn will...@google.com Commit 70008aa50e92 (skbuff: convert to skb_orphan_frags) replaced open coded tests of SKBTX_DEV_ZEROCOPY and skb_copy_ubufs with calls to helper function skb_orphan_frags. Apply that to the last remaining open coded site. Signed-off-by: Willem de Bruijn

Re: [PATCH net] ip: report the original address of ICMP messages

On Tue, Jun 23, 2015 at 2:55 PM, Julian Anastasov j...@ssi.bg wrote: Hello, On Tue, 23 Jun 2015, Willem de Bruijn wrote: The ping utility from iputils relies on cmsg IP_RECVERR to get the source address on icmp errors, not on msg_name, so that worked for me both before and after

Re: [PATCH net] ip: report the original address of ICMP messages

. Fixes: c247f0534cc5 (ip: fix error queue empty skb handling) Signed-off-by: Julian Anastasov j...@ssi.bg Acked-by: Willem de Bruijn will...@google.com The ping utility from iputils relies on cmsg IP_RECVERR to get the source address on icmp errors, not on msg_name, so that worked for me both before

Re: [PATCH net] ip: report the original address of ICMP messages

On Tue, Jun 23, 2015 at 4:06 PM, Julian Anastasov j...@ssi.bg wrote: Hello, On Tue, 23 Jun 2015, Willem de Bruijn wrote: It is using IP_RECVERR and may be relying only on original address returned in msg_name from MSG_ERRQUEUE. It's not very important, in that even

[PATCH net-next] packet: free packet_rollover after synchronize_net

From: Willem de Bruijn will...@google.com Destruction of the po-rollover must be delayed until there are no more packets in flight that can access it. The field is destroyed in packet_release, before synchronize_net. Delay using rcu. Fixes: 0648ab70afe6 (packet: rollover prepare: per-socket

[PATCH net] packet: avoid out of bounds read in round robin fanout

From: Willem de Bruijn will...@google.com PACKET_FANOUT_LB computes f-rr_cur such that it is modulo f-num_members. It returns the old value unconditionally, but f-num_members may have changed since the last store. This can be fixed with -return cur +return cur num ? : 0

Re: [PATCH net] packet: avoid out of bounds read in round robin fanout

On Tue, Jun 16, 2015 at 5:07 PM, Willem de Bruijn will...@google.com wrote: From: Willem de Bruijn will...@google.com PACKET_FANOUT_LB computes f-rr_cur such that it is modulo f-num_members. It returns the old value unconditionally, but f-num_members may have changed since the last store

[PATCH net v2] packet: avoid out of bounds read in round robin fanout

From: Willem de Bruijn will...@google.com PACKET_FANOUT_LB computes f-rr_cur such that it is modulo f-num_members. It returns the old value unconditionally, but f-num_members may have changed since the last store. Ensure that the return value is always num. When modifying the logic, simplify

Re: [PATCH net-next RFC 00/10] socket sendmsg MSG_ZEROCOPY

On Thu, Aug 20, 2015 at 6:56 PM, David Miller da...@davemloft.net wrote: From: Willem de Bruijn will...@google.com Date: Thu, 20 Aug 2015 10:36:39 -0400 Datapath integrity does not otherwise depend on payload, with three exceptions: checksums, optional sk_filter/tc u32/.. and device + driver

[PATCH net-next RFC 06/10] udp: enable sendmsg zerocopy

From: Willem de Bruijn will...@google.com Add MSG_ZEROCOPY support to inet/dgram. This includes udplite. Tested: loopback test //net/socket:snd_zerocopy_lo -u -z passes: without zerocopy (-u): rx=106644 (6655 MB) tx=106644 txc=0 rx=219264 (13683 MB) tx=219264 txc=0 rx=326958

[PATCH net-next RFC 08/10] packet: enable sendmsg zerocopy

From: Willem de Bruijn will...@google.com Support MSG_ZEROCOPY on PF_PACKET transmission. Signed-off-by: Willem de Bruijn will...@google.com --- net/packet/af_packet.c | 45 +++-- 1 file changed, 35 insertions(+), 10 deletions(-) diff --git a/net/packet

[PATCH net-next RFC 03/10] sock: enable sendmsg zerocopy

From: Willem de Bruijn will...@google.com Prepare the datapath for refcounted ubuf_info. Clone ubuf_info with skb_zerocopy_clone() wherever needed due to skb split, merge, resize or clone. The exact locations to modify were chosen by exhaustively searching through all code that might modify

[PATCH net-next RFC 09/10] sock: sendmsg zerocopy ulimit

From: Willem de Bruijn will...@google.com Bound the number of pages that a userspace process may pin. Account pinned pages to the locked page count (`ulimit -l`) of the caller and fail beyond the administrator controlled threshold, similar to infiniband. Use an atomic variable to avoid having

[PATCH net-next RFC 05/10] tcp: enable sendmsg zerocopy

From: Willem de Bruijn will...@google.com Enable support for MSG_ZEROCOPY to the TCP stack. Data that is sent to a remote host will be zerocopy. TSO and GSO are supported. Tested: A 10x TCP_STREAM between two hosts showed a reduction in netserver process cycles by up to 70%, depending

[PATCH net-next RFC 01/10] sock: skb_copy_ubufs support for compound pages

From: Willem de Bruijn will...@google.com Refine skb_copy_ubufs to support compount pages. With upcoming TCP and UDP zerocopy sendmsg, such fragments may appear. These skbuffs can also combine kernel and user fragments, e.g., when corking. Skip the copy for fragments that have only 1 (kernel

[PATCH net-next RFC 07/10] raw: enable sendmsg zerocopy with hdrincl

From: Willem de Bruijn will...@google.com Add MSG_ZEROCOPY support to inet/raw when passing IP_HDRINCL Tested: raw loopback test //net/socket:snd_zerocopy_lo -r -z passes: without zerocopy (-r): rx=69348 (4327 MB) tx=69348 txc=0 rx=145590 (9085 MB) tx=145590 txc=0 rx=219210

[PATCH net-next RFC 04/10] sock: sendmsg zerocopy notification coalescing

From: Willem de Bruijn will...@google.com Support coalescing of zerocopy notifications. In the simple case, each sendmsg() call generates data and eventually a zerocopy ready notification N, where N indicates the Nth successful invocation of sendmsg() with the MSG_ZEROCOPY flag on this socket

[PATCH net-next RFC 00/10] socket sendmsg MSG_ZEROCOPY

From: Willem de Bruijn will...@google.com Add zerocopy socket sendmsg() support with flag MSG_ZEROCOPY. Implement the feature for TCP, UDP, RAW and packet sockets. This is a generalization of a previous packet socket RFC patch http://patchwork.ozlabs.org/patch/413184/ On a send call

[PATCH net-next RFC 02/10] sock: add sendmsg zerocopy

From: Willem de Bruijn will...@google.com The kernel supports zerocopy sendmsg in virtio and tap. Expand the infrastructure to support other socket types. Introduce a completion notification channel over the socket error queue. Notifications are returned with ee_origin SO_EE_ORIGIN_ZEROCOPY

[PATCH net-next RFC 10/10] test: add sendmsg zerocopy tests

From: Willem de Bruijn will...@google.com Introduce the tests uses to verify MSG_ZEROCOPY behavior: snd_zerocopy: send zerocopy fragments out over the default route. snd_zerocopy_lo: send data between a pair of local sockets and report throughput. These tests are not suitable for inclusion

Re: [PATCH] packet: Allow packets with only a header (but no payload)

On Mon, Jul 27, 2015 at 6:35 PM, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: Hi Johann, On Tue, Jul 21, 2015 at 6:51 PM, Willem de Bruijn will...@google.com wrote: I don't see a simple way of verifying the safety of allowing packets without data short of a code audit, which

Re: [PATCH net-next 2/4] packet: add eBPF fanout mode

[ @Willem: RH email doesn't exist anymore, I took it out, otherwise every reply gets a bounce. ;) ] Sorry for using the wrong address, Daniel. Also instead of: #define PACKET_FANOUT_BPF6 #define PACKET_FANOUT_EBPF7 I would call them FANOUT_CBPF and FANOUT_EBPF to be

Re: [PATCH net-next 2/4] packet: add eBPF fanout mode

On Fri, Aug 14, 2015 at 1:03 PM, Alexei Starovoitov a...@plumgrid.com wrote: On 8/14/15 8:50 AM, Willem de Bruijn wrote: +static int fanout_set_data_ebpf(struct packet_fanout *f, char __user *data, + unsigned int len) +{ + struct bpf_prog *new

[PATCH net-next v2 1/4] packet: add classic BPF fanout mode

From: Willem de Bruijn will...@google.com Add fanout mode PACKET_FANOUT_CBPF that accepts a classic BPF program to select a socket. This avoids having to keep adding special case fanout modes. One example use case is application layer load balancing. The QUIC protocol, for instance, encodes

[PATCH net-next v2 2/4] packet: add extended BPF fanout mode

From: Willem de Bruijn will...@google.com Add fanout mode PACKET_FANOUT_EBPF that accepts an en extended BPF program to select a socket. Update the internal eBPF program by passing to socket option SOL_PACKET/PACKET_FANOUT_DATA a file descriptor returned by bpf(). Signed-off-by: Willem de

[PATCH net-next v2 3/4] selftests/net: test classic bpf fanout mode

From: Willem de Bruijn will...@google.com Test PACKET_FANOUT_CBPF by inserting a cBPF program that selects a socket by payload. Requires modifying the test program to send packets with multiple payloads. Also fix a bug in testing the return value of mmap() Signed-off-by: Willem de Bruijn

[PATCH net-next v2 4/4] selftests/net: test extended BPF fanout mode

From: Willem de Bruijn will...@google.com Test PACKET_FANOUT_EBPF by inserting a program into the the kernel with bpf(), then attaching it to the fanout group. Observe the same payload-based distribution as in the PACKET_FANOUT_CBPF test. Signed-off-by: Willem de Bruijn will...@google.com

[PATCH net-next v2 0/4] packet: add cBPF and eBPF fanout modes

From: Willem de Bruijn will...@google.com Allow programmable fanout modes. Support both classical BPF programs passed directly and extended BPF programs passed by file descriptor. One use case is packet steering by deep packet inspection, for instance for packet steering by application layer

Re: [PATCH net-next 2/4] packet: add eBPF fanout mode

On Fri, Aug 14, 2015 at 3:46 PM, Daniel Borkmann dan...@iogearbox.net wrote: On 08/14/2015 09:27 PM, Willem de Bruijn wrote: ... Btw, in case someone sets sock_flag(sk, SOCK_FILTER_LOCKED), perhaps we should also apply it on fanout? Good point. With classic bpf, packet access control

[PATCH net-next 1/4] packet: add BPF fanout mode

From: Willem de Bruijn will...@google.com Add a fanout mode that accepts a BPF program to select a socket. This avoids having to keep adding special case fanout modes. One example use case is application layer load balancing. The QUIC protocol, for instance, encodes a connection ID in UDP

[PATCH net-next 4/4] selftests/net: test eBPF fanout mode

From: Willem de Bruijn will...@google.com Test PACKET_FANOUT_EBPF by inserting a program into the the kernel with bpf(), then attaching it to the fanout group. Observe the same payload-based distribution as in the PACKET_FANOUT_BPF test. Signed-off-by: Willem de Bruijn will...@google.com

[PATCH net-next 3/4] selftests/net: test bpf fanout mode

From: Willem de Bruijn will...@google.com Test PACKET_FANOUT_BPF by inserting a BPF program that selects a socket by payload. Requires modifying the test program to send packets with multiple payloads. Also fix a bug in testing the return value of mmap() Signed-off-by: Willem de Bruijn

[PATCH net-next 0/4] packet: add BPF and eBPF fanout modes

From: Willem de Bruijn will...@google.com Allow programmable fanout modes. Support both classical BPF programs passed directly and eBPF programs passed by file descriptor. One use case is packet steering by deep packet inspection, for instance for packet steering by application layer header

[PATCH net-next 2/4] packet: add eBPF fanout mode

From: Willem de Bruijn will...@google.com Add a fanout mode that accepts an eBPF program to select a socket. Update the internal eBPF program by passing to socket option SOL_PACKET/PACKET_FANOUT_DATA a file descriptor returned by bpf(). Signed-off-by: Willem de Bruijn will...@google.com

Re: [PATCH] packet: Allow packets with only a header (but no payload)

On Tue, Jul 21, 2015 at 12:14 PM, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: 9c70776 added validation for the packet size in packet_snd. This change enforced that every packet needs a long enough header and at least one byte payload. However, when trying to establish a

Re: [PATCH] packet: Allow packets with only a header (but no payload)

On Tue, Jul 21, 2015 at 12:38 PM, Martin Blumenstingl martin.blumensti...@googlemail.com wrote: Hi Willem, On Tue, Jul 21, 2015 at 6:28 PM, Willem de Bruijn will...@google.com wrote: Interesting. 9c7077622dd9 only extended the check from tpacket_snd to packet_snd to make the two paths

Re: [PATCH net v2 3/3] packet: fix tpacket_snd max frame and vlan handling

On Tue, Nov 10, 2015 at 6:51 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 11/11/2015 12:24 AM, Willem de Bruijn wrote: >> >> On Tue, Nov 10, 2015 at 6:12 PM, Daniel Borkmann <dan...@iogearbox.net> >> wrote: >>> >>

Re: [PATCH net v2 3/3] packet: fix tpacket_snd max frame and vlan handling

> if (sock->type == SOCK_DGRAM) { > - err = dev_hard_header(skb, dev, ntohs(proto), addr, > - NULL, tp_len); > + /* In DGRAM sockets, we expect struct sockaddr_ll was filled > +* via struct msghdr, so we have dest

Re: [PATCH net v2 3/3] packet: fix tpacket_snd max frame and vlan handling

On Tue, Nov 10, 2015 at 6:12 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 11/10/2015 11:52 PM, Willem de Bruijn wrote: >>> >>> if (sock->type == SOCK_DGRAM) { >>> - err = dev_hard_header(skb, dev, ntohs(proto), addr, >>&

Re: [PATCH] packet: Allow packets with only a header (but no payload)

On Sat, Nov 7, 2015 at 8:11 AM, Felix Fietkau <n...@openwrt.org> wrote: > On 2015-07-31 00:15, Martin Blumenstingl wrote: >> On Wed, Jul 29, 2015 at 8:05 AM, Willem de Bruijn <will...@google.com> wrote: >>> Martin, to return to your initial statement that PPPoE PA

Re: [PATCH net v3 4/5] packet: infer protocol from ethernet header if unset

Reported-by: Eric Dumazet <eduma...@google.com> > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> Acked-by: Willem de Bruijn <will...@google.com> > --- > net/packet/af_packet.c | 11 +++ > 1 file changed, 11 insertions(+) > > diff --git a/net/pac

Re: [PATCH net v3 5/5] packet: fix tpacket_snd max frame len

for SOCK_DGRAM, > the extra VLAN_HLEN could be possible in both cases. Presumably, the > reserve code was copied from packet_snd(), but later on missed the > check. Make it similar as we have it in packet_snd(). > > Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap") >

Re: [PATCH net v3 3/5] packet: only allow extra vlan len on ethernet devices

On Wed, Nov 11, 2015 at 6:07 PM, Daniel Borkmann <dan...@iogearbox.net> wrote: > On 11/11/2015 11:55 PM, Willem de Bruijn wrote: >> >> On Wed, Nov 11, 2015 at 5:25 PM, Daniel Borkmann <dan...@iogearbox.net> >> wrote: > > ... >>> >>> +

Re: net: heap-out-of-bounds in sock_setsockopt

> > Hmm, we should exclude the raw socket case, something like the > following, but I am not sure if the check is too strict or not, also > not sure if we should return an error for this raw socket case. No, SOF_TIMESTAMPING_OPT_ID with SOCK_RAW/IPPROTO_TCP is legitimate. It should fall through

Re: [Patch net] net: check both type and procotol for tcp sockets

gt;sk_type and sk->sk_protocol to ensure > it is a tcp socket. > > Willem points out __skb_complete_tx_timestamp() needs to fix as well. > > Reported-by: Dmitry Vyukov <dvyu...@google.com> > Cc: Willem de Bruijn <willemdebruijn.ker...@gmail.com> > Cc: Eric Dum

Re: [PATCH v2] soreuseport: add compat case for setsockopt SO_ATTACH_REUSEPORT_CBPF

> Acked-by: Daniel Borkmann > > [ Cc Willem: I believe we also need something similar for PACKET_FANOUT_DATA > when PACKET_FANOUT_CBPF is requested since we have the same issue with the > pointer in struct sock_fprog there, too. ] Indeed. I'll send a patch in a few days

[PATCH net] packet: compat support for sock_fprog

From: Willem de Bruijn <will...@google.com> Socket option PACKET_FANOUT_DATA takes a struct sock_fprog as argument if PACKET_FANOUT has mode PACKET_FANOUT_CBPF. This structure contains a pointer into user memory. If userland is 32-bit and kernel is 64-bit the two disagree about the

Re: [Bug 120441] af_packet no longer uses symmetric hashing

>> Isn't a symmetric hashing for af-packet something very fundamental? >> Looks much more like a bug to me. > > > I agree it would be useful resp. fundamental. I'm not quite sure whether > PACKET_FANOUT_HASH always had this guarantee since the initial > implementation It is based on rxhash, which

[PATCH net] sock_diag: do not broadcast raw socket destruction

From: Willem de Bruijn <will...@google.com> Diag intends to broadcast tcp_sk and udp_sk socket destruction. Testing sk->sk_protocol for IPPROTO_TCP/IPPROTO_UDP alone is not sufficient for this. Raw sockets can have the same type. Add a test for sk->sk_type. Fixes: eb4cb008529c

[PATCH net] sock_diag: invert socket destroy broadcast check

From: Willem de Bruijn <will...@google.com> Socket destruction is only broadcast for a socket sk if a diag listener is registered and sk is not a kernel socket. Invert the test to not even check for listeners for kernel sockets. The sock_diag_has_destroy_listeners invocation derefe

Re: [PATCH net] sock_diag: invert socket destroy broadcast check

On Fri, Jun 24, 2016 at 4:41 PM, Eric W. Biederman <ebied...@xmission.com> wrote: > Willem de Bruijn <willemdebruijn.ker...@gmail.com> writes: > >> From: Willem de Bruijn <will...@google.com> >> >> Socket destruction is only broadcast for a socket sk

[PATCH net-next v2 1/4] packet: move vnet_hdr code to helper functions

From: Willem de Bruijn <will...@google.com> packet_snd and packet_rcv support virtio net headers for GSO. Move this logic into helper functions to be able to reuse it in tpacket_snd and tpacket_rcv. This is a straighforward code move with one exception. Instead of creating and passing a se

[PATCH net-next v2 2/4] packet: vnet_hdr support for tpacket_rcv

From: Willem de Bruijn <will...@google.com> Support socket option PACKET_VNET_HDR together with PACKET_RX_RING. When enabled, a struct virtio_net_hdr will precede the data in the packet ring slots. Verified with test program at github.com/wdebruij/kerneltools/blob/master

[PATCH net-next v2 4/4] packet: tpacket_snd gso and checksum offload

From: Willem de Bruijn <will...@google.com> Support socket option PACKET_VNET_HDR together with PACKET_TX_RING. When enabled, a struct virtio_net_hdr is expected to precede the data in the ring. The vnet option must be set before the ring is created. The implementation reuses the ex

[PATCH net-next v2 3/4] packet: parse tpacket header before skb alloc

From: Willem de Bruijn <will...@google.com> GSO packet headers must be stored in the linear skb segment. Move tpacket header parsing before sock_alloc_send_skb. The GSO follow-on patch will later increase the skb linear argument to sock_alloc_send_skb if needed for large packets. The

[PATCH net-next v2 0/4] packet: tpacket gso and csum offload

From: Willem de Bruijn <will...@google.com> Extend PACKET_VNET_HDR socket option support to packet sockets with memory mapped rings. Patches 2 and 4 add support to tpacket_rcv and tpacket_snd. Patch 1 prepares for this by moving the relevant virtio_net_hdr logic out of packet_snd and pack

Re: [PATCH net-next 4/4] packet: tpacket_snd gso and checksum offload

> union tpacket_uhdr ph; On Tue, Feb 2, 2016 at 10:56 AM, Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > From: Willem de Bruijn <will...@google.com> > > Support socket option PACKET_VNET_HDR together with PACKET_TX_RING. >> > Signed-off-by: Wil

[PATCH net-next 0/4] packet: tpacket gso and csum offload

From: Willem de Bruijn <will...@google.com> Extend PACKET_VNET_HDR socket option support to packet sockets with memory mapped rings (PACKET_RX_RING, PACKET_TX_RING). Patches 2 and 4 add support to tpacket_rcv and tpacket_snd. Patch 1 prepares for this by moving the relevant virtio_net_hdr

[PATCH net-next 3/4] packet: parse tpacket header before skb alloc

From: Willem de Bruijn <will...@google.com> GSO packet headers must be stored in the linear skb segment. Move tpacket header parsing before sock_alloc_send_skb. The GSO follow-on patch will later increase the skb linear argument to sock_alloc_send_skb if needed for large packets. The

[PATCH net-next 4/4] packet: tpacket_snd gso and checksum offload

From: Willem de Bruijn <will...@google.com> Support socket option PACKET_VNET_HDR together with PACKET_TX_RING. When enabled, a struct virtio_net_hdr is expected to precede the data in the ring. The vnet option must be set before the ring is created. The implementation reuses the ex

[PATCH net-next 1/4] packet: move vnet_hdr code to helper functions

From: Willem de Bruijn <will...@google.com> packet_snd and packet_rcv support virtio net headers for GSO. Move this logic into helper functions to be able to reuse it in tpacket_snd and tpacket_rcv. This is a straighforward code move with one exception. Instead of creating and passing a se

Re: Sending short raw packets using sendmsg() broke

On Fri, Feb 26, 2016 at 12:46 PM, David Miller <da...@davemloft.net> wrote: > From: Willem de Bruijn <willemdebruijn.ker...@gmail.com> > Date: Fri, 26 Feb 2016 12:33:13 -0500 > >> Right. The simplest, if hacky, fix is to add something along the lines of &g

Re: Sending short raw packets using sendmsg() broke

> Commit 9c7077622dd9174 added a check, ll_header_truncated(), which requires > that a packet transmitted using sendmsg() with PF_PACKET, SOCK_RAW must be > longer than dev->hard_header_len. > > https://github.com/torvalds/linux/commit/9c7077622dd9174 >

Re: Sending short raw packets using sendmsg() broke

On Fri, Feb 26, 2016 at 9:44 AM, Alan Cox wrote: > On Thu, 2016-02-25 at 15:26 -0500, David Miller wrote: >> From: Heikki Hannikainen >> Date: Thu, 25 Feb 2016 21:36:07 +0200 (EET) >> >> > Commit 9c7077622dd9174 added a check, ll_header_truncated(), which

Re: [PATCH net-next 0/3] validate variable length ll headers

On Wed, Mar 9, 2016 at 10:13 PM, David Miller <da...@davemloft.net> wrote: > From: Willem de Bruijn <willemdebruijn.ker...@gmail.com> > Date: Wed, 9 Mar 2016 21:58:31 -0500 > >> Allow device-specific validation of link layer headers. Existing >> che

[PATCH net-next 0/3] validate variable length ll headers

From: Willem de Bruijn <will...@google.com> Allow device-specific validation of link layer headers. Existing checks drop all packets shorter than hard_header_len. For variable length protocols, such packets can be valid. patch 1 adds header_ops.validate and dev_validate_header patch 2 impl

[PATCH net-next 1/3] net: validate variable length ll headers

From: Willem de Bruijn <will...@google.com> Netdevice parameter hard_header_len is variously interpreted both as an upper and lower bound on link layer header length. The field is used as upper bound when reserving room at allocation, as lower bound when validating user input in PF_

[PATCH net-next 3/3] packet: validate variable length ll headers

From: Willem de Bruijn <will...@google.com> Replace link layer header validation check ll_header_truncate with more generic dev_validate_header. Validation based on hard_header_len incorrectly drops valid packets in variable length protocols, such as AX25. dev_validate_header

[PATCH net-next 2/3] ax25: add link layer header validation function

From: Willem de Bruijn <will...@google.com> As variable length protocol, AX25 fails link layer header validation tests based on a minimum length. header_ops.validate allows protocols to validate headers that are shorter than hard_header_len. Implement this callback for AX25. See als

Re: [net-next RFC 0/4] SO_BINDTOSUBNET

> - write a bpf filter like this: .. > > - compile it: > $ clang -target bpf -c -o socket_bpf.o socket_bpf.c > > - add this to your server.c: > bpf_load_file("/path/to/socket_bpf.o"); > setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, prog_fd, > sizeof(prog_fd[0])); > > - link

Re: [PATCH net-next 5/8] ipv4: process socket-level control messages in IPv4

ntrol messages. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH net-next 4/8] sock: accept SO_TIMESTAMPING flags in socket cmsg

e value of other flags. > > This patch implements validating the control message and setting > tsflags in struct sockcm_cookie. Next commits in this series will > actually implement timestamping per write for different protocols. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH net-next 3/8] tcp: use one bit in TCP_SKB_CB to mark ACK timestamps

checks in tcp_ack_tstamp are not > modified and work as before. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH net-next 2/8] tcp: accept SOF_TIMESTAMPING_OPT_ID for passive TFO

> To address these, instead of limiting the option to the > ESTABLISHED state, accept the SOF_TIMESTAMPING_OPT_ID option as > long as the connection is not in LISTEN or CLOSE states. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH net-next 6/8] ipv6: process socket-level control messages in IPv6

ssage cookie for IPv6? > > Note that this commit interprets new control messages that > were ignored before. As such, this commit does not change > the behavior of IPv6 control messages. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH net-next 0/8] add TX timestamping via cmsg

>> Nice patches! This does not yet solve the append issue that your MSG_EOR patch addresses, of course. The straightforward jump to new_segment that I proposed as simplification is more properly a "start-of-record" than "end-of-record" signal. It is probably preferable to indeed be able to pass

Re: [PATCH net-next 8/8] sock: document timestamping via cmsg in Documentation

On Wed, Mar 30, 2016 at 6:37 PM, Soheil Hassas Yeganeh <soheil.k...@gmail.com> wrote: > From: Soheil Hassas Yeganeh <soh...@google.com> > > Update docs and add code snippet for using cmsg for timestamping. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.co

Re: [PATCH net-next 7/8] sock: enable timestamping using control messages

AMPING_OPT_ID) using > socket options and then should ask for SOF_TIMESTAMPING_TX_* > using control messages per sendmsg to sample timestamps for each > write. > > Signed-off-by: Soheil Hassas Yeganeh <soh...@google.com> Acked-by: Willem de Bruijn <will...@google.com>

Re: [PATCH] packet: uses kfree_skb() for drop.

On Wed, Apr 6, 2016 at 12:54 PM, Weongyo Jeong wrote: > consume_skb() isn't for drop or error cases. kfree_skb() is more proper > one. > Signed-off-by: Weongyo Jeong > --- > net/packet/af_packet.c | 2 +- > 1 file changed, 1 insertion(+), 1

Re: Boot failure when using NFS on OMAP based evms

On Thu, Apr 7, 2016 at 10:36 AM, Franklin S Cooper Jr. <fcoo...@ti.com> wrote: > > > On 04/06/2016 09:22 PM, Willem de Bruijn wrote: >> On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. <fcoo...@ti.com> wrote: >>> Hi All, >>> >>> Currently

[PATCH net-next 0/2] fix udp pull header breakage

From: Willem de Bruijn <will...@google.com> Commit e6afc8ace6dd ("udp: remove headers from UDP packets before queueing") modified udp receive processing to pull headers before enqueue and to not expect them on dequeue. The patch missed protocols on top of udp with in-kernel

[PATCH net-next 1/2] sunrpc: do not pull udp headers on receive

From: Willem de Bruijn <will...@google.com> Commit e6afc8ace6dd modified the udp receive path by pulling the udp header before queuing an skbuff onto the receive queue. Sunrpc also calls skb_recv_datagram to dequeue an skb from a udp socket. Modify this receive path to also no longer expe

Re: Boot failure when using NFS on OMAP based evms

Currently linux-next is failing to boot via NFS on my AM335x GP evm, AM437x GP evm and Beagle X15. I bisected the problem down to the commit "udp: remove headers from UDP packets before queueing". >>> >>> Thanks for the report, and apologies for breaking your configuration. >>> I

[PATCH net-next 2/2] rxrpc: do not pull udp headers on receive

From: Willem de Bruijn <will...@google.com> Commit e6afc8ace6dd modified the udp receive path by pulling the udp header before queuing an skbuff onto the receive queue. Rxrpc also calls skb_recv_datagram to dequeue an skb from a udp socket. Modify this receive path to also no longer expe

[PATCH net-next 1/2] udp: do not expect udp headers on ioctl SIOCINQ

From: Willem de Bruijn <will...@google.com> On udp sockets, ioctl SIOCINQ returns the payload size of the first packet. Since commit e6afc8ace6dd pulled the headers, the result is incorrect when subtracting header length. Remove that operation. Fixes: e6afc8ace6dd ("udp: remove heade

[PATCH net-next 0/2] fix two more udp pull header issues

From: Willem de Bruijn <will...@google.com> Follow up patches to the fixes to RxRPC and SunRPC. A scan of the code showed two other interfaces that expect UDP packets to have a udphdr when queued: read packet length with ioctl SIOCINQ and receive payload checksum with socket option IP_CH

[PATCH net-next 2/2] udp: do not expect udp headers in recv cmsg IP_CMSG_CHECKSUM

From: Willem de Bruijn <will...@google.com> On udp sockets, recv cmsg IP_CMSG_CHECKSUM returns a checksum over the packet payload. Since commit e6afc8ace6dd pulled the headers, taking skb->data as the start of transport header is incorrect. Use the transport header pointer. Also, whe

Re: [PATCH v2] packet: uses kfree_skb() for drops or errors.

On Wed, Apr 6, 2016 at 5:14 PM, Weongyo Jeong wrote: > consume_skb() isn't for drop or error cases for drop or error -> for error > that kfree_skb() is more proper > one. At this patch, it fixed tpacket_rcv() and packet_rcv() to be > consistent for error or non-error

Re: Boot failure when using NFS on OMAP based evms

On Wed, Apr 6, 2016 at 7:12 PM, Franklin S Cooper Jr. wrote: > Hi All, > > Currently linux-next is failing to boot via NFS on my AM335x GP evm, > AM437x GP evm and Beagle X15. I bisected the problem down to the commit > "udp: remove headers from UDP packets before queueing". > > I

[PATCH net-next v2 0/3] udp: support SO_PEEK_OFF

From: Willem de Bruijn <will...@google.com> Support peeking at a non-zero offset for UDP sockets. Match the existing behavior on Unix datagram sockets. 1/3 makes the sk_peek_offset functions safe to use outside locks 2/3 removes udp headers before enqueue, to simplify offset arithmet

[PATCH net-next v2 3/3] udp: enable MSG_PEEK at non-zero offset

so peek and read operations can run concurrently. Only the last store to sk_peek_off is preserved. Signed-off-by: Sam Kumar <samanthaku...@google.com> Signed-off-by: Willem de Bruijn <will...@google.com> --- include/linux/skbuff.h | 7 ++- include/net/sock.h | 2 ++ net/core/datag

  1   2   3   4   5   6   7   8   9   10   >