[PATCH net] ipv6: automatically enable stable privacy mode if stable_secret set

oconf") Reported-by: Bjørn Mork <bj...@mork.no> Cc: Bjørn Mork <bj...@mork.no> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/ipv6/addrconf.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index a5

Re: [PATCH net] pptp: validate sockaddr_len before binding

On 14.12.2015 23:58, Cong Wang wrote: > On Mon, Dec 14, 2015 at 2:45 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: >> diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c >> index fc69e41d09506e..f9ffdf070ad807 100644 >> --- a/drivers/net/p

[PATCH net] net: add validation for the socket syscall protocol argument

/0x80 kernel: [] ? syscall_trace_enter_phase2+0x108/0x200 kernel: [] SyS_connect+0xe/0x10 kernel: [] tracesys_phase2+0x84/0x89 I found no particular commit which introduced this problem. CVE: CVE-2015-8543 Reported-by: 郭永刚 <guoyongg...@360.cn> Signed-off-by: Hannes Frederic Sow

[PATCH net] netlink: fix boolean evaluation on bound

portid may be 0, thus bound will set the flag to false for in-kernel created netlink sockets. Fixes: da314c9923fed55 ("netlink: Replace rhash_portid with bound") Cc: Herbert Xu <herb...@gondor.apana.org.au> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCHv2 net-next] ipv6: allow routes to be configured with expire values

Hi, On 14.12.2015 12:48, Xin Long wrote: >> >> This is the wrong way to do this. >> >> Currently we only ever dump rta_cacheinfo values to the user. >> >> If we use it to set things, we have to completely consider every >> member of that structure as potentially having meaning either >> intended

Re: [PATCH net] netlink: fix boolean evaluation on bound

On 14.12.2015 18:06, Herbert Xu wrote: > On Mon, Dec 14, 2015 at 05:55:25PM +0100, Hannes Frederic Sowa wrote: >> portid may be 0, thus bound will set the flag to false for in-kernel >> created netlink sockets. >> >> Fixes: da314c9923fed55 ("netlink: Replace

Re: [RFC] ipv6: use a random ifid for headerless devices

Hello, On 08.12.2015 19:57, Bjørn Mork wrote: > Hannes Frederic Sowa <han...@stressinduktion.org> writes: >> On 05.12.2015 20:02, Bjørn Mork wrote: >>> Hannes Frederic Sowa <han...@stressinduktion.org> writes: >>>> On Thu, Dec 3, 2015, at 20:29, Bjørn

[PATCH net] net: fix warnings in 'make htmldocs' by moving macro definition out of field declaration

Docbook does not like the definition of macros inside a field declaration and adds a warning. Move the definition out. Fixes: 79462ad02e86180 ("net: add validation for the socket syscall protocol argument") Reported-by: kbuild test robot <l...@intel.com> Signed-off-by: Hannes Fr

[PATCH net v2] net: add validation for the socket syscall protocol argument

; Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- v2) * remove the generic negative check in __sock_create and audit more callers: ax25, decnet, irda turncated the protocol value before writing it into the socket. Check for that and return -EINVAL (thanks, Cong!).

Re: [PATCH net] netlink: fix boolean evaluation on bound

On 14.12.2015 18:50, Eric Dumazet wrote: > On Mon, 2015-12-14 at 18:27 +0100, Hannes Frederic Sowa wrote: > >> Otherwise I would recommend adding a "!!" to express that we actually >> want bound set based on the portid value? > > Note that compiler already

Re: Information leak in pptp_bind

On 14.12.2015 11:38, Dmitry Vyukov wrote: > The following program leak various uninit garbage including kernel > addresses and whatever is on kernel stack, in particular defeating > ASLR. The issue is in pptp_bind which does not verify sockaddr_len. Thanks for the report! I send out a patch

[PATCH net] pptp: validate sockaddr_len before binding

Reported-by: Dmitry Vyukov <dvyu...@gmail.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/ppp/pptp.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/ppp/pptp.c b/drivers/net/ppp/pptp.c index fc69e41d09506e..f9ffdf070

Re: [RFC] ipv6: use a random ifid for headerless devices

On 05.12.2015 20:02, Bjørn Mork wrote: > Hannes Frederic Sowa <han...@stressinduktion.org> writes: >> On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote: >> >>> After looking more at addrconf, I started wondering if we couldn't abuse >>> ipv6_generate_stable_ad

Re: [RFC] ipv6: use a random ifid for headerless devices

Hello, On Thu, Dec 3, 2015, at 20:29, Bjørn Mork wrote: > Hannes Frederic Sowa <han...@stressinduktion.org> writes: > > > I see no problem with the patch as it eases operating those devices. I > > would also suggest storing the ifid in the inet6_dev so it does only

Re: [PATCH] ipv6: keep existing flags when setting IFA_F_OPTIMISTIC

ik Kline <e...@google.com> > Cc: Fernando Gont <fg...@si6networks.com> > Cc: Lorenzo Colitti <lore...@google.com> > Cc: YOSHIFUJI Hideaki/吉藤英明 <hideaki.yoshif...@miraclelinux.com> > Cc: Hannes Frederic Sowa <han...@stressinduktion.org> > Fixes: 64236f3f3d7

Re: bpf: undefined shift in __bpf_prog_run

Hello, On Fri, Dec 4, 2015, at 20:48, Dmitry Vyukov wrote: > On Fri, Dec 4, 2015 at 8:26 PM, David Miller wrote: > > From: Alexei Starovoitov > > Date: Fri, 4 Dec 2015 11:10:15 -0800 > > > >> just don't generate random bpf programs with such

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Tom, On Fri, Dec 4, 2015, at 19:28, Tom Herbert wrote: > > I do know that, but fact is, the current drivers do it. I am concerned > > about the amount of entropy in one single 16 bit field used to > > distinguish flows. Flow labels fine and good, but if current hardware > > does not support

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015, at 20:59, Hannes Frederic Sowa wrote: > And then filling out those fields using the offsetof and sizeof of the > headers, but this seemed to be very difficult a) because they use > bitmasks (which of course could be converted) or in case of IPv6 a > schem

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Dave, On Fri, Dec 4, 2015, at 21:06, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Fri, 04 Dec 2015 20:59:05 +0100 > > > Yes, I agree, I am totally with you here. If generic offloading can be > > realized by NICs I am totall

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Fri, Dec 4, 2015, at 21:43, Tom Herbert wrote: > On Fri, Dec 4, 2015 at 12:26 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > Hi Dave, > > > > On Fri, Dec 4, 2015, at 21:06, David Miller wrote: > >> From: Hannes Frederic Sowa <han.

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Thu, Dec 3, 2015, at 17:35, Andreas Schultz wrote: > On 12/03/2015 04:59 PM, Hannes Frederic Sowa wrote: > > Hi Tom, > > > > On Wed, Dec 2, 2015, at 20:15, Tom Herbert wrote: > >> On Wed, Dec 2, 2015 at 8:35 AM, Hannes Frederic Sowa > >> <han...@stres

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

Hi Tom, On Wed, Dec 2, 2015, at 20:15, Tom Herbert wrote: > On Wed, Dec 2, 2015 at 8:35 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On Wed, Dec 2, 2015, at 04:50, Tom Herbert wrote: > >> That completely misses the whole point of the rest of

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Wed, Dec 2, 2015, at 04:50, Tom Herbert wrote: > On Tue, Dec 1, 2015 at 7:49 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: > >> On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote:

Re: Asterisk deadlocks since Kernel 4.1

Hello, On Wed, Dec 2, 2015, at 18:15, Philipp Hahn wrote: > Hi, > > Am 02.12.2015 um 10:45 schrieb Stefan Priebe - Profihost AG: > > here are the results. > > > > It works with 4.1. > > It works with 4.2. > > It does not work with 4.1.13. > > the patches were first commitet in v4.3-rc3 and

Re: Asterisk deadlocks since Kernel 4.1

Hello Stefan, Stefan Priebe - Profihost AG writes: > here are the results. > > It works with 4.1. > It works with 4.2. > It does not work with 4.1.13. > > git bisect tells me it stopped working after those two commits were applied: > > commit

Re: [RFC] Stable interface index option

