[PATCH net-next RFC v1 03/27] afnetns: prepare for integration into ipv4

the appropriate afnetns inode number, so a match with the appropriate afnet namespace can be done in user space. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/linux/inetdevice.h | 3 +++ include/net/afnetns.h| 2 ++ include/uapi/linux/if_addr.

[PATCH RFC iproute v1 0/4] afnetns: add support for afnetns

This patchset adds support for afnetns to iproute. For more information on afnetns please look at the kernel patchset. Patches for util-linux commands, namely nsenter and unshare, is available here: <https://github.com/hannes/util-linux/tree/afnetns> Hannes Frederic Sowa (4): afnetn

[PATCH net] dccp: fix memory leak during tear-down of unsuccessful connection request

Hannes Frederic Sowa <han...@stressinduktion.org> --- net/dccp/ccids/ccid2.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/dccp/ccids/ccid2.c b/net/dccp/ccids/ccid2.c index f053198e730c48..5e3a7302f7747e 100644 --- a/net/dccp/ccids/ccid2.c +++ b/net/dccp/ccids/ccid2.c @@ -749,6 +749

[PATCH RFC iproute v1 2/4] afnetns: support for ipv4/v6 address management

Support ip address add xxx.yyy.zzz.lll/kk dev eth0 afnetns Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/libnetlink.h| 7 +++ include/linux/if_addr.h | 2 ++ include/namespace.h | 2 ++ ip/ipaddress.c

[PATCH RFC iproute v1 3/4] afnetns: introduce lib/afnetns.c and a name cache

This patch adds a name cache for afnetns, so we don't need to scan the inodes all the same again. This speeds up address list in case of many configured afnetns and ip addresses. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/afnetns.h | 6 ++ i

[PATCH net-next RFC v1 02/27] afnetns: basic namespace operations and representations

This patch adds the basic afnetns operations. Specifically it implements the /proc/self/ns/afnet operations which allow to basically manage afnetns namespaces plus, clone, unshare and setns. The afnetns is tracked in the nsproxy structure for each task_struct. Signed-off-by: Hannes Frederic Sowa

[PATCH RFC iproute v1 1/4] afnetns: add iproute bits for afnetns

Like ip netns, ip afnetns ... provides the basic utility features to create, delete afnet namespaces and execute commands inside afnetns. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/namespace.h | 5 ++ include/utils.h | 1 + ip/Makefile

[PATCH net] tun: fix premature POLLOUT notification on tun devices

no> Reported-by: Valdis Kletnieks <valdis.kletni...@vt.edu> Cc: Valdis Kletnieks <valdis.kletni...@vt.edu> Reported-by: Jonas Lippuner <jo...@lippuner.ca> Cc: Jonas Lippuner <jo...@lippuner.ca> Reported-by: aszlig <asz...@redmoonstudios.org> Cc: aszlig <asz...@r

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hello, On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > On 24.12.2016 00:39, George Spelvin wrote: > > > We just finished discussing why 8 bytes isn't enough. If you only > > > feed back 8 bytes, an attacker who can d

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hi, On 24.12.2016 00:39, George Spelvin wrote: > Hannes Frederic Sowa wrote: >> In general this looks good, but bitbuffer needs to be protected from >> concurrent access, thus needing at least some atomic instruction and >> disabling of interrupts for the lo

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

Hi, On Fri, 2016-12-23 at 13:26 -0500, George Spelvin wrote: > (Cc: list trimmed slightly as the topic is wandering a bit.) > > Hannes Frederic Sowa wrote: > > On Thu, 2016-12-22 at 19:07 -0500, George Spelvin wrote: > > > Adding might_lock() annotations wil

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On 23.12.2016 17:42, Andy Lutomirski wrote: > On Fri, Dec 23, 2016 at 8:23 AM, Andy Lutomirski <l...@amacapital.net> wrote: >> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann <dan...@iogearbox.net> >> wrote: >>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Thu, 2016-12-22 at 19:07 -0500, George Spelvin wrote: > Hannes Frederic Sowa wrote: > > A lockdep test should still be done. ;) > > Adding might_lock() annotations will improve coverage a lot. Might be hard to find the correct lock we take later down the code path, but if t

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Fri, 2016-12-23 at 11:04 +0100, Daniel Borkmann wrote: > On 12/22/2016 05:59 PM, Hannes Frederic Sowa wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa > > > <han...@stressinduktion.or

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On 22.12.2016 22:11, George Spelvin wrote: >> I do tend to like Ted's version in which we use batched >> get_random_bytes() output. If it's fast enough, it's simpler and lets >> us get the full strength of a CSPRNG. > > With the ChaCha20 generator, that's fine, although note that this abandons >

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On 22.12.2016 20:56, Andy Lutomirski wrote: > It's also not quite clear to me why userspace needs to be able to > calculate the digest on its own. A bpf(BPF_CALC_PROGRAM_DIGEST) > command that takes a BPF program as input and hashes it would seem to > serve the same purpose, and that would allow

Re: [PATCH 1/5 net-next] inet: replace ->bind_conflict with ->rcv_saddr_equal

On 21.12.2016 16:16, Josef Bacik wrote: > On Wed, Dec 21, 2016 at 10:06 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On Tue, 2016-12-20 at 15:07 -0500, Josef Bacik wrote: >>> The only difference between inet6_csk_bind_conflict and >>>

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 16:54, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 02:10:33PM +0100, Jason A. Donenfeld wrote: >> On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >>> following up on what appears to be a random subje

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 09:25 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 8:59 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > > > > You mean: > > > > >

Re: BPF hash algo (Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5)

On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > On Thu, Dec 22, 2016 at 7:51 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > > > Hi Hannes, > > > > > > On

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > Hi Hannes, > > On Thu, Dec 22, 2016 at 4:33 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, 2016-12-22 at 16:29 +0100, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 4:12 PM, Jason A. Donenfeld wrote: > > As a first step, I'm considering adding a patch to move halfmd4.c > > inside the ext4 domain, or at the very least, simply remove it from > >

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 14:10, Jason A. Donenfeld wrote: > On Thu, Dec 22, 2016 at 1:47 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> following up on what appears to be a random subject: ;) >> >> IIRC, ext4 code by default still uses half_md4 for hashin

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, 2016-12-22 at 00:41 -0500, Theodore Ts'o wrote: > On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > > > Funny -- while you guys were sending this back & forth, I was writing > > my reply to Andy which essentially arrives at the same conclusion. > > Given

Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On 22.12.2016 00:42, Andy Lutomirski wrote: > On Wed, Dec 21, 2016 at 3:02 PM, Jason A. Donenfeld wrote: >> unsigned int get_random_int(void) >> { >> - __u32 *hash; >> - unsigned int ret; >> - >> - if (arch_get_random_int()) >> - return ret; >> -

Re: ipv6: handle -EFAULT from skb_copy_bits

On Wed, 2016-12-21 at 14:04 -0500, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Wed, 21 Dec 2016 13:41:13 +0100 > > > On Wed, 2016-12-21 at 13:27 +0100, Hannes Frederic Sowa wrote: > >> @@ -555,8 +566,8 @@ static int rawv6_p

Re: [PATCH 1/5 net-next] inet: replace ->bind_conflict with ->rcv_saddr_equal

On Tue, 2016-12-20 at 15:07 -0500, Josef Bacik wrote: > --- a/net/dccp/ipv6.c > +++ b/net/dccp/ipv6.c > @@ -926,7 +926,7 @@ static const struct inet_connection_sock_af_ops > dccp_ipv6_af_ops = { > .getsockopt= ipv6_getsockopt, > .addr2sockaddr = inet6_csk_addr2sockaddr, >

Re: [PATCH 3/5 net-next] inet: don't check for bind conflicts twice when searching for a port

On Tue, 2016-12-20 at 15:07 -0500, Josef Bacik wrote: > --- a/net/ipv4/inet_connection_sock.c > +++ b/net/ipv4/inet_connection_sock.c > @@ -92,7 +92,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum) > { > bool reuse = sk->sk_reuse && sk->sk_state != TCP_LISTEN; > struct

Re: [PATCH 1/5 net-next] inet: replace ->bind_conflict with ->rcv_saddr_equal

On Tue, 2016-12-20 at 15:07 -0500, Josef Bacik wrote: > The only difference between inet6_csk_bind_conflict and inet_csk_bind_conflict > is how they check the rcv_saddr. Since we want to be able to check the saddr > in > other places just drop the protocol specific ->bind_conflict and replace it

Re: ipv6: handle -EFAULT from skb_copy_bits

On Wed, 2016-12-21 at 13:27 +0100, Hannes Frederic Sowa wrote: > @@ -555,8 +566,8 @@ static int rawv6_push_pending_frames(struct sock *sk, > struct flowi6 *fl6, > goto out; > > offset = rp->offset; > - total_len = inet_sk(

Re: ipv6: handle -EFAULT from skb_copy_bits

On Tue, 2016-12-20 at 22:09 -0800, Cong Wang wrote: > On Tue, Dec 20, 2016 at 2:12 PM, Dave Jones wrote: > > fd = socket(AF_INET6, SOCK_RAW, 7); > > > > setsockopt(fd, SOL_IPV6, IPV6_CHECKSUM, , 4); > > setsockopt(fd, SOL_IPV6, IPV6_DSTOPTS, ,

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

On 19.12.2016 17:40, Eric Dumazet wrote: > On Mon, 2016-12-19 at 17:36 +0100, Hannes Frederic Sowa wrote: >> On 19.12.2016 17:17, Eric Dumazet wrote: >>> On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote: >>> >>>> >>>> +static inline

Re: [PATCH RFC net-next 2/7] net: add dst_pending_confirm flag to skbuff

On 19.12.2016 17:17, Eric Dumazet wrote: > On Sun, 2016-12-18 at 22:56 +0200, Julian Anastasov wrote: > >> >> +static inline void sock_confirm_neigh(struct sk_buff *skb, struct neighbour >> *n) >> +{ >> +if (unlikely(skb->dst_pending_confirm)) { >> +struct sock *sk = skb->sk;

Re: Soft lockup in inet_put_port on 4.6

>>>> >>>> On Fri, Dec 16, 2016 at 9:54 AM, Josef Bacik <jba...@fb.com> wrote: >>>>> >>>>> On Thu, Dec 15, 2016 at 7:07 PM, Hannes Frederic Sowa >>>>> <han...@stressinduktion.org> wrote: >>>>>> >

Re: [kernel-hardening] Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

On Fri, Dec 16, 2016, at 22:01, Jason A. Donenfeld wrote: > Yes, on x86-64. But on i386 chacha20 incurs nearly the same kind of > slowdown as siphash, so I expect the comparison to be more or less > equal. There's another thing I really didn't like about your chacha20 > approach which is that it

Re: Soft lockup in inet_put_port on 4.6

Hi Josef, On 15.12.2016 19:53, Josef Bacik wrote: > On Tue, Dec 13, 2016 at 6:32 PM, Tom Herbert wrote: >> On Tue, Dec 13, 2016 at 3:03 PM, Craig Gallek >> wrote: >>> On Tue, Dec 13, 2016 at 3:51 PM, Tom Herbert >>> wrote:

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 16.12.2016 00:43, Jason A. Donenfeld wrote: > Hi Hannes, > > Good news. > > On Thu, Dec 15, 2016 at 10:45 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >>> How's that sound? >> >> I am still very much concerned about the API. >

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 22:25, Jason A. Donenfeld wrote: > On Thu, Dec 15, 2016 at 10:17 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> And I was exactly questioning this. >> >> static unsigned int inet6_hash_frag(__be32 id

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 21:43, Jason A. Donenfeld wrote: > On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> ARM64 and x86-64 have memory operations that are not vector operations >> that operate on 128 bit memory. > > Fair enoug

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 22:04, Peter Zijlstra wrote: > On Thu, Dec 15, 2016 at 09:43:04PM +0100, Jason A. Donenfeld wrote: >> On Thu, Dec 15, 2016 at 9:31 PM, Hannes Frederic Sowa >> <han...@stressinduktion.org> wrote: >>> ARM64 and x86-64 have memory operations

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hello, On 15.12.2016 19:50, Jason A. Donenfeld wrote: > Hi David & Hannes, > > This conversation is veering off course. Why? > I think this doesn't really > matter at all. Gcc converts u64 into essentially a pair of u32 on > 32-bit platforms, so the alignment requirements for 32-bit is at a >

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 16:41, David Laight wrote: > Try (retyped): > > echo 'struct { long a; long long b; } s; int bar { return sizeof s; }' >foo.c > gcc [-m32] -O2 -S foo.c; cat foo.s > > And look at what is generated. I used __alignof__(unsigned long long) with -m32. >> Right now ipv6 addresses have

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 14:56, David Laight wrote: > From: Hannes Frederic Sowa >> Sent: 15 December 2016 12:50 >> On 15.12.2016 13:28, David Laight wrote: >>> From: Hannes Frederic Sowa >>>> Sent: 15 December 2016 12:23 >>> ... >>>> Hmm? Even the

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 13:28, David Laight wrote: > From: Hannes Frederic Sowa >> Sent: 15 December 2016 12:23 > ... >> Hmm? Even the Intel ABI expects alignment of unsigned long long to be 8 >> bytes on 32 bit. Do you question that? > > Yes. > > The linux ABI

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 12:04, David Laight wrote: > From: Hannes Frederic Sowa >> Sent: 14 December 2016 22:03 >> On 14.12.2016 13:46, Jason A. Donenfeld wrote: >>> Hi David, >>> >>> On Wed, Dec 14, 2016 at 10:56 AM, David Laight <david.lai...@aculab.com> &

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 15.12.2016 00:29, Jason A. Donenfeld wrote: > Hi Hannes, > > On Wed, Dec 14, 2016 at 11:03 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> I fear that the alignment requirement will be a source of bugs on 32 bit >> machines, where you cannot e

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

On 14.12.2016 13:46, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:56 AM, David Laight > wrote: >> ... >>> +u64 siphash24(const u8 *data, size_t len, const u8 key[SIPHASH24_KEY_LEN]) >> ... >>> + u64 k0 = get_unaligned_le64(key); >>> + u64

Re: Designing a safe RX-zero-copy Memory Model for Networking

On 14.12.2016 20:43, Christoph Lameter wrote: > On Wed, 14 Dec 2016, David Laight wrote: > >> If the kernel is doing ANY validation on the frames it must copy the >> data to memory the application cannot modify before doing the validation. >> Otherwise the application could change the data

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

Hey Jason, On 14.12.2016 20:38, Jason A. Donenfeld wrote: > On Wed, Dec 14, 2016 at 8:22 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> I don't think this helps. Did you test it? I don't see reason why >> padding could be left out between `d' and `end'

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On 14.12.2016 19:06, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 6:56 PM, David Miller wrote: >> Just marking the structure __packed, whether necessary or not, makes >> the compiler assume that the members are not aligned and causes >> byte-by-byte

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hello, On 14.12.2016 14:10, Jason A. Donenfeld wrote: > On Wed, Dec 14, 2016 at 12:21 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> Can you show or cite benchmarks in comparison with jhash? Last time I >> looked, especially for short inputs, siphash

Re: [PATCH v2 3/4] secure_seq: use siphash24 instead of md5_transform

On 14.12.2016 13:53, Jason A. Donenfeld wrote: > Hi David, > > On Wed, Dec 14, 2016 at 10:51 AM, David Laight > wrote: >> From: Jason A. Donenfeld >>> Sent: 14 December 2016 00:17 >>> This gives a clear speed and security improvement. Rather than manually >>> filling

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

Hello, On 14.12.2016 04:59, Jason A. Donenfeld wrote: > SipHash is a 64-bit keyed hash function that is actually a > cryptographically secure PRF, like HMAC. Except SipHash is super fast, > and is meant to be used as a hashtable keyed lookup function. Can you show or cite benchmarks in

Re: Designing a safe RX-zero-copy Memory Model for Networking

On 13.12.2016 17:10, Jesper Dangaard Brouer wrote: >> What is bad about RDMA is that it is a separate kernel subsystem. >> What I would like to see is a deeper integration with the network >> stack so that memory regions can be registred with a network socket >> and work requests then can be

Re: Soft lockup in inet_put_port on 4.6

On 12.12.2016 19:05, Josef Bacik wrote: > On Fri, Dec 9, 2016 at 11:14 PM, Eric Dumazet > wrote: >> On Fri, 2016-12-09 at 19:47 -0800, Eric Dumazet wrote: >> >>> >>> Hmm... Is your ephemeral port range includes the port your load >>> balancing app is using ? >> >> I

Re: fib_frontend: Add network specific broadcasts, when it takes a sense

On 12.12.2016 15:44, Brandon Philips wrote: > On Mon, Dec 12, 2016 at 9:30 AM, Jiri Benc wrote: >> On Fri, 9 Dec 2016 15:41:52 -0800, Brandon Philips wrote: >>> The issue we have: when creating the VXLAN interface and assigning it >>> an address we see a broadcast route being

Re: [iproute2 net-next 3/8] bpf: Add BPF_ macros

On 12.12.2016 01:53, David Ahern wrote: > Based on version in kernel repo, samples/bpf/libbpf.h > > Signed-off-by: David Ahern > --- > include/bpf_util.h | 179 > + > 1 file changed, 179 insertions(+) > > diff --git

Re: Soft lockup in inet_put_port on 4.6

Hello Tom, On Wed, Dec 7, 2016, at 00:06, Tom Herbert wrote: > We are seeing a fair number of machines getting into softlockup in 4.6 > kernel. As near as I can tell this is happening on the spinlock in > bind hash bucket. When inet_csk_get_port exits and does spinunlock_bh > the TCP timer runs

Re: [PATCH net-next] net: sock_rps_record_flow() is for connected sockets

Hello, On Thu, Dec 8, 2016, at 20:15, Tom Herbert wrote: > On Thu, Dec 8, 2016 at 10:02 AM, Eric Dumazet > wrote: > > On Thu, 2016-12-08 at 09:49 -0800, Tom Herbert wrote: > > > >> Of course that would only help on systems where no one enable encaps, > >> ie. looks good

Re: [PATCH v3 net-next 1/4] udp: add busylocks in RX path

Hi Eric, On Thu, Dec 8, 2016, at 20:41, Eric Dumazet wrote: > Idea of busylocks is to let producers grab an extra spinlock > to relieve pressure on the receive_queue spinlock shared by consumer. > > This behavior is requested only once socket receive queue is above > half occupancy. > > Under

Re: [PATCH] net: handle no dst on skb in icmp6_send

Hello David, On Mon, Nov 28, 2016, at 22:13, David Miller wrote: > From: David Ahern > Date: Sun, 27 Nov 2016 18:52:53 -0800 > > > Andrey reported the following while fuzzing the kernel with syzkaller: > ... > > icmp6_send / icmpv6_send is invoked for both rx and tx

Re: Misalignment, MIPS, and ip_hdr(skb)->version

Hi Jason, On 07.12.2016 19:35, Jason A. Donenfeld wrote: > I receive encrypted packets with a 13 byte header. I decrypt the > ciphertext in place, and then discard the header. I then pass the > plaintext to the rest of the networking stack. The plaintext is an IP > packet. Due to the 13 byte

Re: [PATCH] net/udp: do not touch skb->peeked unless really needed

On Wed, Dec 7, 2016, at 18:32, Eric Dumazet wrote: > On Wed, 2016-12-07 at 17:09 +, David Laight wrote: > > From: Paolo Abeni > > > Sent: 06 December 2016 17:08 > > ... > > > @@ -79,6 +82,9 @@ struct udp_sock { > > > int (*gro_complete)(struct sock *sk, > > >

Re: arp_filter and IPv6 ND

On 03.12.2016 15:21, Saku Ytti wrote: > On 2 December 2016 at 20:39, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > Hey, > >> E.g. you can use IP addresses bound to other interfaces to send replys >> on another interface. This can be useful if y

Re: bpf bounded loops. Was: [flamebait] xdp

On 05.12.2016 17:54, Edward Cree wrote: > On 05/12/16 16:50, Hannes Frederic Sowa wrote: >> On 05.12.2016 17:40, Edward Cree wrote: >>> I may be completely mistaken here, but can't the verifier unroll the loop >>> 'for >>> verification' without it actually be

Re: bpf bounded loops. Was: [flamebait] xdp

On 05.12.2016 17:40, Edward Cree wrote: > On 02/12/16 19:25, Hannes Frederic Sowa wrote: >> On 02.12.2016 19:39, Alexei Starovoitov wrote: >>> Hannes, >>> Not too long ago you proposed a very interesting idea to add >>> support for bounded loops wit

Re: [flamebait] xdp Was: Re: bpf bounded loops. Was: [flamebait] xdp

Hello, On 03.12.2016 00:34, Alexei Starovoitov wrote: > On Fri, Dec 02, 2016 at 08:42:41PM +0100, Hannes Frederic Sowa wrote: >> On Fri, Dec 2, 2016, at 20:25, Hannes Frederic Sowa wrote: >>> On 02.12.2016 19:39, Alexei Starovoitov wrote: >>>> On Thu, Dec 01, 20

Re: bpf bounded loops. Was: [flamebait] xdp

On Fri, Dec 2, 2016, at 20:42, John Fastabend wrote: > On 16-12-02 11:25 AM, Hannes Frederic Sowa wrote: > > Hi, > > > > On 02.12.2016 19:39, Alexei Starovoitov wrote: > >> On Thu, Dec 01, 2016 at 10:27:12PM +0100, Hannes Frederic Sowa wrote: > >>>

Re: bpf bounded loops. Was: [flamebait] xdp

On Fri, Dec 2, 2016, at 20:25, Hannes Frederic Sowa wrote: > On 02.12.2016 19:39, Alexei Starovoitov wrote: > > On Thu, Dec 01, 2016 at 10:27:12PM +0100, Hannes Frederic Sowa wrote: > >> like") and the problematic of parsing DNS packets in XDP due to string > >> pr

Re: bpf bounded loops. Was: [flamebait] xdp

Hi, On 02.12.2016 19:39, Alexei Starovoitov wrote: > On Thu, Dec 01, 2016 at 10:27:12PM +0100, Hannes Frederic Sowa wrote: >> like") and the problematic of parsing DNS packets in XDP due to string >> processing and looping inside eBPF. > > Hannes, > Not too

Re: arp_filter and IPv6 ND

Hi, On 02.12.2016 18:51, Saku Ytti wrote: > On 2 December 2016 at 18:45, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > >> next-hop-self attribute on your neighbor in that direction? BGP in >> general doesn't lead to ND entry installs, protocols li

Re: [flamebait] xdp, well meaning but pointless

On 02.12.2016 17:59, Tom Herbert wrote: > On Fri, Dec 2, 2016 at 3:54 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> On 02.12.2016 11:24, Jesper Dangaard Brouer wrote: >>> On Thu, 1 Dec 2016 13:51:32 -0800 >>> Tom Herbert <t...@herbertla

Re: arp_filter and IPv6 ND

Hello, On 02.12.2016 16:42, Saku Ytti wrote: > On 2 December 2016 at 16:08, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > Hey, > >> May I ask why you want to turn it off? > > Certainly. I don't want device to answer with link address

Re: arp_filter and IPv6 ND

On 02.12.2016 13:51, Saku Ytti wrote: > net.ipv4.conf.all.arp_filter appears not to have IPv6 counter part. > Or am I missing something? That is Linux does answer to ND queries for > unrelated interfaces by default, and I can't seem to find way to turn > that off. May I ask why you want to turn

Re: [flamebait] xdp, well meaning but pointless

On 02.12.2016 11:24, Jesper Dangaard Brouer wrote: > On Thu, 1 Dec 2016 13:51:32 -0800 > Tom Herbert wrote: > The technical plenary at last IETF on Seoul a couple of weeks ago was exclusively focussed on DDOS in light of the recent attack against Dyn. There

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 02.12.2016 00:14, Ido Schimmel wrote: [...] >> Basically, if you delete a node right now the kernel might simply do a >> RCU_INIT_POINTER(ptr_location, NULL), which has absolutely no barriers >> or synchronization with the reader side. Thus you might get a callback >> from the notifier for a

Re: Initial thoughts on TXDP

On 01.12.2016 21:13, Sowmini Varadhan wrote: > On (12/01/16 11:05), Tom Herbert wrote: >> >> Polling does not necessarily imply that networking monopolizes the CPU >> except when the CPU is otherwise idle. Presumably the application >> drives the polling when it is ready to receive work. > > I'm

Re: Initial thoughts on TXDP

Side note: On 01.12.2016 20:51, Tom Herbert wrote: >> > E.g. "mini-skb": Even if we assume that this provides a speedup >> > (where does that come from? should make no difference if a 32 or >> > 320 byte buffer gets allocated). >> > > It's the zero'ing of three cache lines. I believe we talked

Re: [PATCH net-next v3] ipv6 addrconf: Implemented enhanced DAD (RFC7527)

y: Bob Gilligan <gilli...@arista.com> > --- Reviewed-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks! > @@ -794,6 +808,17 @@ static void ndisc_recv_ns(struct sk_buff *skb) > have_ifp: > if (ifp->flags & (I

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 30.11.2016 19:22, Ido Schimmel wrote: > On Wed, Nov 30, 2016 at 05:49:56PM +0100, Hannes Frederic Sowa wrote: >> On 30.11.2016 17:32, Ido Schimmel wrote: >>> On Wed, Nov 30, 2016 at 04:37:48PM +0100, Hannes Frederic Sowa wrote: >>>> On 30.11.2016 11:09, Jir

Re: [flamebait] xdp, well meaning but pointless

On 01.12.2016 22:12, Tom Herbert wrote: > On Thu, Dec 1, 2016 at 12:44 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> Hello, >> >> this is a good conversation and I simply want to bring my worries >> across. I don't have good solutions

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 01.12.2016 21:54, Ido Schimmel wrote: > On Thu, Dec 01, 2016 at 09:40:48PM +0100, Hannes Frederic Sowa wrote: >> On 01.12.2016 21:04, David Miller wrote: >>> >>> Hannes and Ido, >>> >>> It looks like we are very close to having this in mergable shap

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 30.11.2016 17:32, Ido Schimmel wrote: > Hi Hannes, > > On Wed, Nov 30, 2016 at 04:37:48PM +0100, Hannes Frederic Sowa wrote: >> On 30.11.2016 11:09, Jiri Pirko wrote: >>> From: Ido Schimmel <ido...@mellanox.com> >>> >>> Make sure the device h

Re: [flamebait] xdp, well meaning but pointless

. On 01.12.2016 17:28, Thomas Graf wrote: > On 12/01/16 at 04:52pm, Hannes Frederic Sowa wrote: >> First of all, this is a rant targeted at XDP and not at eBPF as a whole. >> XDP manipulates packets at free will and thus all security guarantees >> are off as well as in any user space solution

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 01.12.2016 21:04, David Miller wrote: > > Hannes and Ido, > > It looks like we are very close to having this in mergable shape, can > you guys work out this final issue and figure out if it really is > a merge stopped or not? Sure, if the fib notification register could be done under

Re: [flamebait] xdp, well meaning but pointless

On 01.12.2016 17:19, David Miller wrote: > Saying that ntuple filters can handle the early drop use case doesn't > take into consideration the nature of the tables (hundreds of > thousands of "evil" IP addresses), whether hardware can actually > handle that (it can't), and whether simple IP

Re: [flamebait] xdp, well meaning but pointless

Hi, On 01.12.2016 15:58, Thomas Graf wrote: > On 12/01/16 at 10:11am, Florian Westphal wrote: >> Aside from this, XDP, like DPDK, is a kernel bypass. >> You might say 'Its just stack bypass, not a kernel bypass!'. >> But what does that mean exactly? That packets can still be passed >> onward to

Re: [flamebait] xdp, well meaning but pointless

On 01.12.2016 10:11, Florian Westphal wrote: > [ As already mentioned in my reply to Tom, here is > the xdp flamebait/critique ] > > Lots of XDP related patches started to appear on netdev. > I'd prefer if it would stop... I discussed this with Florian and helped with the text. I want to mention

Re: [RFC PATCH net-next v2] ipv6: implement consistent hashing for equal-cost multipath routing

On Wed, Nov 30, 2016, at 20:49, David Miller wrote: > From: David Lebrun > Date: Tue, 29 Nov 2016 18:15:18 +0100 > > > When multiple nexthops are available for a given route, the routing engine > > chooses a nexthop by computing the flow hash through

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 30.11.2016 17:32, Ido Schimmel wrote: > Hi Hannes, > > On Wed, Nov 30, 2016 at 04:37:48PM +0100, Hannes Frederic Sowa wrote: >> On 30.11.2016 11:09, Jiri Pirko wrote: >>> From: Ido Schimmel <ido...@mellanox.com> >>> >>> Make sure the device h

Re: [patch net-next v3 11/12] mlxsw: spectrum_router: Request a dump of FIB tables during init

On 30.11.2016 11:09, Jiri Pirko wrote: > From: Ido Schimmel > > Make sure the device has a complete view of the FIB tables by invoking > their dump during module init. > > Signed-off-by: Ido Schimmel > Signed-off-by: Jiri Pirko >

Re: [RFC PATCH net-next] ipv6: implement consistent hashing for equal-cost multipath routing

On Mon, Nov 28, 2016, at 21:32, David Miller wrote: > From: David Lebrun > Date: Mon, 28 Nov 2016 21:16:19 +0100 > > > The advantage of my solution over RFC2992 is lowest possible disruption > > and equal rebalancing of affected flows. The disadvantage is the lookup >

Re: net: GPF in rt6_get_cookie

Hi On 30.11.2016 11:39, Andrey Konovalov wrote: > On Sat, Nov 26, 2016 at 5:23 PM, 'Dmitry Vyukov' via syzkaller > wrote: >> Hello, >> >> I got several GPFs in rt6_get_cookie while running syzkaller: >> >> general protection fault: [#1] SMP DEBUG_PAGEALLOC KASAN

Re: [RFC PATCH net-next v2] ipv6: implement consistent hashing for equal-cost multipath routing

Hi, On Tue, Nov 29, 2016, at 18:15, David Lebrun wrote: > When multiple nexthops are available for a given route, the routing > engine > chooses a nexthop by computing the flow hash through get_hash_from_flowi6 > and by taking that value modulo the number of nexthops. The resulting > value >

Re: [PATCH net-next 5/5] udp: add recvmmsg implementation

Hello, On Wed, Nov 30, 2016, at 01:22, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Fri, 25 Nov 2016 18:09:00 +0100 > > > During review we discussed on how to handle major errors in the kernel: > > > > The old code and t

Re: [PATCH v3 net-next 0/4] bpf: BPF for lightweight tunnel encapsulation

Hi Thomas, On 29.11.2016 14:21, Thomas Graf wrote: > This series implements BPF program invocation from dst entries via the > lightweight tunnels infrastructure. The BPF program can be attached to > lwtunnel_input(), lwtunnel_output() or lwtunnel_xmit() and see an L3 > skb as context. Programs

Re: [PATCH net-next 5/5] udp: add recvmmsg implementation

On 25.11.2016 16:39, Paolo Abeni wrote: > skbs are extracted from the receive queue in burts, and a single > sk_rmem_alloc/forward allocated memory update is performed for > each burst. > MSG_PEEK and MSG_ERRQUEUE are not supported to keep the implementation > as simple as possible. > >

Re: net/arp: ARP cache aging failed.

On 25.11.2016 09:18, Julian Anastasov wrote: > > Hello, > > On Thu, 24 Nov 2016, Hannes Frederic Sowa wrote: > >> I think some people are thinking about it already (me also ;) ). >> >> But it is not easy to come up with a solution. First of all, we need t

Re: [patch net-next v2 09/11] ipv4: fib: Add an API to request a FIB dump

On 24.11.2016 09:47, Ido Schimmel wrote: > On Thu, Nov 24, 2016 at 12:04:57AM +0100, Hannes Frederic Sowa wrote: >> On 23.11.2016 20:53, Ido Schimmel wrote: >>> On Wed, Nov 23, 2016 at 06:47:03PM +0100, Hannes Frederic Sowa wrote: >>>> Hmm, I think you need to r

Re: net/arp: ARP cache aging failed.

On 24.11.2016 10:06, YueHaibing wrote: > On 2016/11/24 15:51, Julian Anastasov wrote: >> >> Hello, >> >> On Wed, 23 Nov 2016, Eric Dumazet wrote: >> >>> On Wed, 2016-11-23 at 15:37 +0100, Hannes Frederic Sowa wrote: >>> >>>>

<    1   2   3   4   5   6   7   8   9   >