Netdev List
 help / color / mirror / Atom feed
* [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: Gilles Chanteperdrix @ 2014-11-16 18:05 UTC (permalink / raw)
  To: Nicolas Ferre, netdev; +Cc: Gilles Chanteperdrix

The at91_ether driver depends on symbols defined in the macb driver.

Currently, when compiling both at91_ether and macb as module, starting
the at91_ether module fails, because the macb module can not be loaded
with a macb interface.

Avoid this issue by getting the macb module initialization routine to
always return 0, even when no macb device is detected.

Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
---
 drivers/net/ethernet/cadence/macb.c |   15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 4d9fc05..f70228c 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2327,7 +2327,20 @@ static struct platform_driver macb_driver = {
 	},
 };
 
-module_platform_driver_probe(macb_driver, macb_probe);
+static bool found;
+static int __init macb_driver_init(void)
+{
+	found = platform_driver_probe(&macb_driver, macb_probe) == 0;
+	return 0;
+}
+module_init(macb_driver_init);
+
+static void __exit macb_driver_exit(void)
+{
+	if (found)
+		platform_driver_unregister(&macb_driver);
+}
+module_exit(macb_driver_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Cadence MACB/GEM Ethernet driver");
-- 
1.7.10.4

^ permalink raw reply related

* Re: [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Bjørn Mork @ 2014-11-16 18:31 UTC (permalink / raw)
  To: Martin Hauke; +Cc: netdev
In-Reply-To: <20141116000322.GA22833@gmx.de>

Martin Hauke <mardnh@gmx.de> writes:

> Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)

Thanks.  But you forgot the Signed-off-by line on both patches. Please
resubmit with it.  See
https://www.kernel.org/doc/Documentation/SubmittingPatches



Bjørn

^ permalink raw reply

* Re: [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: David Miller @ 2014-11-16 18:53 UTC (permalink / raw)
  To: gilles.chanteperdrix; +Cc: nicolas.ferre, netdev
In-Reply-To: <1416161106-27498-1-git-send-email-gilles.chanteperdrix@xenomai.org>

From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Date: Sun, 16 Nov 2014 19:05:06 +0100

> The at91_ether driver depends on symbols defined in the macb driver.
> 
> Currently, when compiling both at91_ether and macb as module, starting
> the at91_ether module fails, because the macb module can not be loaded
> with a macb interface.
> 
> Avoid this issue by getting the macb module initialization routine to
> always return 0, even when no macb device is detected.
> 
> Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>

This is not acceptable, sorry.

This means the module stays in memory even if nobody has a real use
for it.

You'll need to find another solution, and I'll say in passing that this
was very poorly designed and that's why the problem exists.

^ permalink raw reply

* [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Martin Hauke @ 2014-11-16 18:55 UTC (permalink / raw)
  To: Bjørn Mork; +Cc: netdev
In-Reply-To: <871tp3gfpr.fsf@nemi.mork.no>

Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)

Signed-off-by: Martin Hauke <mardnh@gmx.de>
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 22756db..b8a82b8 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -780,6 +780,7 @@ static const struct usb_device_id products[] = {
 	{QMI_FIXED_INTF(0x413c, 0x81a4, 8)},	/* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
 	{QMI_FIXED_INTF(0x413c, 0x81a8, 8)},	/* Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card */
 	{QMI_FIXED_INTF(0x413c, 0x81a9, 8)},	/* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
+	{QMI_FIXED_INTF(0x03f0, 0x581d, 4)},	/* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
 
 	/* 4. Gobi 1000 devices */
 	{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
-- 
2.1.2

^ permalink raw reply related

* Re: [PATCH v2 net-next 6/7] bpf: allow eBPF programs to use maps
From: David Miller @ 2014-11-16 19:04 UTC (permalink / raw)
  To: ast-uqk4Ao+rVK5Wk0Htik3J/w
  Cc: mingo-DgEjT+Ai2ygdnm+yROfE0A, luto-kltTT9wpgjJwATOyAt5JVQ,
	dborkman-H+wXaHxf7aLQT0dZR+AlfA,
	hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r,
	edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-api-u79uwXL29TY76Z2rM5mHXA,
	netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415929010-9361-7-git-send-email-ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>

From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
Date: Thu, 13 Nov 2014 17:36:49 -0800

> +static u64 bpf_map_lookup_elem(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5)
> +{
> +	/* verifier checked that R1 contains a valid pointer to bpf_map
> +	 * and R2 points to a program stack and map->key_size bytes were
> +	 * initialized
> +	 */
> +	struct bpf_map *map = (struct bpf_map *) (unsigned long) r1;
> +	void *key = (void *) (unsigned long) r2;
> +	void *value;
> +
> +	WARN_ON_ONCE(!rcu_read_lock_held());
> +
> +	value = map->ops->map_lookup_elem(map, key);
> +
> +	/* lookup() returns either pointer to element value or NULL
> +	 * which is the meaning of PTR_TO_MAP_VALUE_OR_NULL type
> +	 */
> +	return (unsigned long) value;
> +}

You should translate this into a true boolean '1' or '0' value so that
kernel pointers don't propagate to the user or his eBPF programs.

^ permalink raw reply

* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Denys Fedoryshchenko @ 2014-11-16 19:05 UTC (permalink / raw)
  To: Eric Dumazet; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1416161495.17262.90.camel@edumazet-glaptop2.roam.corp.google.com>

On 2014-11-16 20:11, Eric Dumazet wrote:
> On Sun, 2014-11-16 at 10:54 +0200, Denys Fedoryshchenko wrote:
>> As latest findings, when servers are going crazy because of tcp memory
>> invalid accounting.
>> First of all i upgraded kernel to latest version 3.17.3 and added also
>> patch from upcoming kernel,
>> "12) Don't call sock_kfree_s() with NULL pointers, this function also
>> has the side effect of adjusting
>> the socket memory usage.  From Cong Wang.", but it didnt helped.
>> 
>> I added printk_ratelimited to places where suspicious values might
>> appear, and got some more information.
>> First, is not very suspicious, no idea if it is a problem:
>> [ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by 
>> 4352
>> [ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by 
>> 4352
>> [ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by 
>> 4352
>> [ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by 
>> 4352
>> [ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by 
>> 4352
>> [ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by 
>> 4352
>> [ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by 
>> 4352
>> [ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by 
>> 4352
>> [ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by 
>> 4352
>> [ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by 
>> 4352
>> [ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by 
>> 4352
>> [ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by 
>> 4352
>> [ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by 
>> 4352
>> [ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by 
>> 4352
>> [ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by 
>> 4352
>> [ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by 
>> 4352
>> [ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by 
>> 4352
>> Second is always linked with crashes, it is sk_mem_uncharge and
>> sk_forward_alloc goes negative. Patch to show message
>> for sk_mem_uncharge in sock.h is very simple:
>> 
>>   static inline void sk_mem_uncharge(struct sock *sk, int size)
>> @@ -1480,6 +1485,8 @@
>>          if (!sk_has_account(sk))
>>                  return;
>>          sk->sk_forward_alloc += size;
>> +       if (sk->sk_forward_alloc < -8192)
>> +           printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
>> negative %d by %d\n", sk, sk->sk_forward_alloc, size);
>>   }
>> 
> 
> 
> Could you describe your hardware setup and networking setup ?
This problem are happening on multiple different units that i am using 
as https balancers, and all of them very different (except it is all 
Intel CPU's, but even in that - different generations and models). Such 
problem seems happens on all of them, and seems doesn't depend on 
hardware (networking - igb, e1000e, broadcom stuff - all affected). But 
if it is important:
S2600GZ motherboard, one E5-2620 Xeon
networking - onboard igb, 2 ports used
100GB RAM
This particular one has bonding (but it seems crashes with or without 
it).

System are custom, running on USB flash, busybox+glibc based setup, 
similar OS working for other purposes for NAT, PPPoE termination without 
any issues.

What is common between failing units:

I am using haproxy-based HTTPS balancer(Also as i remember haproxy doing 
a lot of setsockopt stuff), that is handling right now:
     454444 connections established
Bandwidth passing thru is around 1Gbps.

I'm disabling tso/gso/gro on all interfaces.

The way i am forwarding transparent traffic to haproxy:
iptables -t mangle -A PREROUTING -p tcp --sport 443 -j MARK --set-mark 
0x1
iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 
0x1
ip rule add fwmark 0x1 lookup 100
ip route add local 0.0.0.0/0 dev lo table 100

"Typical" setup is

backend ssl_passthru
         mode tcp
         option transparent
         source 0.0.0.0 usesrc clientip

frontend ssl-in
         mode tcp
         bind    :443 transparent
         default_backend ssl_passthru
         option tcp-smart-accept

I hope i didnt missed something important. I can provide remote ssh 
access to it.
I will keep sending info, just with hope that some of info maybe will 
give idea, what i should patch or test.

P.S. Just got an idea now, that -2147483648 hinting that somewhere is 
happening integer overflow from very large positive value, to negative. 
I will try to set triggers also to that now.

If required i can provide image with such system. I am not sure you are 
interested in this problem and if it can be reproduced on synthetic 
setup, but as i remember this memory leak happened with me once also on 
normal server with torrents (i left some image unattended for 2 weeks, 
with a lot of requests, and it crashed at the end), so it might affect 
also other use cases.
I am trying to limit now socket buffers, to see if it will decrease 
frequency of crashes.
Also i tried to put "canary" values inside structure, near 
sk_forward_alloc , to see if there is any sort of memory corruption 
occuring on sk_forward_alloc, but seems there is no corruption.
I will try also going back to stable kernels 3.2.64, to see if it will 
fix this problem, but testing takes sometimes almost 1 day, depends on 
luck.

^ permalink raw reply

* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Eric Dumazet @ 2014-11-16 19:10 UTC (permalink / raw)
  To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1416161495.17262.90.camel@edumazet-glaptop2.roam.corp.google.com>

On Sun, 2014-11-16 at 10:11 -0800, Eric Dumazet wrote:

> Could you describe your hardware setup and networking setup ?

Hmmm, this looks like a bug in TCP fast open.

I am cooking a patch.

^ permalink raw reply

* Re: [PATCH net] ipv4: Fix incorrect error code when adding an unreachable route
From: David Miller @ 2014-11-16 19:16 UTC (permalink / raw)
  To: pmatilai; +Cc: netdev
In-Reply-To: <beb6c57fb3e1591346d64ac2fcdb354cd87987d4.1415963644.git.pmatilai@redhat.com>

From: Panu Matilainen <pmatilai@redhat.com>
Date: Fri, 14 Nov 2014 13:14:32 +0200

> Trying to add an unreachable route incorrectly returns -ESRCH if
> if custom FIB rules are present:
> 
> [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
> RTNETLINK answers: Network is unreachable
> [root@localhost ~]# ip rule add to 55.66.77.88 table 200
> [root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
> RTNETLINK answers: No such process
> [root@localhost ~]#
> 
> Commit 83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
> return value for rule lookup") changed fib_rules_lookup()
> to use -ESRCH as a "not found" code internally, but for user space it
> should be translated into -ENETUNREACH. Handle the translation centrally in
> ipv4-specific fib_lookup(), leaving the DECnet case alone.
> 
> On a related note, commit b7a71b51ee37d919e4098cd961d59a883fd272d8
> ("ipv4: removed redundant conditional") removed a similar translation from
> ip_route_input_slow() prematurely AIUI.
> 
> Fixes: b7a71b51ee37 ("ipv4: removed redundant conditional")
> Signed-off-by: Panu Matilainen <pmatilai@redhat.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Bjørn Mork @ 2014-11-16 19:18 UTC (permalink / raw)
  To: Martin Hauke; +Cc: netdev
In-Reply-To: <20141116185525.GA19989@gmx.de>

Martin Hauke <mardnh@gmx.de> writes:

> Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
>
> Signed-off-by: Martin Hauke <mardnh@gmx.de>

Acked-by: Bjørn Mork <bjorn@mork.no>

Dave, please add this to the netdev stable queue as well.


Thanks,
Bjørn

^ permalink raw reply

* Re: [PATCH net] reciprocal_div: objects with exported symbols should be obj-y rather than lib-y
From: David Miller @ 2014-11-16 19:19 UTC (permalink / raw)
  To: hannes; +Cc: netdev, jim.epost
In-Reply-To: <85de478df37362b703cb5db64cbfc48d4d4439f5.1415974584.git.hannes@stressinduktion.org>

From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Fri, 14 Nov 2014 15:16:47 +0100

> Otherwise the exported symbols might be discarded because of no users
> in vmlinux.
> 
> Reported-by: Jim Davis <jim.epost@gmail.com>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH 1/1] drivers: net: cpsw: Fix TX_IN_SEL offset
From: David Miller @ 2014-11-16 19:20 UTC (permalink / raw)
  To: john.ogness
  Cc: linux-kernel, mugunthanvnm, balbi, george.cherian, jhovold, mpa,
	bhutchings, zonque, tklauser, netdev
In-Reply-To: <87sihlj11v.fsf@linutronix.de>

From: John Ogness <john.ogness@linutronix.de>
Date: Fri, 14 Nov 2014 15:42:52 +0100

> The TX_IN_SEL offset for the CPSW_PORT/TX_IN_CTL register was
> incorrect. This caused the Dual MAC mode to never get set when
> it should. It also caused possible unintentional setting of a
> bit in the CPSW_PORT/TX_BLKS_REM register.
> 
> The purpose of setting the Dual MAC mode for this register is to:
> 
>     "... allow packets from both ethernet ports to be written into
>      the FIFO without one port starving the other port."
> 					- AM335x ARM TRM
> 
> Signed-off-by: John Ogness <john.ogness@linutronix.de>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH 0/8] Netfilter/IPVS fixes for net
From: David Miller @ 2014-11-16 19:24 UTC (permalink / raw)
  To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1415984329-5569-1-git-send-email-pablo@netfilter.org>

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 14 Nov 2014 17:58:40 +0100

> The following patchset contains Netfilter updates for your net tree,
> they are:
 ...
> You can pull these changes from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git

Pulled, thanks a lot Pablo!

^ permalink raw reply

* Re: [PATCH net-next] tipc: allow one link per bearer to neighboring nodes
From: David Miller @ 2014-11-16 19:27 UTC (permalink / raw)
  To: holger.brunck; +Cc: jon.maloy, ying.xue, erik.hugne, netdev
In-Reply-To: <1415986399-23874-1-git-send-email-holger.brunck@keymile.com>

From: Holger Brunck <holger.brunck@keymile.com>
Date: Fri, 14 Nov 2014 18:33:19 +0100

> There is no reason to limit the amount of possible links to a
> neighboring node to 2. If we have more then two bearers we can also
> establish more links.
> 
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
> Reviewed-By: Jon Maloy <jon.maloy@ericsson.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH 1/1 net-next] openvswitch: use PTR_ERR_OR_ZERO
From: David Miller @ 2014-11-16 19:43 UTC (permalink / raw)
  To: fabf-AgBVmzD5pcezQB+pC5nmwQ
  Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1415989978-28559-1-git-send-email-fabf-AgBVmzD5pcezQB+pC5nmwQ@public.gmane.org>

From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:32:58 +0100

> Signed-off-by: Fabian Frederick <fabf@skynet.be>

Applied.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

^ permalink raw reply

* Re: [PATCH 1/1 net-next] net: dsa: replace count*size kmalloc by kmalloc_array
From: David Miller @ 2014-11-16 19:43 UTC (permalink / raw)
  To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1415990202-28673-1-git-send-email-fabf@skynet.be>

From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:36:42 +0100

> kmalloc_array manages count*sizeof overflow.
> 
> Signed-off-by: Fabian Frederick <fabf@skynet.be>

Applied, and yes I read Joe's feedback and the rest of this thread
wrt. sizeof(u8/s8).  That can be done as a followup.

^ permalink raw reply

* Re: [PATCH 1/1 net-next] net: dsa: replace count*size kzalloc by kcalloc
From: David Miller @ 2014-11-16 19:44 UTC (permalink / raw)
  To: fabf; +Cc: linux-kernel, netdev
In-Reply-To: <1415990303-28764-1-git-send-email-fabf@skynet.be>

From: Fabian Frederick <fabf@skynet.be>
Date: Fri, 14 Nov 2014 19:38:23 +0100

> kcalloc manages count*sizeof overflow.
> 
> Signed-off-by: Fabian Frederick <fabf@skynet.be>

Applied.

^ permalink raw reply

* Re: [PATCH] ieee802154: fix error handling in ieee802154fake_probe()
From: David Miller @ 2014-11-16 19:45 UTC (permalink / raw)
  To: marcel
  Cc: alex.aring, khoroshilov, linux-wpan, netdev, linux-kernel,
	ldv-project
In-Reply-To: <B1D43522-B042-4D92-8F8A-D2AD89A3F0F9@holtmann.org>

From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 15 Nov 2014 16:58:28 +0900

> Dave, do you want to just take it via net-stable tree? We currently
> have no urgent bluetooth-stable tree patches pending.

Yeah I can do that, applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH net] dcbnl : Disable software interrupts before taking dcb_lock
From: David Miller @ 2014-11-16 19:51 UTC (permalink / raw)
  To: anish; +Cc: netdev, john.fastabend, neerav.parikh
In-Reply-To: <1416011911-28998-1-git-send-email-anish@chelsio.com>

From: Anish Bhatt <anish@chelsio.com>
Date: Fri, 14 Nov 2014 16:38:31 -0800

> Solves possible lockup issues that can be seen from firmware DCB agents calling
> into the DCB app api.
> 
> DCB firmware event queues can be tied in with NAPI so that dcb events are
> generated in softIRQ context. This can results in calls to dcb_*app()
> functions which try to take the dcb_lock.
> 
> If the the event triggers while we also have the dcb_lock because lldpad or
> some other agent happened to be issuing a  get/set command we could see a cpu
> lockup.
> 
> This code was not originally written with firmware agents in mind, hence
> grabbing dcb_lock from softIRQ context was not considered.
> 
> Signed-off-by: Anish Bhatt <anish@chelsio.com>

Applied, thanks.

^ permalink raw reply

* Re: [GIT net] Open vSwitch
From: David Miller @ 2014-11-16 20:02 UTC (permalink / raw)
  To: pshelar; +Cc: netdev
In-Reply-To: <1416015444-1519-1-git-send-email-pshelar@nicira.com>

From: Pravin B Shelar <pshelar@nicira.com>
Date: Fri, 14 Nov 2014 17:37:24 -0800

> Following fixes are accumulated in ovs-repo.
> Three of them are related to protocol processing, one is
> related to memory leak in case of error and one is to
> fix race.
> Patch "Validate IPv6 flow key and mask values" has conflicts
> with net-next, Let me know if you want me to send the patch
> for net-next.

Pulled, thanks a lot.

I'll sort out the merge conflicts next time I merge net into
net-next, thanks for offering.

^ permalink raw reply

* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates 2014-11-14
From: David Miller @ 2014-11-16 20:04 UTC (permalink / raw)
  To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1416031715-32498-1-git-send-email-jeffrey.t.kirsher@intel.com>

From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 14 Nov 2014 22:08:23 -0800

> This series contains updates to i40e only.

Patch #3 needs to be updated to do error handling for the case where
skb_linearize() fails, as pointed out by Eric Dumazet.

^ permalink raw reply

* Business Project.
From: Mrs. Yeung Wong @ 2014-11-16 19:59 UTC (permalink / raw)
  To: Recipients

i have secured business project for you.reply only to my private email mrsyeungwong06@rogers.com if interested.

Regards,
Yeung.

^ permalink raw reply

* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Eric Dumazet @ 2014-11-16 20:16 UTC (permalink / raw)
  To: Denys Fedoryshchenko; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <8d9b6a2c313db242c1afb3bcd6a12c51@visp.net.lb>

On Sun, 2014-11-16 at 21:05 +0200, Denys Fedoryshchenko wrote:
> On 2014-11-16 20:11, Eric Dumazet wrote:
> > On Sun, 2014-11-16 at 10:54 +0200, Denys Fedoryshchenko wrote:
> >> As latest findings, when servers are going crazy because of tcp memory
> >> invalid accounting.
> >> First of all i upgraded kernel to latest version 3.17.3 and added also
> >> patch from upcoming kernel,
> >> "12) Don't call sock_kfree_s() with NULL pointers, this function also
> >> has the side effect of adjusting
> >> the socket memory usage.  From Cong Wang.", but it didnt helped.
> >> 
> >> I added printk_ratelimited to places where suspicious values might
> >> appear, and got some more information.
> >> First, is not very suspicious, no idea if it is a problem:
> >> [ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by 
> >> 4352
> >> [ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by 
> >> 4352
> >> [ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by 
> >> 4352
> >> [ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by 
> >> 4352
> >> [ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by 
> >> 4352
> >> [ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by 
> >> 4352
> >> [ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by 
> >> 4352
> >> [ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by 
> >> 4352
> >> [ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by 
> >> 4352
> >> [ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by 
> >> 4352
> >> [ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by 
> >> 4352
> >> [ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by 
> >> 4352
> >> [ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by 
> >> 4352
> >> [ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by 
> >> 4352
> >> [ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by 
> >> 4352
> >> [ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by 
> >> 4352
> >> [ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by 
> >> 4352
> >> Second is always linked with crashes, it is sk_mem_uncharge and
> >> sk_forward_alloc goes negative. Patch to show message
> >> for sk_mem_uncharge in sock.h is very simple:
> >> 
> >>   static inline void sk_mem_uncharge(struct sock *sk, int size)
> >> @@ -1480,6 +1485,8 @@
> >>          if (!sk_has_account(sk))
> >>                  return;
> >>          sk->sk_forward_alloc += size;
> >> +       if (sk->sk_forward_alloc < -8192)
> >> +           printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
> >> negative %d by %d\n", sk, sk->sk_forward_alloc, size);
> >>   }
> >> 
> > 
> > 
> > Could you describe your hardware setup and networking setup ?
> This problem are happening on multiple different units that i am using 
> as https balancers, and all of them very different (except it is all 
> Intel CPU's, but even in that - different generations and models). Such 
> problem seems happens on all of them, and seems doesn't depend on 
> hardware (networking - igb, e1000e, broadcom stuff - all affected). But 
> if it is important:
> S2600GZ motherboard, one E5-2620 Xeon
> networking - onboard igb, 2 ports used
> 100GB RAM
> This particular one has bonding (but it seems crashes with or without 
> it).
> 
> System are custom, running on USB flash, busybox+glibc based setup, 
> similar OS working for other purposes for NAT, PPPoE termination without 
> any issues.
> 
> What is common between failing units:
> 
> I am using haproxy-based HTTPS balancer(Also as i remember haproxy doing 
> a lot of setsockopt stuff), that is handling right now:
>      454444 connections established
> Bandwidth passing thru is around 1Gbps.
> 
> I'm disabling tso/gso/gro on all interfaces.
> 
> The way i am forwarding transparent traffic to haproxy:
> iptables -t mangle -A PREROUTING -p tcp --sport 443 -j MARK --set-mark 
> 0x1
> iptables -t mangle -A PREROUTING -p tcp --dport 443 -j MARK --set-mark 
> 0x1
> ip rule add fwmark 0x1 lookup 100
> ip route add local 0.0.0.0/0 dev lo table 100
> 
> "Typical" setup is
> 
> backend ssl_passthru
>          mode tcp
>          option transparent
>          source 0.0.0.0 usesrc clientip
> 
> frontend ssl-in
>          mode tcp
>          bind    :443 transparent
>          default_backend ssl_passthru
>          option tcp-smart-accept
> 
> I hope i didnt missed something important. I can provide remote ssh 
> access to it.
> I will keep sending info, just with hope that some of info maybe will 
> give idea, what i should patch or test.
> 
> P.S. Just got an idea now, that -2147483648 hinting that somewhere is 
> happening integer overflow from very large positive value, to negative. 
> I will try to set triggers also to that now.
> 
> If required i can provide image with such system. I am not sure you are 
> interested in this problem and if it can be reproduced on synthetic 
> setup, but as i remember this memory leak happened with me once also on 
> normal server with torrents (i left some image unattended for 2 weeks, 
> with a lot of requests, and it crashed at the end), so it might affect 
> also other use cases.
> I am trying to limit now socket buffers, to see if it will decrease 
> frequency of crashes.
> Also i tried to put "canary" values inside structure, near 
> sk_forward_alloc , to see if there is any sort of memory corruption 
> occuring on sk_forward_alloc, but seems there is no corruption.
> I will try also going back to stable kernels 3.2.64, to see if it will 
> fix this problem, but testing takes sometimes almost 1 day, depends on 
> luck.

Thanks Denys !

Could you try following patch ?

Thanks !

 net/ipv4/tcp_output.c |   33 +++++++++++----------------------
 1 file changed, 11 insertions(+), 22 deletions(-)

diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index a3d453b94747..877eb4aa05a6 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2998,7 +2998,7 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
 {
 	struct tcp_sock *tp = tcp_sk(sk);
 	struct tcp_fastopen_request *fo = tp->fastopen_req;
-	int syn_loss = 0, space, i, err = 0, iovlen = fo->data->msg_iovlen;
+	int syn_loss = 0, space, err = 0;
 	struct sk_buff *syn_data = NULL, *data;
 	unsigned long last_syn_loss = 0;
 
@@ -3031,25 +3031,17 @@ static int tcp_send_syn_data(struct sock *sk, struct sk_buff *syn)
 	/* limit to order-0 allocations */
 	space = min_t(size_t, space, SKB_MAX_HEAD(MAX_TCP_HEADER));
 
-	syn_data = skb_copy_expand(syn, MAX_TCP_HEADER, space,
-				   sk->sk_allocation);
-	if (syn_data == NULL)
+	syn_data = sk_stream_alloc_skb(sk, space, sk->sk_allocation);
+	if (!syn_data)
 		goto fallback;
 
-	for (i = 0; i < iovlen && syn_data->len < space; ++i) {
-		struct iovec *iov = &fo->data->msg_iov[i];
-		unsigned char __user *from = iov->iov_base;
-		int len = iov->iov_len;
-
-		if (syn_data->len + len > space)
-			len = space - syn_data->len;
-		else if (i + 1 == iovlen)
-			/* No more data pending in inet_wait_for_connect() */
-			fo->data = NULL;
+	memcpy(syn_data->cb, syn->cb, sizeof(syn->cb));
+	if (memcpy_fromiovec(skb_put(syn_data, space), fo->data->msg_iov, space))
+		goto fallback;
 
-		if (skb_add_data(syn_data, from, len))
-			goto fallback;
-	}
+	/* No more data pending in inet_wait_for_connect() */
+	if (space == fo->size)
+		fo->data = NULL;
 
 	/* Queue a data-only packet after the regular SYN for retransmission */
 	data = pskb_copy(syn_data, sk->sk_allocation);
@@ -3101,13 +3093,10 @@ int tcp_connect(struct sock *sk)
 		return 0;
 	}
 
-	buff = alloc_skb_fclone(MAX_TCP_HEADER + 15, sk->sk_allocation);
-	if (unlikely(buff == NULL))
+	buff = sk_stream_alloc_skb(sk, 0, sk->sk_allocation);
+	if (unlikely(!buff))
 		return -ENOBUFS;
 
-	/* Reserve space for headers. */
-	skb_reserve(buff, MAX_TCP_HEADER);
-
 	tcp_init_nondata_skb(buff, tp->write_seq++, TCPHDR_SYN);
 	tp->retrans_stamp = tcp_time_stamp;
 	tcp_connect_queue_skb(sk, buff);

^ permalink raw reply related

* Re: [patch iproute2] tc: add support for vlan tc action
From: Jamal Hadi Salim @ 2014-11-16 20:19 UTC (permalink / raw)
  To: Jiri Pirko, netdev
  Cc: davem, pshelar, therbert, edumazet, willemb, dborkman, mst, fw,
	Paul.Durrant, tgraf
In-Reply-To: <1415804134-9895-1-git-send-email-jiri@resnulli.us>

On 11/12/14 09:55, Jiri Pirko wrote:
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>

Latest patches work great. If you want you can
include these notes in the iproute2 commit log.

There is only one small doubt when i add two vlan
tags(Q followed by QandQ). Look at the very end
of the text i have below...

cheers,
jamal

---
export TC=/media/MT1/other-gits/iproute2-jiri/tc/tc
export ETH=eth0
#index supplied by kernel
sudo $TC actions add action vlan pop
#explicit add with our index
sudo $TC actions add action vlan pop index 10
sudo $TC actions add action vlan push id 123
sudo $TC actions add action vlan push id 456 protocol 802.1Q
sudo $TC actions add action vlan push id 789 protocol 802.1ad

sudo $TC actions ls action vlan
------ expect something like ----
         action order 0:  vlan pop
          index 1 ref 1 bind 0

         action order 1:  vlan push id 123 protocol 802.1Q
          index 2 ref 1 bind 0

         action order 2:  vlan push id 456 protocol 802.1Q
          index 3 ref 1 bind 0

         action order 3:  vlan push id 789 protocol 802.1ad
          index 4 ref 1 bind 0

         action order 4:  vlan pop
          index 10 ref 1 bind 0
-------
#show stats
sudo $TC -s actions ls action vlan

-------
         action order 0:  vlan pop
          index 1 ref 1 bind 0 installed 78 sec used 78 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 1:  vlan push id 123 protocol 802.1Q
          index 2 ref 1 bind 0 installed 44 sec used 44 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 2:  vlan push id 456 protocol 802.1Q
          index 3 ref 1 bind 0 installed 42 sec used 42 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 3:  vlan push id 789 protocol 802.1ad
          index 4 ref 1 bind 0 installed 39 sec used 39 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 4:  vlan pop
          index 10 ref 1 bind 0 installed 47 sec used 47 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0
-----

sudo $TC actions flush action vlan
#expect all actions to be gone..
sudo $TC actions ls action vlan

#lets bind actions to filters...
sudo ip li add dev dummy0 type dummy
sudo ifconfig dummy0 up
#
sudo tc qdisc del dev $ETH ingress
sudo tc qdisc add dev $ETH ingress
#
sudo $TC filter add dev $ETH parent ffff: pref 11 protocol ip \
u32 match ip src 10.0.0.1 flowid 1:1 \
action  vlan  push id 123 \
action mirred egress redirect dev dummy0

window 1> sudo tcpdump -n -i dummy0 -e -X
window 2> ping -c 1 10.0.0.1

Expect something like:
52:54:00:c3:4b:c5 > 02:00:00:22:01:01, ethertype 802.1Q (0x8100), length 
102: vlan 123, p 0, ethertype IPv4, ...
#now look at the stats..
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
#
sudo $TC filter add dev $ETH parent ffff: pref 12 protocol ip \
u32 match ip src 10.0.0.2 flowid 1:2 \
action vlan push id 456 protocol 802.1Q \
action mirred egress redirect dev dummy0

sudo tcpdump -n -i dummy0 -X -e
ping -c 1 10.0.0.2
#look at the stats..
sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
#
sudo $TC filter add dev $ETH parent ffff: pref 13 protocol ip \
u32 match ip src 10.0.0.13 flowid 1:13 \
action vlan push id 789 protocol 802.1ad \
action mirred egress redirect dev dummy0
ping -c 1 10.0.0.2

sudo tcpdump -n -i dummy0 -X -e
Expect ...
52:54:00:c3:4b:c5 > 02:00:00:22:01:01, ethertype 802.1Q-QinQ (0x88a8), 
length 102: vlan 789, p 0, ethertype IPv4,,,
#
sudo $TC -s filter ls dev $ETH parent 1: protocol ip
#
# Speaking in New Brunswickian:
#             For shits and giggles lets add two vlans ...
# match all pings this time...
#
sudo $TC filter add dev $ETH parent ffff: pref 11 protocol ip u32 \
match ip protocol 1 0xff flowid 1:1 \
action  vlan  push id 123 \
action vlan push id 789 protocol 802.1ad \
action mirred egress redirect dev dummy0

sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
------
filter pref 11 u32
filter pref 11 u32 fh 800: ht divisor 1
filter pref 11 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 
(rule hit 2 success 0)
   match 00010000/00ff0000 at 8 (success 0 )
         action order 1:  vlan push id 123 protocol 802.1Q
          index 13 ref 1 bind 1 installed 6 sec used 6 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 2:  vlan push id 789 protocol 802.1ad
          index 14 ref 1 bind 1 installed 6 sec used 6 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 3: mirred (Egress Redirect to device dummy0) stolen
         index 9 ref 1 bind 1 installed 6 sec used 6 sec
         Action statistics:
         Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0
----

Send 10 pings to 192.168.100.1
ping 192.168.100.1 -c 10

sudo $TC -s filter ls dev $ETH parent ffff: protocol ip
------
filter pref 11 u32
filter pref 11 u32 fh 800: ht divisor 1
filter pref 11 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 
(rule hit 24 success 10)
   match 00010000/00ff0000 at 8 (success 10 )
         action order 1:  vlan push id 123 protocol 802.1Q
          index 13 ref 1 bind 1 installed 143 sec used 60 sec
         Action statistics:
         Sent 840 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 2:  vlan push id 789 protocol 802.1ad
          index 14 ref 1 bind 1 installed 143 sec used 60 sec
         Action statistics:
         Sent 840 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0

         action order 3: mirred (Egress Redirect to device dummy0) stolen
         index 9 ref 1 bind 1 installed 143 sec used 60 sec
         Action statistics:
         Sent 840 bytes 10 pkt (dropped 0, overlimits 0 requeues 0)
         backlog 0b 0p requeues 0
--------

As can be seen, the two vlan tags were supposedly added. I am
not sure how well it worked. I see 4 more bytes added. tcpdump doesnt do
a good job telling me if it worked...

17:58:31.636816 00:22:01:01:52:54 > 00:00:00:00:02:00, ethertype 
802.1Q-QinQ (0x88a8), length 106: vlan 789, p 0, LLC, dsap Unknown 
(0x44) Group, ssap Null (0x00) Command, ctrl 0x5400: Information, send 
seq 0, rcv seq 42, Flags [Command], length 88
         0x0000:  0000 0000 0200 0022 0101 5254 88a8 0315
         0x0010:  00c3 4500 0054 c06b 0000 4001 704c 8100
         0x0020:  007b c0a8 6401 c0a8 649f 0000 24b8 027c
         0x0030:  000a c7e5 6854 0000 0000 e0b4 0900 0000
         0x0040:  0000 1011 1213 1415 1617 1819 1a1b 1c1d
         0x0050:  1e1f 2021 2223 2425 2627 2829 2a2b 2c2d
         0x0060:  2e2f 3031 3233 3435 3637

Here it is with just 802.1q tag...
17:53:38.198323 52:54:00:c3:4b:c5 > 02:00:00:22:01:01, ethertype 802.1Q 
(0x8100), length 102: vlan 456, p 0, ethertype IPv4, 192.168.100.1 > 
192.168.100.159: ICMP echo reply, id 620, seq 1, length 64
         0x0000:  0200 0022 0101 5254 00c3 4bc5 8100 01c8
         0x0010:  0800 4500 0054 c052 0000 4001 7065 c0a8
         0x0020:  6401 c0a8 649f 0000 6482 026c 0001 a2e4
         0x0030:  6854 0000 0000 cc04 0300 0000 0000 1011
         0x0040:  1213 1415 1617 1819 1a1b 1c1d 1e1f 2021
         0x0050:  2223 2425 2627 2829 2a2b 2c2d 2e2f 3031
         0x0060:  3233 3435 3637

------------

^ permalink raw reply

* Re: [PATCH] net/at91_ether: fix loading when macb is compiled as a module
From: Gilles Chanteperdrix @ 2014-11-16 20:32 UTC (permalink / raw)
  To: David Miller; +Cc: nicolas.ferre, netdev
In-Reply-To: <20141116.135302.1339801219762777528.davem@davemloft.net>

On Sun, Nov 16, 2014 at 01:53:02PM -0500, David Miller wrote:
> From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Date: Sun, 16 Nov 2014 19:05:06 +0100
> 
> > The at91_ether driver depends on symbols defined in the macb driver.
> > 
> > Currently, when compiling both at91_ether and macb as module, starting
> > the at91_ether module fails, because the macb module can not be loaded
> > with a macb interface.
> > 
> > Avoid this issue by getting the macb module initialization routine to
> > always return 0, even when no macb device is detected.
> > 
> > Signed-off-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> 
> This is not acceptable, sorry.
> 
> This means the module stays in memory even if nobody has a real use
> for it.
> 
> You'll need to find another solution, and I'll say in passing that this
> was very poorly designed and that's why the problem exists.
> 

Ok, I see multiple possible other fixes:
- inline the shared functions in the macb.h driver or move them to a
library, this effectively means duplication, but who is going to
enable both drivers anyway?
- when both drivers are compiled as module, make one module
containing both drivers say at91+macb.ko
- modify the code I posted so that it only keeps the macb driver
loaded without macb device if IS_ENABLED(CONFIG_ARM_AT91_ETHER)
and probably many others I do not see.

I just do not know which one you would find acceptable.

Regards.

-- 
					    Gilles.

^ permalink raw reply

* Re: [PATCH 0/3] Add temperature reading and registers dump to mv88e6171
From: David Miller @ 2014-11-16 20:48 UTC (permalink / raw)
  To: andrew; +Cc: netdev, linux
In-Reply-To: <1416086694-15790-1-git-send-email-andrew@lunn.ch>

From: Andrew Lunn <andrew@lunn.ch>
Date: Sat, 15 Nov 2014 22:24:50 +0100

> These patches centralize the temperature sensor reading code, and then
> make use of it with the mv88e6171 which has a compatible
> sensor. Additionally, support is added for reading the mv88e6171 via
> ethtool.

Series applied to net-next, thanks.

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox