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

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

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 > <han...@stressinduktion.org> wrote: > >> I agree here, but I don't think this patch particularly is a lot of >> bloat and something very interesting people ca

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: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to ndisc_opt_addr_space

On 04.05.2016 14:30, Alexander Aring wrote: > Hi, > > On 05/02/2016 09:37 PM, Hannes Frederic Sowa wrote: >> On 20.04.2016 10:19, Alexander Aring wrote: >>> This patch makes the address length as argument for the >>> ndisc_opt_addr_space function. This is necess

Re: [patch net-next] vrf: add exit function and allow module unload

Hello Jiri, On Wed, May 4, 2016, at 12:20, Jiri Pirko wrote: > drivers/net/vrf.c | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c > index 8a8f1e5..b217c2d 100644 > --- a/drivers/net/vrf.c > +++ b/drivers/net/vrf.c > @@ -839,7 +839,14 @@

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 <g.na...@alphalink.fr> >>> wrote: &

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) > >> { > >> /* > >>

Re: [PATCHv2 bluetooth-next 00/10] 6lowpan: introduce basic 6lowpan-nd

On 02.05.2016 19:25, Marcel Holtmann wrote: > Hi Dave, > >> this patch series introduces a layer for IPv6 neighbour discovery. At first >> it introduce the "ndisc_ops" to run a different handling for recv/send of >> NA/NS messages. The use case for such ndisc operation is RFC 6775 [0]. >> Which

Re: [PATCHv2 bluetooth-next 08/10] ipv6: export ndisc functions

ND_DEBUG)\ > + net_##level##_ratelimited(fmt, ##__VA_ARGS__); \ > +} while (0) > + If the debug messages are well thought out, I think we could install them always on debug level. There are valid users now, so Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCHv2 bluetooth-next 04/10] ndisc: add addr_len parameter to ndisc_opt_addr_space

On 20.04.2016 10:19, Alexander Aring wrote: > This patch makes the address length as argument for the > ndisc_opt_addr_space function. This is necessary to handle addresses > which don't use dev->addr_len as address length. Would it make sense for patch 4, 5 and 6 to add the operation to

Re: [PATCHv2 bluetooth-next 07/10] ipv6: introduce neighbour discovery ops

On 20.04.2016 10:19, Alexander Aring wrote: > This patch introduces neighbour discovery ops callback structure. The > structure contains at first receive and transmit handling for NS/NA and > userspace option field functionality. > > These callback offers 6lowpan different handling, such as

Re: [PATCHv2 bluetooth-next 02/10] 6lowpan: add 802.15.4 short addr slaac

ames Morris <jmor...@namei.org> > Cc: Hideaki YOSHIFUJI <yoshf...@linux-ipv6.org> > Cc: Patrick McHardy <ka...@trash.net> > Signed-off-by: Alexander Aring <a...@pengutronix.de> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks, Hannes

Re: [PATCHv2 bluetooth-next 03/10] 6lowpan: remove ipv6 module request

On 20.04.2016 10:19, Alexander Aring wrote: > Since we use exported function from ipv6 kernel module we don't need to > request the module anymore to have ipv6 functionality. > > Signed-off-by: Alexander Aring <a...@pengutronix.de> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCHv2 bluetooth-next 01/10] 6lowpan: add private neighbour data

Hello, On 20.04.2016 10:19, Alexander Aring wrote: > This patch will introduce a 6lowpan neighbour private data. Like the > interface private data we handle private data for generic 6lowpan and > for link-layer specific 6lowpan. > > The current first use case if to save the short address for a

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.  

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

Re: mlx5e throwing RTNL_ASSERT error on vxlan_get_rx_port

Hello, On 22.04.2016 22:02, Saeed Mahameed wrote: > On Fri, Apr 22, 2016 at 10:30 PM, Alexander Duyck > wrote: >> From what I can tell it looks like the recent commit that changed the >> behavior for vxlan_get_rx_port has broken the mlx5 driver as it was >> calling

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 <han...@stressinduktion.org> > 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: >>&

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

Re: [PATCH net-next 0/7] net: network drivers should not depend on geneve/vxlan

Hi David, On Wed, Apr 20, 2016, at 03:11, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Wed, 20 Apr 2016 03:06:13 +0200 > > > On Wed, Apr 20, 2016, at 02:27, David Miller wrote: > >> From: Hannes Frederic Sowa <han...@st

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

Re: Regression in next for smsc911x with tigthen lockdep checks

Hi, On 20.04.2016 17:01, Tony Lindgren wrote: > Looks like commit fafc4e1ea1a4 ("sock: tigthen lockdep checks for > sock_owned_by_user") in next causes a regression at least for > smsc911x with CONFIG_LOCKDEP. It keeps spamming with the following > message. Any ideas? Not yet, can you quickly

Re: [PATCH net-next 0/7] net: network drivers should not depend on geneve/vxlan

On 20.04.2016 03:11, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Wed, 20 Apr 2016 03:06:13 +0200 > >> On Wed, Apr 20, 2016, at 02:27, David Miller wrote: >>> From: Hannes Frederic Sowa <han...@stressinduktion.org> >&

Re: [PATCH net-next 0/7] net: network drivers should not depend on geneve/vxlan

On Wed, Apr 20, 2016, at 02:27, David Miller wrote: > From: Hannes Frederic Sowa <han...@stressinduktion.org> > Date: Mon, 18 Apr 2016 21:19:41 +0200 > > > This patchset removes the dependency of network drivers on vxlan or > > geneve, so those don't get autoloaded wh

[PATCH net-next 6/7] vxlan: break dependency with netdev drivers

. This also comes in beneficial if in future we want to add offloading knobs for vxlan. Cc: Jesse Gross <je...@kernel.org> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/vxlan.c | 14 +- include/linux/netdevice.h | 1 + include

[PATCH net-next 5/7] qlcnic: protect qlicnic_attach_func with rtnl_lock

qlcnic_attach_func requires rtnl_lock to be held. Cc: dept-gelinuxnic...@qlogic.com Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/ethernet/qlogic/qlcnic/qlcnic_main.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drive

[PATCH net-next 7/7] geneve: break dependency with netdev drivers

Equivalent to "vxlan: break dependency with netdev drivers", don't autoload geneve module in case the driver is loaded. Instead make the coupling weaker by using netdevice notifiers as proxy. Cc: Jesse Gross <je...@kernel.org> Signed-off-by: Hannes Frederic Sowa <han...@

[PATCH net-next 4/7] ixgbe: protect vxlan_get_rx_port in ixgbe_service_task with rtnl_lock

idm...@intel.com> Cc: Bruce Allan <bruce.w.al...@intel.com> Cc: John Ronciak <john.ronc...@intel.com> Cc: Mitch Williams <mitch.a.willi...@intel.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 2 ++

[PATCH net-next 3/7] mlx4: protect mlx4_en_start_port in mlx4_en_restart with rtnl_lock

mlx4_en_start_port requires rtnl_lock to be held. Cc: Eugenia Emantayev <euge...@mellanox.com> Cc: Yishai Hadas <yish...@mellanox.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 2 ++ 1 file changed, 2 i

[PATCH net-next 1/7] benet: be_resume needs to protect be_open with rtnl_lock

om> Cc: Somnath Kotur <somnath.ko...@broadcom.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/ethernet/emulex/benet/be_main.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/emulex/benet/be_m

[PATCH net-next 2/7] fm10k: protect fm10k_open in fm10k_io_resume with rtnl_lock

@intel.com> Cc: Bruce Allan <bruce.w.al...@intel.com> Cc: John Ronciak <john.ronc...@intel.com> Cc: Mitch Williams <mitch.a.willi...@intel.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 2 ++ 1 f

[PATCH net-next 0/7] net: network drivers should not depend on geneve/vxlan

This patchset removes the dependency of network drivers on vxlan or geneve, so those don't get autoloaded when the nic driver is loaded. Also audited the code such that vxlan_get_rx_port and geneve_get_rx_port are not called without rtnl lock. Hannes Frederic Sowa (7): benet: be_resume needs

Re: switchdev fib offload issues

Hi Jiri, On 18.04.2016 17:47, Jiri Pirko wrote: Proposed solutions (ideas): 1) per-netns. Add a procfs file: /proc/sys/net/ipv4/route/fib_offload_error_policy with values: "evict" - default, current behaviour "fail" - propagate offload error to user

Re: [PATCH net-next v2] vxlan: synchronously and race-free destruction of vxlan sockets

On 15.04.2016 22:36, David Miller wrote: From: Hannes Frederic Sowa <han...@stressinduktion.org> Date: Fri, 8 Apr 2016 22:55:01 +0200 @@ -1053,7 +1052,9 @@ static void __vxlan_sock_release(struct vxlan_sock *vs) vxlan_notify_del_rx_port(vs); spin_unlock(>

Re: [PATCH RFC 1/2] tun: don't require serialization lock on tx

, in absence of qdisc, no serialization lock is acquired by the caller. Signed-off-by: Paolo Abeni <pab...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: [PATCH RFC 2/2] tun: don't set a default qdisc

On 14.04.2016 12:01, Michael S. Tsirkin wrote: On Thu, Apr 14, 2016 at 05:21:40PM +0800, Jason Wang wrote: On 04/14/2016 05:10 PM, Michael S. Tsirkin wrote: On Thu, Apr 14, 2016 at 05:07:50PM +0800, Jason Wang wrote: On 04/14/2016 05:05 PM, Michael S. Tsirkin wrote: On Thu, Apr 14, 2016

Re: [PATCH RFC 1/2] tun: don't require serialization lock on tx

On 13.04.2016 11:41, Michael S. Tsirkin wrote: On Wed, Apr 13, 2016 at 11:04:46AM +0200, Paolo Abeni wrote: The current tun_net_xmit() implementation don't need any external lock since it relay on rcu protection for the tun data structure and on socket queue lock for skb queuing. This patch

[PATCH net-next] vxlan: reduce usage of synchronize_net in ndo_stop

We only need to do the synchronize_net dance once for both, ipv4 and ipv6 sockets, thus removing one synchronize_net in case both sockets get dismantled. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- Based on patch: [net-next,v2] vxlan: synchronously and rac

Re: [PATCH net-next v2] vxlan: synchronously and race-free destruction of vxlan sockets

On Sat, Apr 9, 2016, at 01:24, Cong Wang wrote: > On Fri, Apr 8, 2016 at 1:55 PM, Hannes Frederic Sowa > <han...@stressinduktion.org> wrote: > > Due to the fact that the udp socket is destructed asynchronously in a > > work queue, we have some nondeterministic

[PATCH net-next v2] vxlan: synchronously and race-free destruction of vxlan sockets

by searching vxlan_net->sock_list. Cc: Eric Dumazet <eric.duma...@gmail.com> Cc: Jiri Benc <jb...@redhat.com> Cc: Marcelo Ricardo Leitner <marcelo.leit...@gmail.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- v2) synchronize_rcu -> synchronize_net (p

Re: [PATCH net] vxlan: synchronously and race-free destruction of vxlan sockets

Hi Marcelo, On 08.04.2016 20:51, Marcelo Ricardo Leitner wrote: On Thu, Apr 07, 2016 at 04:57:40PM +0200, Hannes Frederic Sowa wrote: Due to the fact that the udp socket is destructed asynchronously in a work queue, we have some nondeterministic behavior during shutdown of vxlan tunnels

Re: [PATCH net-next] ipv6, token: allow for clearing the current device token

On 08.04.2016 17:25, Bjørn Mork wrote: Hannes Frederic Sowa <han...@stressinduktion.org> writes: On Fri, Apr 8, 2016, at 16:18, Bjørn Mork wrote: Daniel Borkmann <dan...@iogearbox.net> writes: if (!token) return -EINVAL; - if (ipv6_ad

Re: [PATCH net-next] ipv6, token: allow for clearing the current device token

On Fri, Apr 8, 2016, at 16:18, Bjørn Mork wrote: > Daniel Borkmann writes: > > > > > if (!token) > > return -EINVAL; > > - if (ipv6_addr_any(token)) > > - return -EINVAL; > > if (dev->flags & (IFF_LOOPBACK | IFF_NOARP)) > >

Re: [PATCH net-next] ipv6, token: allow for clearing the current device token

date previously tokenized addresses") Reported-by: Robin H. Johnson <robb...@gentoo.org> Signed-off-by: Daniel Borkmann <dan...@iogearbox.net> Cc: Hannes Frederic Sowa <han...@stressinduktion.org> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org> Thanks, Hannes

[PATCH net-next] sock: tigthen lockdep checks for sock_owned_by_user

Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- fs/cifs/connect.c| 4 ++-- include/net/sock.h | 44 +--- net/bluetooth/af_bluetooth.c | 2 +- net/llc/llc_proc.c | 2 +- net/sunrpc/svcsock.c

[PATCH net-next v2] sock: make lockdep_sock_is_held inline and conditional on LOCKDEP

; Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/sock.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/net/sock.h b/include/net/sock.h index eb2d7c3e120b25..81d6fecec0a2c0 100644 --- a/include/net/sock.h +++ b/include/net/sock.h @@

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 <pet...@infradead.org> Cc: Ingo Molnar <mi...@redhat.com> Cc: Eric Dumaze

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On 08.04.2016 01:08, Eric Dumazet wrote: On Fri, 2016-04-08 at 00:47 +0200, Hannes Frederic Sowa wrote: I see... hmpf. Wouldn't it be nicer if I include a helper a la: #define lockdep_is_held(lock) 1 in lockdep.h in case lockdep is globally not enabled? I do actually have already another

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

t;da...@davemloft.net> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- Hello Peter and Ingo, if it is possible coud this go in via the net-tree, as this problem is visible there already? Would be happy to get a review. Thanks, Hannes include/linux/lockdep.h | 2 ++

Re: [PATCH net-next] sock: make lockdep_sock_is_held static inline

On 08.04.2016 00:37, Eric Dumazet wrote: On Thu, 2016-04-07 at 15:30 -0700, Eric Dumazet wrote: But... this wont solve the compiler error ? include/net/sock.h: In function 'lockdep_sock_is_held': include/net/sock.h:1367:2: error: implicit declaration of function 'lockdep_is_held'

Re: [net-next:master 194/196] include/net/sock.h:1367:9: error: implicit declaration of function 'lockdep_is_held'

On Thu, Apr 7, 2016, at 23:09, David Miller wrote: > From: kbuild test robot > Date: Fri, 8 Apr 2016 05:00:42 +0800 > > >include/net/sock.h: In function 'lockdep_sock_is_held': > >>> include/net/sock.h:1367:9: error: implicit declaration of function > >>>

[PATCH net-next] sock: make lockdep_sock_is_held static inline

I forgot to add inline to lockdep_sock_is_held, so it generated all kinds of build warnings if not build with lockdep support. Reported-by: kbuild test robot <fengguang...@intel.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/sock.h | 2 +- 1 fil

[PATCH net] vxlan: synchronously and race-free destruction of vxlan sockets

by searching vxlan_net->sock_list. Cc: Jiri Benc <jb...@redhat.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/vxlan.c | 20 +++- include/net/vxlan.h | 2 -- 2 files changed, 3 insertions(+), 19 deletions(-) diff --git a/drivers/net/vx

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

[PATCH net-next 3/3] tun: use socket locks for sk_{attach,detatch}_filter

de cleaner by ensuring that only one lock governs the socket filter instead of two independent locks. Cc: Daniel Borkmann <dan...@iogearbox.net> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- drivers/net/tun.c | 14 +- include/linux/filter

[PATCH net-next 1/3] sock: fix lockdep annotation in release_sock

the slock spinlock during processing the outstanding skbs). I took over this patch from Eric Dumazet and tested it. Signed-off-by: Eric Dumazet <eric.duma...@gmail.com> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/sock.h | 7 ++- net/core/sock.c

[PATCH net-next 2/3] net: introduce lockdep_is_held and update various places to use it

The socket is either locked if we hold the slock spin_lock for lock_sock_fast and unlock_sock_fast or we own the lock (sk_lock.owned != 0). Check for this and at the same time improve that the current thread/cpu is really holding the lock. Signed-off-by: Hannes Frederic Sowa <

[PATCH net-next 0/3] sock: lockdep tightening

First patch is from Eric Dumazet and improves lockdep accuracy for socket locks. After that, second patch introduces lockdep_sock_is_held and uses it. Final patch reverts and reworks the lockdep fix from Daniel in the filter code, as we now have tighter lockdep support. Hannes Frederic Sowa (3

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 01.04.2016 06:26, Alexei Starovoitov wrote: On Fri, Apr 01, 2016 at 06:12:49AM +0200, Hannes Frederic Sowa wrote: On 01.04.2016 06:04, Alexei Starovoitov wrote: On Thu, Mar 31, 2016 at 08:03:38PM -0700, Eric Dumazet wrote: On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote: Eric

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 01.04.2016 06:04, Alexei Starovoitov wrote: On Thu, Mar 31, 2016 at 08:03:38PM -0700, Eric Dumazet wrote: On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote: Eric, what's your take on Hannes's patch 2 ? Is it more accurate to ask lockdep to check for actual lock or lockdep can

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On Fri, Apr 1, 2016, at 05:13, Eric Dumazet wrote: > On Fri, 2016-04-01 at 04:01 +0200, Hannes Frederic Sowa wrote: > > > I thought so first, as well. But given the double check for the > > spin_lock and the "mutex" we end up with the same result for the &g

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On Fri, Apr 1, 2016, at 05:03, Eric Dumazet wrote: > On Thu, 2016-03-31 at 18:45 -0700, Alexei Starovoitov wrote: > > > Eric, what's your take on Hannes's patch 2 ? > > Is it more accurate to ask lockdep to check for actual lock > > or lockdep can rely on owned flag? > > Potentially there could

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 01.04.2016 03:45, Eric Dumazet wrote: On Thu, 2016-03-31 at 18:39 -0700, Eric Dumazet wrote: On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote: On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote: Thanks. As you can see, release_sock() messes badly lockdep (once your other

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 01.04.2016 03:39, Eric Dumazet wrote: On Fri, 2016-04-01 at 03:36 +0200, Hannes Frederic Sowa wrote: On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote: Thanks. As you can see, release_sock() messes badly lockdep (once your other patches are in ) Once we properly fix release_sock

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On Fri, Apr 1, 2016, at 03:23, Eric Dumazet wrote: > On Fri, 2016-04-01 at 02:30 +0200, Hannes Frederic Sowa wrote: > > > I fixed this one, I wait with review a bit and collapse some of the > > newer fixes into one and check and repost again tomorrow. > > No change

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On Fri, Apr 1, 2016, at 03:19, Eric Dumazet wrote: > Thanks. > > As you can see, release_sock() messes badly lockdep (once your other > patches are in ) > > Once we properly fix release_sock() and/or __release_sock(), all these > false positives disappear. This was a loopback connection. I need

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 01.04.2016 02:12, Eric Dumazet wrote: Since this function does not take a reference on the dst, how could it be safe ? As soon as you exit the function, dst would possibly point to something obsolete/freed. This works because the caller owns the socket. If you believe one path needs to be

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

On 01.04.2016 02:12, Eric Dumazet wrote: On Fri, 2016-04-01 at 02:01 +0200, Hannes Frederic Sowa wrote: Hi Eric, On 01.04.2016 01:39, Eric Dumazet wrote: On Fri, 2016-04-01 at 01:29 +0200, Hannes Frederic Sowa wrote: Various fixes which were discovered by this changeset. More probably

Re: [PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

Hi Eric, On 01.04.2016 01:39, Eric Dumazet wrote: On Fri, 2016-04-01 at 01:29 +0200, Hannes Frederic Sowa wrote: Various fixes which were discovered by this changeset. More probably to come... Really ? Again, TCP stack locks the socket most of the time. The fact that lockdep does

[PATCH net 6/4] tcp: fix __sk_dst_get usage in tcp_current_mss

Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/ipv4/tcp_output.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c index ba3621834e7bfa..3f70582578ada0 100644 --- a/net/ipv4/tcp_output.c +++ b/ne

[PATCH net 5/4] tcp: fix rcu usage around __sk_dst_get in tcp_update_metrics

Already another one fix I overlooked. Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- net/ipv4/tcp_metrics.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/ipv4/tcp_metrics.c b/net/ipv4/tcp_metrics.c index 33a36648423e8b..196de79902819a

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

Hi Daniel, On 31.03.2016 23:52, Daniel Borkmann wrote: On 03/31/2016 09:48 PM, Hannes Frederic Sowa wrote: [...] Tightest solution would probably be to combine both patches. bool called_by_tuntap; old_fp = rcu_dereference_protected(sk->sk_filter, called_by_tuntap ? lockdep_rtnl_is_h

[PATCH net 4/4] tcp: various missing rcu_read_lock around __sk_dst_get

Various fixes which were discovered by this changeset. More probably to come... Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/tcp.h | 5 - net/core/sock.c| 7 +-- net/ipv4/tcp_input.c | 18 ++ net/ipv4/tcp_metrics.

[PATCH net 3/4] sock: use lockdep_sock_is_held were appropriate

.@suse.cz> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/sock.h | 7 --- net/dccp/ipv4.c | 2 +- net/dccp/ipv6.c | 2 +- net/ipv4/af_inet.c | 2 +- net/ipv4/cipso_ipv4.c| 3 ++- net/ipv4/ip_sockglue.c | 4 ++--

[PATCH net 1/4] tun: add socket locking around sk_{attach,detach}_filter

uot;) Reported-by: Sasha Levin <sasha.le...@oracle.com> Cc: Daniel Borkmann <dan...@iogearbox.net> Cc: Alexei Starovoitov <alexei.starovoi...@gmail.com> Cc: Michal Kubecek <mkube...@suse.cz> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- driver

[PATCH net 0/4] net: fix and tighten rcu dereference checks

discovered by this change. Certainly there are more to come. Hannes Frederic Sowa (4): tun: add socket locking around sk_{attach,detach}_filter net: proper check if we hold the socket lock during dereference sock: use lockdep_sock_is_held were appropriate tcp: various missing rcu_read_lock around

[PATCH net 2/4] net: proper check if we hold the socket lock during dereference

Starovoitov <alexei.starovoi...@gmail.com> Cc: Michal Kubecek <mkube...@suse.cz> Signed-off-by: Hannes Frederic Sowa <han...@stressinduktion.org> --- include/net/sock.h | 5 + net/core/filter.c | 6 +++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/include/n

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On 31.03.2016 21:36, David Miller wrote: From: Hannes Frederic Sowa <han...@stressinduktion.org> Date: Thu, 31 Mar 2016 21:24:12 +0200 diff --git a/net/core/filter.c b/net/core/filter.c index 4b81b71171b4ce..8ab270d5ce5507 100644 --- a/net/core/filter.c +++ b/net/core/filter.c @@ -

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

Hello, On 31.03.2016 21:21, David Miller wrote: From: Daniel Borkmann Date: Thu, 31 Mar 2016 14:16:18 +0200 On 03/31/2016 01:59 PM, Eric Dumazet wrote: On Thu, 2016-03-31 at 13:35 +0200, Daniel Borkmann wrote: +static inline bool sock_owned_externally(const struct

Re: [PATCH net] tun, bpf: fix suspicious RCU usage in tun_{attach,detach}_filter

On 31.03.2016 07:43, Alexei Starovoitov wrote: On Thu, Mar 31, 2016 at 07:22:32AM +0200, Michal Kubecek wrote: On Wed, Mar 30, 2016 at 10:08:10PM -0700, Alexei Starovoitov wrote: On Thu, Mar 31, 2016 at 07:01:15AM +0200, Michal Kubecek wrote: On Wed, Mar 30, 2016 at 06:18:42PM -0700, Alexei

Re: [PATCH net v2] ipv4: fix broadcast packets reception

4/udp: Verify multicast group is ours in upd_v4_early_demux()") Signed-off-by: Paolo Abeni <pab...@redhat.com> Acked-by: Hannes Frederic Sowa <han...@stressinduktion.org>

Re: ipv6 not bringing up due to qdisc_tx_is_noop failing

Hello, On 16.03.2016 16:29, Nikolay Borisov wrote: I have stack traces which do show this sequence of events, so my questions now are: 1. What's the difference between netdev_queue->qdisc and netdev_queue->qdisc_sleeping. Git blaming indicates those member haves existed even before the git

Re: ipv6 not bringing up due to qdisc_tx_is_noop failing

On 16.03.2016 18:14, Nikolay Borisov wrote: On Wed, Mar 16, 2016 at 7:07 PM, Hannes Frederic Sowa <han...@stressinduktion.org> wrote: On 16.03.2016 16:29, Nikolay Borisov wrote: I have stack traces which do show this sequence of events, so my questions now are: 1. What's the diff

Re: [PATCH net-next v3 1/2] RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket

On 16.03.2016 12:10, Sowmini Varadhan wrote: On (03/16/16 11:29), Hannes Frederic Sowa wrote: Normally we kmemdup a table per netns and update its data pointer, so we can reuse the proc_doint_minmax functions. I remembered one more thing.. in this particular case, I need to have my one

Re: [PATCH net-next v3 1/2] RDS: TCP: Add sysctl tunables for sndbuf/rcvbuf on rds-tcp socket

Hello, some feedback. On 15.03.2016 19:53, Sowmini Varadhan wrote: Add per-net sysctl tunables to set the size of sndbuf and rcvbuf on the kernel tcp socket. The tunables are added at /proc/sys/net/rds/tcp/rds_tcp_sndbuf and /proc/sys/net/rds/tcp/rds_tcp_rcvbuf. Since these values must be

Re: [PATCH net v2] mld, igmp: Fix reserved tailroom calculation

On 01.03.2016 11:18, Daniel Borkmann wrote: On 03/01/2016 12:03 AM, Benjamin Poirier wrote: [...] Notes: Changes v1->v2 As suggested by Hannes, move the code to an inline helper and express it using "if" rather than "min". The code is correct, thanks! Therefore: Acked-by:

Re: [PATCH net v2] mld, igmp: Fix reserved tailroom calculation

;needed_tailroom or it may output more skbs than needed because not all space available is used. Fixes: 4c672e4b ("ipv6: mld: fix add_grhead skb_over_panic for devs with large MTUs") Signed-off-by: Benjamin Poirier <bpoir...@suse.com> I like it, thanks a lot! Ack

Re: [PATCH] mld, igmp: Fix reserved tailroom calculation

On 29.02.2016 19:08, Benjamin Poirier wrote: If you think we should write the expression with "if" instead of "min", instead of the current + skb->reserved_tailroom = skb_tailroom(skb) - + min_t(int, mtu, skb_tailroom(skb) - tlen); it should be: + if (mtu <

Re: [PATCH] mld, igmp: Fix reserved tailroom calculation

On 29.02.2016 16:19, Benjamin Poirier wrote: On 2016/02/29 15:57, Daniel Borkmann wrote: [...] [ cutting the IPv4 part off as diff is the same ] diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index 5ee56d0..c157edc 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -1574,9 +1574,9 @@

Re: [PATCH net] ipv4: only create late gso-skb if skb is already set up with CHECKSUM_PARTIAL

On 26.02.2016 01:45, Wakko Warner wrote: Now there's another one: [ 777.315931] [ cut here ] [ 777.316099] WARNING: CPU: 0 PID: 1404 at /usr/src/linux/dist/4.4-nobklcd/net/ipv4/af_inet.c:155 inet_sock_destruct+0x1cb/0x1f0() [ 777.316189] Modules linked in: nfsv3

Re: [patch net-next v2 0/9] Introduce devlink interface and first drivers to use it

On 25.02.2016 22:12, Jiri Pirko wrote: Thu, Feb 25, 2016 at 09:44:43PM CET, han...@stressinduktion.org wrote: On 25.02.2016 21:12, David Miller wrote: From: Jiri Pirko Date: Tue, 23 Feb 2016 16:51:25 +0100 There a is need for some userspace API that would allow to expose

Re: [patch net-next v2 0/9] Introduce devlink interface and first drivers to use it

On 25.02.2016 21:12, David Miller wrote: From: Jiri Pirko Date: Tue, 23 Feb 2016 16:51:25 +0100 There a is need for some userspace API that would allow to expose things that are not directly related to any device class like net_device of ib_device, but rather

Re: 4.4.1 skb_warn_bad_offload+0xc5/0x110

On 24.02.2016 02:46, Wakko Warner wrote: Please keep me in CC. Wakko Warner wrote: Hannes Frederic Sowa wrote: [full-quote for netdev] Hello, On 16.02.2016 01:08, Wakko Warner wrote: I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet

Re: [patch net-next 3/9] mlx4: Implement port type setting via devlink interface

On 23.02.2016 17:55, Jiri Pirko wrote: Tue, Feb 23, 2016 at 05:45:07PM CET, han...@stressinduktion.org wrote: On 23.02.2016 17:04, Jiri Pirko wrote: Tue, Feb 23, 2016 at 04:57:17PM CET, han...@stressinduktion.org wrote: On 23.02.2016 16:30, Jiri Pirko wrote: Tue, Feb 23, 2016 at 04:16:11PM

Re: [patch net-next 3/9] mlx4: Implement port type setting via devlink interface

On 23.02.2016 17:04, Jiri Pirko wrote: Tue, Feb 23, 2016 at 04:57:17PM CET, han...@stressinduktion.org wrote: On 23.02.2016 16:30, Jiri Pirko wrote: Tue, Feb 23, 2016 at 04:16:11PM CET, han...@stressinduktion.org wrote: 1) is easily solvable, just drop the ifindex style attributes and

Re: [patch net-next 3/9] mlx4: Implement port type setting via devlink interface

On 23.02.2016 16:30, Jiri Pirko wrote: Tue, Feb 23, 2016 at 04:16:11PM CET, han...@stressinduktion.org wrote: 1) is easily solvable, just drop the ifindex style attributes and always force the user to enter the bus and bus-topology id. But why? Use can easily get that info and map it to

Re: [patch net-next 3/9] mlx4: Implement port type setting via devlink interface

On 23.02.2016 15:26, Jiri Pirko wrote: Tue, Feb 23, 2016 at 02:28:05PM CET, han...@stressinduktion.org wrote: On 23.02.2016 13:21, Jiri Pirko wrote: Tue, Feb 23, 2016 at 12:26:00PM CET, han...@stressinduktion.org wrote: Hi Jiri, On 22.02.2016 19:31, Jiri Pirko wrote: From: Jiri Pirko

<    1   2   3   4   5   6   7   8   9   >