* [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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox