Re: [PATCH] once: switch to new jump label API

ced out-of-line at the jump target, rather than at the inline > fallthrough case. > > Signed-off-by: Eric Biggers Acked-by: Hannes Frederic Sowa

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

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 locki

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 wrote: >> On Fri, Dec 23, 2016 at 3:59 AM, Daniel Borkmann >> wrote: >>> On 12/23/2016 11:59 AM, Hannes Frederic Sowa wrote: >>>> >>>> On Fri,

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 > > > wrote: > > > > On

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 t

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 >> wrote: >>> following up on what appears to be a random subject: ;) >>> >>> IIR

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 > wrote: > > On Thu, 2016-12-22 at 08:07 -0800, Andy Lutomirski wrote: > > > > > > You mean: > > > > > > commit 7bd509e311f40

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 > wrote: > > On Thu, 2016-12-22 at 16:41 +0100, Jason A. Donenfeld wrote: > > > Hi Hannes, > > > > > > On Thu, Dec 22, 2016 at 4:3

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 > wrote: > > IPv6 you cannot touch anymore. The hashing algorithm is part of uAPI. > > You don't want to give people new IPv6 a

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 > > linux/cryptohash.h. That'll th

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 > wrote: >> following up on what appears to be a random subject: ;) >> >> IIRC, ext4 code by default still uses half_md4 for hashing of filenames >> in the htree.

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 that

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(&ret)) >> - return ret; >> - >> - ha

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 us

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 > wrote: >>> How's that sound? >> >> I am still very much concerned about the API. > > Thanks for pushing

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 > wrote: >> And I was exactly questioning this. >> >> static unsigned int inet6_hash_frag(__be32 id, const struct in6_addr *saddr, >>

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 > wrote: >> ARM64 and x86-64 have memory operations that are not vector operations >> that operate on 128 bit memory. > > Fair enough. imull I guess. > >> How

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 >> wrote: >>> ARM64 and x86-64 have memory operations that are not vector operations >>&g

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 > m

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] x86/kbuild: enable modversions for symbols exported from asm

On 15.12.2016 15:15, Nicholas Piggin wrote: > On Thu, 15 Dec 2016 14:15:31 +0100 > Hannes Frederic Sowa wrote: > >> On 15.12.2016 13:03, Nicholas Piggin wrote: >>> On Thu, 15 Dec 2016 12:19:02 +0100 >>> Hannes Frederic Sowa wrote: >>> >&

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] x86/kbuild: enable modversions for symbols exported from asm

On 15.12.2016 13:03, Nicholas Piggin wrote: > On Thu, 15 Dec 2016 12:19:02 +0100 > Hannes Frederic Sowa wrote: > >> On 15.12.2016 03:06, Nicholas Piggin wrote: >>> On Wed, 14 Dec 2016 15:04:36 +0100 >>> Hannes Frederic Sowa wrote: >>> >>

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 >>> wrote: >>>

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 15.12.2016 03:06, Nicholas Piggin wrote: > On Wed, 14 Dec 2016 15:04:36 +0100 > Hannes Frederic Sowa wrote: > >> On 09.12.2016 17:03, Greg Kroah-Hartman wrote: >>> On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote: >>>> On Fri, 9 Dec 2016

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 > wrote: >> I fear that the alignment requirement will be a source of bugs on 32 bit >> machines, where you cannot even simply take a well aligned stru

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 k1 = get_unaligned_le64(k

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 > 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' because of the

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 accesses to be performed f

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 > wrote: >> Can you show or cite benchmarks in comparison with jhash? Last time I >> looked, especially for short inputs, siphash didn't beat jhash (also on &g

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 09.12.2016 17:03, Greg Kroah-Hartman wrote: > On Sat, Dec 10, 2016 at 01:56:53AM +1000, Nicholas Piggin wrote: >> On Fri, 9 Dec 2016 15:36:04 +0100 >> Stanislav Kozina wrote: >> >>> The question is how to provide a similar guarantee if a different way? >> As a tool to aid distro revie

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 MD5 buffers, we simply creat

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 comparison

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 heade

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On 01.12.2016 17:12, Michal Marek wrote: > On 2016-12-01 04:39, Nicholas Piggin wrote: >> On Thu, 01 Dec 2016 02:35:54 + >> Ben Hutchings wrote: >>> As I understand it, genksyms incorporates the definitions of a >>> function's parameter and return types - not just their names - and all >>> the

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 >> Dumping ftrace buffer: >>

Re: [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check

On 23.11.2016 05:45, Rohit Thapliyal wrote: > |>On 22.11.2016 07:27, Manjeet Pawar wrote: > >> From: Rohit Thapliyal > > >> > >> np checked for NULL and then dereferenced. It should be modified > >> for NULL case. > >> > >> Signed-off-by: Rohit Thapliyal

Re: [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check

On 22.11.2016 07:27, Manjeet Pawar wrote: > From: Rohit Thapliyal > > np checked for NULL and then dereferenced. It should be modified > for NULL case. > > Signed-off-by: Rohit Thapliyal > Signed-off-by: Manjeet Pawar > --- > net/ipv6/ip6_output.c | 9 + > 1 file changed, 5 insertions

Re: net: BUG still has locks held in unix_stream_splice_read

On 17.11.2016 22:44, Cong Wang wrote: > On Sun, Oct 9, 2016 at 8:14 PM, Al Viro wrote: >> E.g what will happen if some code does a read on AF_UNIX socket with >> some local mutex held? AFAICS, there are exactly two callers of >> freezable_schedule_timeout() - this one and one in XFS; the latter i

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

Hey Jason, On 15.11.2016 01:45, Jason A. Donenfeld wrote: > I'll have a better look at this. Perhaps this should be modeled on > what we currently do for userspace, which might amount to something > more or less like: Cool, thanks! > diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c > i

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On Mon, Nov 14, 2016, at 18:48, David Ahern wrote: > On 11/14/16 10:33 AM, Hannes Frederic Sowa wrote: > >>>>> I just also quickly read up on the history (sorry was travelling last > >>>>> week) and wonder if you ever saw a user space facing bug or if this i

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 14.11.2016 18:17, David Ahern wrote: > On 11/14/16 10:04 AM, Hannes Frederic Sowa wrote: >> On 14.11.2016 17:55, David Ahern wrote: >>> On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: >>>> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >>>>

Re: Long delays creating a netns after deleting one (possibly RCU related)

Hi Cong, On Sat, Nov 12, 2016, at 01:55, Cong Wang wrote: > On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney > wrote: > > > > Ah! This net_mutex is different than RTNL. Should synchronize_net() be > > modified to check for net_mutex being held in addition to the current > > checks for RTNL bei

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On 14.11.2016 17:55, David Ahern wrote: > On 11/14/16 9:44 AM, Hannes Frederic Sowa wrote: >> On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: >>> This puts the IPv6 routing functions in parity with the IPv4 routing >>> functions. Namely, we now check in v6 t

Re: [PATCH v3] ip6_output: ensure flow saddr actually belongs to device

On Mon, Nov 14, 2016, at 00:28, Jason A. Donenfeld wrote: > This puts the IPv6 routing functions in parity with the IPv4 routing > functions. Namely, we now check in v6 that if a flowi6 requests an > saddr, the returned dst actually corresponds to a net device that has > that saddr. This mirrors th

Re: Source address fib invalidation on IPv6

On Sun, Nov 13, 2016, at 01:43, Jason A. Donenfeld wrote: > On Sat, Nov 12, 2016 at 8:08 PM, Jason A. Donenfeld > wrote: > >> Gotcha. I don't see any checks that the saddr is valid similar to what > >> IPv4 does. > >> > >> I think the right place to add a check is in ip6_dst_lookup_tail(): > >>

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On 01.11.2016 17:39, David Miller wrote: > From: Hannes Frederic Sowa > Date: Tue, 1 Nov 2016 17:27:56 +0100 > >> On 01.11.2016 16:35, David Miller wrote: >>> I have a really hard time accepting a "fix" that depends upon behavior >>> that the Linux ipv6

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

Hello, On 01.11.2016 17:39, Tom Herbert wrote: > On Tue, Nov 1, 2016 at 9:25 AM, Hannes Frederic Sowa > wrote: >> On 31.10.2016 20:25, Tom Herbert wrote: >>> The normal hash for TCP or UDP using ECMP is over >> dstIP, srcPort, dstPort>. For an ICMP packet ECMP woul

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On 01.11.2016 16:35, David Miller wrote: > I have a really hard time accepting a "fix" that depends upon behavior > that the Linux ipv6 stack doesn't even have. We actually support this feature: commit df3687ffc6653e4d32168338b4dee20c164ed7c9 Author: Florent Fourcot Date: Fri Jan 17 17:15:03 2

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

On 31.10.2016 20:25, Tom Herbert wrote: > The normal hash for TCP or UDP using ECMP is over dstIP, srcPort, dstPort>. For an ICMP packet ECMP would most likely be > done over . There really is no way to ensure > that an ICMP packet will follow the same path as TCP or any other > protocol. Fortunat

Re: [PATCH net-next 0/5] Route ICMPv6 errors with the flow when ECMP in use

Hi, On 27.10.2016 17:23, David Miller wrote: > From: Jakub Sitnicki > Date: Mon, 24 Oct 2016 11:28:47 +0200 > >> However, for it to work IPv6 flow labels have to be same in both >> directions (i.e. reflected) or need to be chosen in a manner that >> ensures that the flow going in the opposite di

Re: [PATCH net-next 5/5] ipv6: Compute multipath hash for forwarded ICMP errors from offending packet

gt; > Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa

Re: [PATCH net-next 4/5] ipv6: Compute multipath hash for sent ICMP errors from offending packet

on receive side, when forwarding ICMP errors. > > Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa

Re: [PATCH net-next 3/5] ipv6: Use multipath hash from flow info if available

at triggered the error. > > Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa

Re: [PATCH net-next 2/5] net: Extend struct flowi6 with multipath hash

we would > like to make a routing decision based on the flow identifying the > offending IPv6 datagram that triggered the error, rather than the flow > of the ICMP error itself. > > Signed-off-by: Jakub Sitnicki Acked-by: Hannes Frederic Sowa

Re: kernel BUG at net/unix/garbage.c:149!"

On Tue, Sep 27, 2016, at 16:16, Nikolay Borisov wrote: > Dave, > > What's the status of https://patchwork.ozlabs.org/patch/664062/ , is > this going to be picked up ? Not sure if we actually fix a bug with this. Miklos could you maybe enhance the changelog then? Thanks, Hannes

Re: [PATCH RFC 2/2] rlimits: report resource limits violations

On 07.09.2016 23:20, Alexei Starovoitov wrote: > On Wed, Sep 07, 2016 at 01:27:35PM +0300, Yauheni Kaliuta wrote: >> The patch instrument different places of resource limits checks with >> reporting using the infrastructure from the previous patch. >> >> Signed-off-by: Yauheni Kaliuta >> --- >> a

Re: [PATCH] softirq: let ksoftirqd do its job

On 01.09.2016 14:57, Eric Dumazet wrote: > On Thu, 2016-09-01 at 14:38 +0200, Jesper Dangaard Brouer wrote: > >> Correction, on the server-under-test, I'm actually running RHEL7.2 >> >> >>> How do I verify/check if I have enabled a cpu-cgroup? >> >> Hannes says I can look in "/proc/self/cgroup" >>

Re: [PATCH] softirq: let ksoftirqd do its job

On 31.08.2016 22:42, Eric Dumazet wrote: > On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote: > >> I can confirm the improvement of approx 900Kpps (no wonder people have >> been complaining about DoS against UDP/DNS servers). >> >> BUT during my extensive testing, of this patch, I al

Re: [PATCH] softirq: let ksoftirqd do its job

uation. (Note that more packets are now > dropped by the NIC itself, since the BH handlers get less cpu cycles to > drain RX ring buffer) > > Since the load runs in well identified threads context, an admin can > more easily tune process scheduling parameters if needed. > &

Re: [PATCH] softirq: let ksoftirqd do its job

On 01.09.2016 13:02, Jesper Dangaard Brouer wrote: > On Wed, 31 Aug 2016 23:51:16 +0200 > Jesper Dangaard Brouer wrote: > >> On Wed, 31 Aug 2016 13:42:30 -0700 >> Eric Dumazet wrote: >> >>> On Wed, 2016-08-31 at 21:40 +0200, Jesper Dangaard Brouer wrote: >>> I can confirm the improvement

Re: kernel BUG at net/unix/garbage.c:149!"

On 30.08.2016 11:18, Miklos Szeredi wrote: > On Tue, Aug 30, 2016 at 12:37 AM, Miklos Szeredi wrote: >> On Sat, Aug 27, 2016 at 11:55 AM, Miklos Szeredi wrote: > >> crash> list -H gc_inflight_list unix_sock.link -s unix_sock.inflight | >> grep counter | cut -d= -f2 | awk '{s+=$1} END {print s}'

Re: kernel BUG at net/unix/garbage.c:149!"

On 25.08.2016 01:30, Nikolay Borisov wrote: > On Thu, Aug 25, 2016 at 12:40 AM, Hannes Frederic Sowa > wrote: >> On 24.08.2016 16:24, Nikolay Borisov wrote: > [SNIP] >> >> One commit which could have to do with that is >> >> commit fc64869c48494a401b1

Re: kernel BUG at net/unix/garbage.c:149!"

On 24.08.2016 16:24, Nikolay Borisov wrote: > Hello, > > I hit the following BUG: > > [1851513.239831] [ cut here ] > [1851513.240079] kernel BUG at net/unix/garbage.c:149! > [1851513.240313] invalid opcode: [#1] SMP > [1851513.248320] CPU: 37 PID: 11683 Comm: ngin

Re: CVE-2014-9900 fix is not upstream

On 24.08.2016 16:03, Lennart Sorensen wrote: > On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote: >> Sadly, sizeof is what we use when copying that sucker to userland. So these >> padding bits in the end would've leaked, true enough, and the case is >> somewhat >> weaker. And any normal ar

Re: [PATCH v2] net: neigh: disallow transition to NUD_STALE if lladdr is unchanged in neigh_update()

> > Signed-off-by: Chunhui He > --- > v2: > - change title from "net: neigh: disallow state transition DELAY->STALE in >neigh_update()" > - remove "NUD_CONNECTED" condition instead of "NUD_CONNECTED | NUD_DELAY" > - remove "NEIGH_UPDATE_F_WEAK_OVERRIDE" condition Reviewed-by: Hannes Frederic Sowa Thanks!

Re: [PATCH] net: neigh: disallow state transition DELAY->STALE in neigh_update()

igh, const u8 > *lladdr, u8 new, > goto out; > } else { > if (lladdr == neigh->ha && new == NUD_STALE && > - ((flags & NEIGH_UPDATE_F_WEAK_OVERRIDE) || > - (old & NUD_CONNECTED)) > - ) > - new = old; > + !(flags & NEIGH_UPDATE_F_ADMIN)) > + goto out; > } > } > > Any thoughts? This change makes perfectly sense to me. Reviewed-by: Hannes Frederic Sowa Thanks, Hannes

Re: [RFC PATCH 00/30] Kernel NET policy

Hello, On Mon, Jul 18, 2016, at 21:43, Andi Kleen wrote: > > I wonder if this can be attacked from a different angle. What would be > > missing to add support for this in user space? The first possibility > > that came to my mind is to just multiplex those hints in the kernel. > > "just" is the h

Re: [RFC PATCH 00/30] Kernel NET policy

On 18.07.2016 17:45, Andi Kleen wrote: >> It seems strange to me to add such policies to the kernel. >> Addmittingly, documentation of some settings is non-existent and one needs >> various different tools to set this (sysctl, procfs, sysfs, ethtool, etc). > > The problem is that different applica

Re: [PATCHv3 wl-drv-next 1/2] add basic register-field manipulation macros

On 01.07.2016 23:26, Jakub Kicinski wrote: > C bitfields are problematic and best avoided. Developers > interacting with hardware registers find themselves searching > for easy-to-use alternatives. Common approach is to define > structures or sets of macros containing mask and shift pair. > Opera

Re: [PATCH v1 1/1] ipv4: Prevent malformed UFO fragments in ip_append_page

unning NFS under UDP. > > Signed-off-by: Steven Caron Awesome! Acked-by: Hannes Frederic Sowa

Re: ipv4: Constrain UFO fragment sizes to multiples of 8 bytes

On 09.06.2016 06:59, Cong Wang wrote: > (Cc'ing netdev...) > > On Mon, Jun 6, 2016 at 1:24 PM, Steven Caron wrote: >> Back in 2011, Bill Sommerfeld submitted an update to prevent ip_append_data >> to create malformed packets: >> Commit: d9be4f7a6f5a8da3133b832eca41c3591420b1ca >> >> Now we're f

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On 07.06.2016 17:23, Paul E. McKenney wrote: > On Tue, Jun 07, 2016 at 04:59:02PM +0200, Hannes Frederic Sowa wrote: >> On 07.06.2016 15:06, Paul E. McKenney wrote: >>> On Tue, Jun 07, 2016 at 02:41:44PM +0200, Hannes Frederic Sowa wrote: >>>> On 07.06.20

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On 07.06.2016 15:06, Paul E. McKenney wrote: > On Tue, Jun 07, 2016 at 02:41:44PM +0200, Hannes Frederic Sowa wrote: >> On 07.06.2016 09:15, Peter Zijlstra wrote: >>>> >>>> diff --git a/Documentation/memory-barriers.txt >>>> b/Documentatio

Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep

On 07.06.2016 09:15, Peter Zijlstra wrote: >> >> diff --git a/Documentation/memory-barriers.txt >> b/Documentation/memory-barriers.txt >> index 147ae8ec836f..a4d0a99de04d 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -806,6 +806,41 @@ out-guess

Re: [PATCH 3.12 69/76] net: fix infoleak in rtnetlink

On 20.05.2016 18:45, David Miller wrote: > From: Vegard Nossum > Date: Fri, 20 May 2016 14:04:54 +0200 > >> Just out of curiosity, was this observed in practice? I could be >> wrong, but I was under the impression that using designated >> initializers would zero the rest of the struct, including

Re: [PATCH] net: af_unix: protect ->sk_shutdown change with lock_sock()

On 18.05.2016 12:14, Andrey Ryabinin wrote: > ->sk_shutdown bits share one bitfield with some other bits in sock struct, > such as ->sk_no_check_[r,t]x, ->sk_userlocks ... > sock_setsockopt() may write to these bits, while holding the socket lock. > In case of AF_UNIX sockets, we change ->sk_shutdo

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 11.05.2016 16:45, Eric Dumazet wrote: > On Wed, May 11, 2016 at 7:38 AM, Paolo Abeni wrote: > >> Uh, we have likely the same issue in the net_rx_action() function, which >> also execute with bh disabled and check for jiffies changes even on >> single core hosts ?!? > > That is why we have a l

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 11.05.2016 15:39, Hannes Frederic Sowa wrote: > I am fine with that. It is us to show clear benefits or use cases for > that. If we fail with that, no problem at all that the patches get > rejected, we don't want to add bloat to the kernel, for sure! At this > point I still th

Re: [RFC PATCH 0/2] net: threadable napi poll loop

Hi all, On 11.05.2016 15:08, Eric Dumazet wrote: > On Wed, 2016-05-11 at 11:48 +0200, Paolo Abeni wrote: >> Hi Eric, >> On Tue, 2016-05-10 at 15:51 -0700, Eric Dumazet wrote: >>> On Wed, 2016-05-11 at 00:32 +0200, Hannes Frederic Sowa wrote: >>> >>>> N

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 11.05.2016 08:55, Peter Zijlstra wrote: > On Tue, May 10, 2016 at 03:51:37PM -0700, Eric Dumazet wrote: >> diff --git a/kernel/softirq.c b/kernel/softirq.c >> index 17caf4b63342..22463217e3cf 100644 >> --- a/kernel/softirq.c >> +++ b/kernel/softirq.c >> @@ -56,6 +56,7 @@ EXPORT_SYMBOL(irq_stat);

Re: [RFC PATCH 0/2] net: threadable napi poll loop

On 10.05.2016 23:09, Eric Dumazet wrote: > On Tue, May 10, 2016 at 1:46 PM, Hannes Frederic Sowa > wrote: > >> I agree here, but I don't think this patch particularly is a lot of >> bloat and something very interesting people can play with and extend upon. >> >

Re: [RFC PATCH 0/2] net: threadable napi poll loop

Hello, On 10.05.2016 16:29, Eric Dumazet wrote: > On Tue, 2016-05-10 at 16:11 +0200, Paolo Abeni wrote: >> Currently, the softirq loop can be scheduled both inside the ksofirqd kernel >> thread and inside any running process. This makes nearly impossible for the >> process scheduler to balance in

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On 03.05.2016 17:51, Guillaume Nault wrote: > On Tue, May 03, 2016 at 01:23:34PM +0200, Hannes Frederic Sowa wrote: >> On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: >>> On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault >>> wrote: >>>> On Sun,

Re: [Question] Should `CAP_NET_ADMIN` be needed when opening `/dev/ppp`?

On Tue, May 3, 2016, at 12:35, Richard Weinberger wrote: > On Tue, May 3, 2016 at 12:12 PM, Guillaume Nault > wrote: > > On Sun, May 01, 2016 at 09:38:57PM +0800, Wang Shanker wrote: > >> static int ppp_open(struct inode *inode, struct file *file) > >> { > >> /* > >>* This could (sho

Re: [PATCH 3.2 085/115] veth: don’t modify ip_summed; doing so treats packets with bad checksums as good.

Hi Ben, On Wed, Apr 27, 2016, at 20:07, Ben Hutchings wrote: > On Wed, 2016-04-27 at 08:59 -0700, Ben Greear wrote: > > On 04/26/2016 04:02 PM, Ben Hutchings wrote: > > > > > > 3.2.80-rc1 review patch.  If anyone has any objections, please let me > > > know. > > I would be careful about this.  I

Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408

On Sun, Apr 24, 2016, at 23:25, Eric Dumazet wrote: > #ifdef CONFIG_LOCKDEP > - WARN_ON(!lockdep_sock_is_held(sk)); > + WARN_ON_ONCE(!lockdep_sock_is_held(sk) && !debug_locks); > #endif Eric, could you resend this patch without the negation and also add my acked-by (I came finally ar

Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408

On 24.04.2016 20:38, David Miller wrote: > From: Hannes Frederic Sowa > Date: Thu, 21 Apr 2016 15:49:37 +0200 > >> On 21.04.2016 15:31, Eric Dumazet wrote: >>> On Thu, 2016-04-21 at 05:05 -0400, valdis.kletni...@vt.edu wrote: >>>> On Thu, 21 Apr 2016 09:42

Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408

On 21.04.2016 15:31, Eric Dumazet wrote: > On Thu, 2016-04-21 at 05:05 -0400, valdis.kletni...@vt.edu wrote: >> On Thu, 21 Apr 2016 09:42:12 +0200, Hannes Frederic Sowa said: >>> Hi, >>> >>> On Thu, Apr 21, 2016, at 02:30, Valdis Kletnieks wrote: >&

Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408

On 21.04.2016 15:31, Eric Dumazet wrote: > On Thu, 2016-04-21 at 05:05 -0400, valdis.kletni...@vt.edu wrote: >> On Thu, 21 Apr 2016 09:42:12 +0200, Hannes Frederic Sowa said: >>> Hi, >>> >>> On Thu, Apr 21, 2016, at 02:30, Valdis Kletnieks wrote: >&

Re: IPv6 patch mysteriously breaks IPv4 VPN

On 21.04.2016 04:24, Valdis Kletnieks wrote: > I'll say up front - no, I do *not* have a clue why this commit causes this > problem - it makes exactly zero fsking sense. > > Scenario: $WORK is blessed with a Juniper VPN system. I've been > seeing for a while now (since Dec-ish) an issue where at

Re: linux-next: zillions of lockdep whinges in include/net/sock.h:1408

Hi, On Thu, Apr 21, 2016, at 02:30, Valdis Kletnieks wrote: > linux-next 20160420 is whining at an incredible rate - in 20 minutes of > uptime, I piled up some 41,000 hits from all over the place (cleaned up > to skip the CPU and PID so the list isn't quite so long): Thanks for the report. Can yo

Re: [PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

On 08.04.2016 01:12, Hannes Frederic Sowa wrote: I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: David Miller Signed-off-by: Hannes Frederic Sowa

[PATCH net] lockdep: provide always true lockdep_is_held stub if lockdep disabled

I need this to provide a generic lockdep_sock_is_held function which can be easily used in the kernel without using ifdef PROVEN macros. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Eric Dumazet Cc: David Miller Signed-off-by: Hannes Frederic Sowa --- Hello Peter and Ingo, if it is possible coud

Re: [PATCH] ipv6: icmp: Add protection from concurrent users in the function icmpv6_echo_reply

On 05.04.2016 23:27, Bastien Philbert wrote: This adds protection from concurrenct users in the function icmpv6_echo_reply around the call to the function __in6_dev_get by locking/unlocking around this call with calls to the functions rtnl_lock and rtnl_unlock to protect against concurrent users

  1   2   3   4   5   >