On Tue, Dec 1, 2015, at 22:44, Stephen Hemminger wrote: > On Tue, 01 Dec 2015 22:14:59 +0100 > Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > > I had several snmp installations with net-snmp and munin, cacti and so > > on and all had the interface name in if

Re: [RFC] Stable interface index option

On Tue, Dec 1, 2015, at 20:27, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Tue, 01 Dec 2015 17:02:23 +0100 > > > On Tue, Dec 1, 2015, at 16:50, Maximilian Wilhelm wrote: > >> > I'm not sure I understand how this would

Re: [RFC] Stable interface index option

gt; > >> From: Stephen Hemminger <step...@networkplumber.org> > >> Date: Tue, 1 Dec 2015 08:06:52 -0800 > >> > >> > On Tue, 01 Dec 2015 17:02:23 +0100 > >> > Hannes Frederic Sowa <han...@stressinduktion.org> wrote: > >> > > >> &g

Re: [RFC] Stable interface index option

Hello, On Tue, Dec 1, 2015, at 23:43, Maximilian Wilhelm wrote: > Anno domini 2015 Hannes Frederic Sowa scripsit: > > > On Tue, Dec 1, 2015, at 20:27, David Miller wrote: > > > From: Hannes Frederic Sowa <han...@stressinduktion.org> > > > D

Re: IPv4 tunnels: why IP-IP and SIT enforce DF bit, but GRE does not?

Hello, On Thu, Nov 26, 2015, at 19:28, Konstantin Shemyak wrote: > The kernel has taken the decision to always enforce DF bit on IPv4 > tunnels, which have fixed (not inherited) TTL (e.g. > net/ipv4/ipip.c:ipip_tunnel_ioctl()). Commment by Alexey Kuznetsov in > the head of ip_gre.c explains

Re: [RFCv3 bluetooth-next 3/4] ipv6: add ipv6_addr_prefix_copy

aller must guarantee 0 <= plen <= 128 */ > + int o = plen >> 3, > + b = plen & 0x7; > + > + memcpy(addr->s6_addr, pfx, o); > + if (b != 0) { > + addr->s6_addr[o] &= ~(0xff00 >> b); > + addr

Re: TUN interfaces loopback

Hello, On Wed, Nov 25, 2015, at 17:58, Radu Rendec wrote: > Disclaimer: I know this is a *development* list, but I feel the answer > lies deep down in the ipv4 routing code, so it's more likely that I > find help here. > > That being said, I have two TUN interfaces that are "cross-connected" >

Re: [PATCH net v2] openvswitch: properly refcount vport-vxlan module

On Tue, Dec 1, 2015, at 14:19, Paolo Abeni wrote: > Currently all the vport_ops list manipulation functions are protected by > the ovs_lock (even the lookup): the scenario described above should not > be possible. This makes all sense and it seems no use-after-free is possible at all (I didn't

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Dec 1, 2015, at 16:44, John W. Linville wrote: > On Mon, Nov 30, 2015 at 09:26:51PM -0800, Tom Herbert wrote: > > On Mon, Nov 30, 2015 at 5:28 PM, Jesse Gross wrote: > > > > Based on what we can do today, I see only two real choices: do some > > > refactoring to clean

Re: [RFC] Stable interface index option

On Tue, Dec 1, 2015, at 16:50, Maximilian Wilhelm wrote: > > I'm not sure I understand how this would work- are we going to > > pin down the ifindex for some subset of interfaces? > > I'm not sure what your idea is, but I guess we might mean the same > thing: > > What I have in mind is that the

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

On Tue, Dec 1, 2015, at 14:05, Eric Dumazet wrote: > On Tue, 2015-12-01 at 12:11 +0100, Hannes Frederic Sowa wrote: > > Hi Eric, > > > > On Mon, Nov 30, 2015, at 04:37, Eric Dumazet wrote: > > > - opt = xchg(>opt, NULL); >

Re: [PATCH net] ipv6: add complete rcu protection around np->opt

Hi Eric, On Mon, Nov 30, 2015, at 04:37, Eric Dumazet wrote: > - opt = xchg(>opt, NULL); > - if (opt) > - sock_kfree_s(sk, opt, opt->tot_len); > + opt = xchg((__force struct ipv6_txoptions > **)>opt, >

Re: [PATCH net v2] openvswitch: properly refcount vport-vxlan module

Hello Paolo, On Mon, Nov 30, 2015, at 12:31, Paolo Abeni wrote: > After 614732eaa12d, no refcount is maintained for the vport-vxlan module. > This allows the userspace to remove such module while vport-vxlan > devices still exist, which leads to later oops. > > v1 -> v2: > - move vport 'owner'

Re: [RFC] ipv6: use a random ifid for headerless devices

Hello, On Mon, Nov 30, 2015, at 12:55, Bjørn Mork wrote: > Generating a random ifid for devices with no L2 header > at all, allowing such devices to take part in IPv6 > autoconfiguration. The tuntap driver is one example of > a driver where such an ifid would be useful. > > Note that as there is

Re: net: Use after free in dst_release on boot

Hi, On Fri, Nov 27, 2015, at 21:48, Sasha Levin wrote: > [ 117.057618] BUG: KASAN: use-after-free in dst_release+0x9a/0xc0 at > addr 8806cf7c7560 > > [ 117.058566] Read of size 2 by task swapper/0/1 > Can you check if the following commit was already applied? net wasn't merged into

Re: [PATCH net] bridge: Only call /sbin/bridge-stp for the initial network namespace

On Mon, Nov 30, 2015, at 22:38, Eric W. Biederman wrote: > Signed-off-by: "Eric W. Biederman" > --- > net/bridge/br_stp_if.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c > index

Re: IPv4 tunnels: why IP-IP and SIT enforce DF bit, but GRE does not?

On Tue, Dec 1, 2015, at 14:20, Konstantin Shemyak wrote: > On 01.12.2015 12:15, Hannes Frederic Sowa wrote: > > Hello, > > > > On Thu, Nov 26, 2015, at 19:28, Konstantin Shemyak wrote: > >> The kernel has taken the decision to always enforce DF bit on IPv4

[PATCH net] af-unix: passcred support for sendpage

details. Fixes: 869e7c62486ec ("net: af_unix: implement stream sendpage support") Reported-by: Al Viro <v...@zeniv.linux.org.uk> Cc: Al Viro <v...@zeniv.linux.org.uk> Cc: Eric Dumazet <eduma...@google.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.or

Re: use-after-free in sock_wake_async

Hannes Frederic Sowa <han...@stressinduktion.org> writes: > I have seen filesystems already doing so in .destroy_inode, that's why I > am asking. The allocation happens the same way as we do with sock_alloc, > e.g. shmem. I actually thought that struct inode already provide

Re: [iproute PATCH RFC] libnetlink: introduce DECLARE_NLREQ

Phil Sutter writes: > This macro aims to simplify most netlink users' pattern to prepare a > request, which is to create an unnamed struct and initialize it: > > | struct { > | struct nlmsghdr n; > | struct whatever foo; > | char buf[arbitrary number]; > | } req; > | > |

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 14:32, Hannes Frederic Sowa wrote: > diff --git a/include/net/sock.h b/include/net/sock.h > index 7f89e4b..ae34da1 100644 > --- a/include/net/sock.h > +++ b/include/net/sock.h > @@ -1674,7 +1674,7 @@ static inline void sock_orphan(struct sock *sk) >

Re: [PATCH iproute2 -next v2 4/5] {f,m}_bpf: allow updates on program arrays

On Thu, Nov 26, 2015, at 15:38, Daniel Borkmann wrote: > +static int bpf_mnt_fs(const char *target) > +{ > + bool bind_done = false; > + > + while (mount("", target, "none", MS_PRIVATE | MS_REC, NULL)) { > + if (errno != EINVAL || bind_done) { > +

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 16:51, Eric Dumazet wrote: > On Thu, 2015-11-26 at 14:32 +0100, Hannes Frederic Sowa wrote: > > Hannes Frederic Sowa <han...@stressinduktion.org> writes: > > > > > > > I have seen filesystems already doing so in .destroy

Re: use-after-free in sock_wake_async

On Thu, Nov 26, 2015, at 18:09, Eric Dumazet wrote: > On Thu, 2015-11-26 at 18:03 +0100, Hannes Frederic Sowa wrote: > > > My rationale was like this: we already have rcu to free the wq, so we > > don't add any more callbacks as current code. sock_alloc is right now > > 1

Re: use-after-free in sock_wake_async

On Wed, Nov 25, 2015, at 23:09, Eric Dumazet wrote: > On Wed, 2015-11-25 at 20:57 +, Rainer Weikusat wrote: > > > I do agree that keeping the ->sk_data_ready outside of the lock will > > very likely have performance advantages. That's just something I > > wouldn't have undertaken because I'd

Re: use-after-free in sock_wake_async

On Wed, Nov 25, 2015, at 23:43, Eric Dumazet wrote: > On Wed, 2015-11-25 at 23:32 +0100, Hannes Frederic Sowa wrote: > > On Wed, Nov 25, 2015, at 23:09, Eric Dumazet wrote: > > > On Wed, 2015-11-25 at 20:57 +, Rainer Weikusat wrote: > > > > > > > I do

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hi, On Tue, Nov 24, 2015, at 23:21, Alexei Starovoitov wrote: > On Tue, Nov 24, 2015 at 10:58:08PM +0100, Hannes Frederic Sowa wrote: > > > > > > > > > > interesting idea, but then remote host will be influencing local cpu > > > > > selection

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hi David, On Tue, Nov 24, 2015, at 23:25, David Miller wrote: > From: Florian Westphal > Date: Tue, 24 Nov 2015 23:22:42 +0100 > > > Yes, I get that point, but I maintain that KCM is a strange workaround > > for bad userspace design. > > I fundamentally disagree with you. > >

Re: [PATCH net] ipv6: distinguish frag queues by device for multicast and link-local packets

ments. > > Applied and queued up for -stable, thanks! I reviewed it earlier and agree last time that this patch is necessary. Unfortunately forgot to ack before. :( Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> In IPv4 as in IPv6 global addresses we have to expect

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: > As you said this in only feedback and nobody is forcing anyone to do > anything. But encouraging HW vendors to provide generic mechanisms so > that your users can use whatever protocol they want is the exact > _opposite_ of punishing users, this

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015, at 18:52, Tom Herbert wrote: > On Tue, Nov 24, 2015 at 9:43 AM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: > >> As you said this in only feedback and nobody is forcing

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hello, On Tue, Nov 24, 2015, at 17:25, Florian Westphal wrote: > Its a well-written document, but I don't see how moving the burden of > locking a single logical tcp connection (to prevent threads from > reading a partial record) from userspace to kernel is an improvement. > > If you really have

Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload

On Tue, Nov 24, 2015, at 19:37, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Tue, 24 Nov 2015 18:43:35 +0100 > > > On Tue, Nov 24, 2015, at 18:32, Tom Herbert wrote: > >> As you said this in only feedback and nobody is forc

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hello, On Tue, Nov 24, 2015, at 19:59, Alexei Starovoitov wrote: > On Tue, Nov 24, 2015 at 07:23:30PM +0100, Hannes Frederic Sowa wrote: > > Hello, > > > > On Tue, Nov 24, 2015, at 17:25, Florian Westphal wrote: > > > Its a well-written document, but I d

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

On Tue, Nov 24, 2015, at 20:16, Hannes Frederic Sowa wrote: > ...also ipvs/netfilter could be used to only inspect the header and > reroute the packet to some better fitting CPU. Complete hierarchies > could be build with NUMA and addresses, packets could be rerouted into > nam

Re: [RFC PATCH 2/2] Crypto kernel tls socket

Hello, Stephan Mueller writes: > Am Dienstag, 24. November 2015, 18:34:55 schrieb Herbert Xu: > > Hi Herbert, > >>On Mon, Nov 23, 2015 at 09:43:02AM -0800, Dave Watson wrote: >>> Userspace crypto interface for TLS. Currently supports gcm(aes) 128bit >>> only, however the

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hello, David Miller writes: > From: Tom Herbert > Date: Mon, 23 Nov 2015 09:33:44 -0800 > >> The TCP PSH flag is not defined for message delineation (neither is >> urgent pointer). We can't change that (many people have tried to add >> message

Re: [RFC PATCH 0/2] Crypto kernel TLS socket

Hello, On Mon, Nov 23, 2015, at 18:42, Dave Watson wrote: > An approach for a kernel TLS socket. > > Only the symmetric encryption / decryption is done in-kernel, as well > as minimal framing handling. The handshake is kept in userspace, and > the negotiated cipher / keys / IVs are then set on

Re: [PATCH net-next] bpf: add show_fdinfo handler for maps

On Mon, Nov 23, 2015, at 20:09, John Fastabend wrote: > On 15-11-23 10:03 AM, Alexei Starovoitov wrote: > > On Mon, Nov 23, 2015 at 05:11:58PM +0100, Hannes Frederic Sowa wrote: > >> > >> Actually, that is the reason why I mentioned it, so *the admin* can see > &g

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hello Tom, On Mon, Nov 23, 2015, at 18:33, Tom Herbert wrote: > > For me this still looks a little bit like messages could be delimited by > > TCP PSH flag, where we might need to have some more fine grained control > > over and besides that just adding better fanout semantics to TCP, no? > > >

Re: [PATCH net-next 3/6] net: Add MSG_BATCH flag

Hello, On Fri, Nov 20, 2015, at 22:21, Tom Herbert wrote: > Add a new msg flag called MSG_BATCH. This flag is used in sendmsg to > indicate that more messages will follow (i.e. a batch of messages is > being sent). This is similar to MSG_MORE except that the following > messages are not merged

Re: Asterisk deadlocks since Kernel 4.1

On Mon, Nov 23, 2015, at 13:44, Stefan Priebe - Profihost AG wrote: > Am 19.11.2015 um 20:51 schrieb Stefan Priebe: > > > > Am 19.11.2015 um 14:19 schrieb Florian Weimer: > >> On 11/19/2015 01:46 PM, Stefan Priebe - Profihost AG wrote: > >> > >>> I can try Kernel 4.4-rc1 next week. Or something

Re: [PATCH net-next 0/6] kcm: Kernel Connection Multiplexor (KCM)

Hello, On Fri, Nov 20, 2015, at 22:21, Tom Herbert wrote: > Kernel Connection Multiplexor (KCM) is a facility that provides a > message based interface over TCP for generic application protocols. > The motivation for this is based on the observation that although > TCP is byte stream transport

Re: Deadlock between bind and splice

On Mon, Nov 23, 2015, at 09:32, Dmitry Vyukov wrote: > On Tue, Nov 10, 2015 at 3:59 AM, Al Viro wrote: > > On Tue, Nov 10, 2015 at 02:38:54AM +, Al Viro wrote: > >> On Fri, Nov 06, 2015 at 07:42:15AM -0800, Eric Dumazet wrote: > >> > >> > Thank you for this report. >

Re: [PATCH net-next] bpf: add show_fdinfo handler for maps

On Sun, Nov 22, 2015, at 00:18, Alexei Starovoitov wrote: > On Fri, Nov 20, 2015 at 11:30:13AM +0100, Hannes Frederic Sowa wrote: > > Hi Alexei, > > > > > If user space can be see both 'count' and 'max_entries', it can be very > > > tempting to start assuming 'f

Re: [PATCH net-next] bpf: add show_fdinfo handler for maps

Hi Alexei, On Fri, Nov 20, 2015, at 04:30, Alexei Starovoitov wrote: > On Thu, Nov 19, 2015 at 09:12:30PM +0100, Hannes Frederic Sowa wrote: > > On Thu, Nov 19, 2015, at 19:32, Alexei Starovoitov wrote: > > > On Thu, Nov 19, 2015 at 07:19:24PM +0100, Hannes Frederic Sowa wro

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 19:09, David Miller wrote: > From: Tom Herbert > Date: Thu, 19 Nov 2015 09:38:37 -0800 > > > 1) We need transparency. If a third party kills a TCP connection then > > the application should be informed of specifically that. This seems > > easy

Re: [PATCH net-next] bpf: add show_fdinfo handler for maps

inned object. > > Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Does it make sense to include bpf_htab->count in case of a hashmap? Thanks, Hannes -- To unsubscribe from this list: send the line "unsubs

Re: [PATCH net-next] bpf: add show_fdinfo handler for maps

On Thu, Nov 19, 2015, at 19:32, Alexei Starovoitov wrote: > On Thu, Nov 19, 2015 at 07:19:24PM +0100, Hannes Frederic Sowa wrote: > > On Thu, Nov 19, 2015, at 11:56, Daniel Borkmann wrote: > > > Add a handler for show_fdinfo() to be used by the anon-inodes > > > back

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 22:41, Eric Dumazet wrote: > On Thu, 2015-11-19 at 13:29 -0800, Tom Herbert wrote: > > > We (TCP stack) compete with QUIC, based on UDP, which has no issues like > > > that. We need to allow TCP sessions being signaled of a non temporary > > > network disruption. > > > >

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 23:04, Eric Dumazet wrote: > On Thu, 2015-11-19 at 22:53 +0100, Hannes Frederic Sowa wrote: > > > > > You don't steer QUIC source addresses at all? I think most networking > > failures are of transient nature thus the kernel routing subsystem

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 19:27, Hannes Frederic Sowa wrote: > I will research the semantics behind tcpdrop: > <http://www.freebsd.org/cgi/man.cgi?query=tcpdrop=0=0=FreeBSD+10.2-RELEASE=default=html> Fyi, my research shows that it just sends RST and discards complete socket state.

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 23:15, Eric Dumazet wrote: > On Thu, 2015-11-19 at 23:09 +0100, Hannes Frederic Sowa wrote: > > > My point is the "eventually" and the very much increased latency until > > the kernel learns about new better source addresses it has availab

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 23:33, Lorenzo Colitti wrote: > On Fri, Nov 20, 2015 at 2:38 AM, Tom Herbert wrote: > >> I actually don't have an issue with killing from user space that much. I > >> still recommend (and actually have started to look at it today) to add a > >> new

Re: Asterisk deadlocks since Kernel 4.1

On Thu, Nov 19, 2015, at 12:43, Stefan Priebe - Profihost AG wrote: > > Am 19.11.2015 um 12:41 schrieb Hannes Frederic Sowa: > > On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote: > >> OK it had a livelock again. It just took more time. > >

Re: Asterisk deadlocks since Kernel 4.1

On Thu, Nov 19, 2015, at 10:56, Stefan Priebe - Profihost AG wrote: > OK it had a livelock again. It just took more time. > > So here is the data: Thanks, I couldn't reproduce it so far with simple threaded resolver loop on your kernel. :/ Your data is useless if you don't also provide the file

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 06:12, Tom Herbert wrote: > I think this solution presumes some out of band signaling about a path > failure deep in the network that is not reported via the TCP > connection. This solution is obviously only as good as the signaling, > but clearly the most general solution

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Thu, Nov 19, 2015, at 17:19, Eric Dumazet wrote: > On Thu, 2015-11-19 at 10:48 -0500, David Miller wrote: > > At least if they do it this way, and someone claims that Linux TCP > > behaves outside the spec or improperly, it's not directly because of > > any code I am responsible for. > > > >

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

On Wed, Nov 18, 2015, at 18:28, Eric Dumazet wrote: > On Wed, 2015-11-18 at 16:54 +0100, Hannes Frederic Sowa wrote: > > > Still, the RST packet can be dropped along the way. So the teardown of > > the socket on the other side might not happen. > > This is why it is bett

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Wed, Nov 18, 2015, at 16:16, Eric Dumazet wrote: > On Wed, 2015-11-18 at 15:56 +0100, Hannes Frederic Sowa wrote: > > On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote: > > > On Wed, Nov 18, 2015 at 10:31 PM, Hannes Frederic Sowa > > > <han...@stressi

Re: [PATCH -next] net: tcp: move to timewait when receiving data post active-close

On Wed, Nov 18, 2015, at 16:46, Eric Dumazet wrote: > On Wed, 2015-11-18 at 16:36 +0100, Florian Westphal wrote: > > > Yes, but we kill the socket. > > > > I should have added > > > > 0.400 `ss -nito state time-wait` > > > > as last line... > > > > Before patch: no output > > after patch: tw

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Wed, Nov 18, 2015, at 16:32, Hannes Frederic Sowa wrote: > On Wed, Nov 18, 2015, at 16:16, Eric Dumazet wrote: > > On Wed, 2015-11-18 at 15:56 +0100, Hannes Frederic Sowa wrote: > > > On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote: > > > > On Wed, No

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Wed, Nov 18, 2015, at 21:35, David Miller wrote: > From: Lorenzo Colitti <lore...@google.com> > Date: Wed, 18 Nov 2015 19:47:21 +0900 > > > On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa > > <han...@stressinduktion.org> wrote: > >> I bet th

Re: Add a SOCK_DESTROY operation to close sockets from userspace

Hello, On Wed, Nov 18, 2015, at 02:43, Lorenzo Colitti wrote: > This patch series adds the ability for a privileged process to > destroy sockets belonging to other userspace processes via the > sock_diag interface, and implements that for TCP sockets. > > This functionality is needed on laptops

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Wed, Nov 18, 2015, at 11:47, Lorenzo Colitti wrote: > On Wed, Nov 18, 2015 at 7:19 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > I bet there will soon be a timewaitd which handles the not configurable > > (David has rejected all those patches so f

Re: Add a SOCK_DESTROY operation to close sockets from userspace

Hi, On Wed, Nov 18, 2015, at 05:04, Eric Dumazet wrote: > On Tue, 2015-11-17 at 19:27 -0800, Stephen Hemminger wrote: > > > I understand why you might want this, but it smells like the same > > kind of problems that the "forced unmount" patch had which eventually > > led to it not being accepted

Re: Add a SOCK_DESTROY operation to close sockets from userspace

Hello, On Wed, Nov 18, 2015, at 14:04, Lorenzo Colitti wrote: > On Wed, Nov 18, 2015 at 8:19 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > I was wondering why you didn't use tcp_close function, because still we > > could have the address and we w

Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote: > On Wed, Nov 18, 2015 at 10:31 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > I was not saying using tcp_close literally, sorry for not making that > > clear, but just model the state transitions a

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 22:36, Stefan Priebe wrote: > sorry here it is. What I'm wondering is why is there ipv6 stuff? I don't > have ipv6 except for link local. Could it be this one? > > https://bugzilla.redhat.com/show_bug.cgi?id=505105#c79 > > Thread 31 (Thread 0x7f295c011700 (LWP 26654)):

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 22:42, Stefan Priebe wrote: > > Am 18.11.2015 um 22:40 schrieb Hannes Frederic Sowa: > > On Wed, Nov 18, 2015, at 22:36, Stefan Priebe wrote: > >> sorry here it is. What I'm wondering is why is there ipv6 stuff? I don't > >> have ipv

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 21:23, Stefan Priebe wrote: > > Am 17.11.2015 um 20:43 schrieb Thomas Gleixner: > > On Tue, 17 Nov 2015, Stefan Priebe wrote: > >> I've now also two gdb backtraces from two crashes: > >> http://pastebin.com/raw.php?i=yih5jNt8 > >> > >>

Re: Asterisk deadlocks since Kernel 4.1

On Wed, Nov 18, 2015, at 22:20, Stefan Priebe wrote: > you mean just: > la /proc/$pid/fd ls -l /proc/pid/fd/ the numbers in brackets in return from readlink are the inode numbers. > and > > cat /proc/net/netlink Exactly, last row is the inode number. Bye, Hannes -- To unsubscribe from this

[PATCH net] rtnetlink: fix frame size warning in rtnl_fill_ifinfo

ones, so we don't have the huge frame allocations at the same time. Cc: Eric Dumazet <eduma...@google.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/rtnetlink.c | 274 --- 1 file changed, 152 insert

[PATCH net v2] rtnetlink: fix frame size warning in rtnl_fill_ifinfo

ones, so we don't have the huge frame allocations at the same time. Cc: Eric Dumazet <eduma...@google.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/core/rtnetlink.c | 274 --- 1 file changed, 152 insert

Re: [PATCH net] af_unix: take receive queue lock while appending new skb

Hi Eric, On Tue, Nov 17, 2015, at 15:42, Eric Dumazet wrote: > On Tue, 2015-11-17 at 15:10 +0100, Hannes Frederic Sowa wrote: > > While possibly in future we don't necessarily need to use > > sk_buff_head.lock this is a rather larger change, as it affects the > > af_unix

<    2   3   4   5   6   7   8   9   >