Bug#782515: [PATCH stable 3.10-3.16] tcp: Fix crash in TCP Fast Open

ecend(skb_put(syn_data, space), > fo->data->msg_iov, 0, space))) { > kfree_skb(syn_data); > Looks goot to me, thanks Ben ! Acked-by: Eric Dumazet -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#782515: [stable regression] tcp: make connect() mem charging friendly

On Tue, 2015-04-14 at 08:32 +0100, Ben Hutchings wrote: > Commit 355a901e6cf1b2b763ec85caa2a9f04fbcc4ab4a ("tcp: make connect() > mem charging friendly") was backported to various stable branches: > > v3.10.73: e64a85197b3f tcp: make connect() mem charging friendly > v3.12.40: d06381e8aac5 tcp: ma

Bug#708995: iptables firewall is dropping GRO'd packets

On Tue, 2013-05-21 at 14:55 +0200, Jiri Pirko wrote: > This is looking good to me. On my test machine it makes tbf work correctly > with gso packets. > I worked on similar patch (enqueue path) myself some time ago but I got > distracted by other tasks. Yes, I understood this. > > Do you plan to

Bug#708995: iptables firewall is dropping GRO'd packets

On Mon, 2013-05-20 at 17:53 -0700, Eric Dumazet wrote: > On Tue, 2013-05-21 at 01:28 +0100, Ben Hutchings wrote: > > I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO > > kicks in on the LAN interface. > > > > On Mon, 2013-05-20 at

Bug#708995: iptables firewall is dropping GRO'd packets

On Tue, 2013-05-21 at 01:28 +0100, Ben Hutchings wrote: > I'm seeing packet loss when forwarding from a LAN to PPP, whenever GRO > kicks in on the LAN interface. > > On Mon, 2013-05-20 at 05:48 +0100, Ben Hutchings wrote: > [...] > > The Windows system is connected to the LAN interface (int0). Tu

Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken

On Wed, 2013-04-03 at 00:15 +0200, Hannes Frederic Sowa wrote: > On Tue, Apr 02, 2013 at 03:00:38PM -0700, Eric Dumazet wrote: > > On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote: > > > > > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF

Bug#565404: linux-image-2.6.26-2-amd64: atl1e: TSO is broken

On Tue, 2013-04-02 at 23:15 +0200, Hannes Frederic Sowa wrote: > The error vanishes as soon as I put a gso size limit of MAX_TX_BUF_LEN > in the driver. MAX_TX_BUF_LEN seems to be arbitrary set to 0x2000. I > can even raise it to 0x3000 and don't see any tcp retransmits. Do you > have an advice on

Bug#660804: [PATCH V2] ipsec: be careful of non existing mac headers

-by: Eric Dumazet --- V2: added skb_mac_header_rebuild() helper as David suggested. include/linux/skbuff.h | 10 ++ net/ipv4/xfrm4_mode_beet.c |5 + net/ipv4/xfrm4_mode_tunnel.c |6 ++ net/ipv6/xfrm6_mode_beet.c |6 +- net/ipv6/xfrm6_mode_tunnel.c |6

Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet

Le jeudi 23 février 2012 à 15:23 -0500, David Miller a écrit : > I think the work to backport is equal whether you use a helper function > or not. Heck, use an inline function so you don't have to worry about > module exports or any details like that. > > Besides, I'm the one who likely has to b

Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet

Le jeudi 23 février 2012 à 15:11 -0500, David Miller a écrit : > Three instances of the same piece of code, maybe a helper function is > appropriate at that point? :-) You might even get ambitious and add a > big comment to that helper function explaining the situation. I did have this idea but re

Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet

Le jeudi 23 février 2012 à 15:36 +0100, Eric Dumazet a écrit : > [PATCH] ipsec: be careful of non existing mac headers > > Nicollo Belli reported ipsec crashes in case we handle a frame without > mac header (atm in his case) Oops sorry for your name being mangled in changelog, it

Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet

opying mac header, better make sure it is present. Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809 Reported-by: Niccolò Belli Tested-by: Niccolò Belli Signed-off-by: Eric Dumazet --- net/ipv4/xfrm4_mode_beet.c |9 + net/ipv4/xfrm4_mode_tunnel.c

Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet

Le jeudi 23 février 2012 à 02:38 +0100, Eric Dumazet a écrit : > Which driver handles this Traverse Solos card ? If br2684_push() is used, it seems it lacks proper call to skb_reset_mac_header(skb) in paths where eth_type_trans() is not called. Later in xfrm4_mode_tunnel_input() we cr

Bug#660804: [Bug 42809] New: kernel panic when receiving an ipsec packet

Le jeudi 23 février 2012 à 01:59 +0100, Niccolò Belli a écrit : > Hi, > The bug is still present in latest 3.2.7 vanilla kernel. I wasted the > whole day debugging that damn thing and I finally discovered the root cause. > The problem is with my Traverse Solos multi-port ADSL2+ PCI card[1] > (whi

Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable

Le lundi 30 janvier 2012 à 15:57 +0100, Eric Dumazet a écrit : > Hmm, TX _completion_ is not run from tasklet but hardware IRQ, this is > why I added the spin_lock_irqsave(). > > > Tasklet fires the TX, but hardware IRQ does the TX completion part. > > This driver is ...

Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable

Le lundi 30 janvier 2012 à 14:41 +, Ben Hutchings a écrit : > On Mon, 2012-01-30 at 15:28 +0100, Eric Dumazet wrote: > > Le lundi 30 janvier 2012 à 14:05 +, Ben Hutchings a écrit : > > > > > Yes, I spotted that. But no descriptors are pushed to the hardware > &

Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable

Le lundi 30 janvier 2012 à 14:05 +, Ben Hutchings a écrit : > Yes, I spotted that. But no descriptors are pushed to the hardware > here; that's done in the driver's TX tasklet. Although... maybe that > can run immediately when scheduled from here? I've never had to deal > with tasklets so I

Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable

Le lundi 30 janvier 2012 à 11:14 +0100, Eric Dumazet a écrit : > Le lundi 30 janvier 2012 à 12:51 +0300, Denis Kirjanov a écrit : > > I'll check this out. After kernel.org was cracked I've missed > > @kernel.org mail account. > > > At first glance, start_

Bug#656476: Sundance network driver (D-Link DFE-580TX) timeouts rendering interface unusable

Le lundi 30 janvier 2012 à 12:51 +0300, Denis Kirjanov a écrit : > I'll check this out. After kernel.org was cracked I've missed > @kernel.org mail account. At first glance, start_tx() is racy against TX completion. It does : if (np->cur_tx - np->dirty_tx < TX_QUEUE_LEN - 1 &&

Bug#650495: linux-image-3.1.0-1-amd64: oops

driver. Sorry. > > > > If you can reproduce it with the nvidia driver and not without, that's > > fine too, since in that case we can pass it on to the nvidia driver > > packagers (who would presumably help you file a report with nvidia). > > Actually this bug is rea

Bug#646063: net: fix route cache rebuilds

Le mardi 08 novembre 2011 à 01:39 +0100, Florian Fuessl a écrit : > Unfortunately the system still suffered from two network disconnects starting > with the following messages in the kernel log: > Nov 7 06:38:41 spozerl kernel: [ 9025.854230] Route hash chain too long! > Nov 7 06:38:41 spozerl

Bug#646063: net: fix route cache rebuilds

Le vendredi 21 octobre 2011 à 01:07 +0100, Ben Hutchings a écrit : > Eric, do you see any problems with this? Would we need any more > follow-up fixes? Hi Ben This patch is probably safe, it should avoid the emergency rebuild trigger.even with few entries in cache, because of one long chain [di

Bug#631945: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler

372 Debian ref: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631945 Reported-by: Lucas Bocchi Reported-and-bisected-by: Michal Pokrywka Signed-off-by: Eric Dumazet CC: Michal Soltys Acked-by: Patrick McHardy --- net/sched/sch_sfq.c |7 ++- 1 files changed, 6 insertions(+), 1 delet

Bug#631945: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler

Le vendredi 29 juillet 2011 à 15:27 +0200, Eric Dumazet a écrit : > Le vendredi 29 juillet 2011 à 14:29 +0200, Michal Soltys a écrit : > > On 11-07-15 00:14, Andrew Morton wrote: > > > > > > (switched to email. Please respond via emailed reply-to-all, not via >

Bug#631945: [Bugme-new] [Bug 39372] New: Problems with HFSC Scheduler

Le vendredi 29 juillet 2011 à 14:29 +0200, Michal Soltys a écrit : > On 11-07-15 00:14, Andrew Morton wrote: > > > > (switched to email. Please respond via emailed reply-to-all, not via > > the bugzilla web interface). > > > > > > Here: WARN_ON(next_time == 0); > > > > From the other thread o

Bug#599816: Nested GRE locking bug

Le lundi 25 octobre 2010 à 12:53 -0700, David Miller a écrit : > I'll commit the following to upstream, and submit a combined > patch to -stable. > > > net: Increase xmit RECURSION_LIMIT to 10. > > Three is definitely too low, and we know from reports that GRE tunnels > stac

Bug#599816: Nested GRE locking bug

Le mardi 19 octobre 2010 à 01:53 -0700, David Miller a écrit : > From: Eric Dumazet > Date: Thu, 14 Oct 2010 06:11:59 +0200 > > > net-next-2.6 contains a fix for this, adding the perc_cpu > > xmit_recursion limit. We might push it to net-2.6 > > We need to think a b

Bug#595265: linux-image-2.6.32-5-686: Nerwork card fails to come up again after suspend

Le lundi 18 octobre 2010 à 23:45 +0200, Francois Romieu a écrit : > Ben Hutchings : > [...] > > Arnout Boelens reported that his RTL8111/8168B fails to link-up after > > suspend and resume, both under Debian's kernel based on 2.6.32 and under > > 2.6.36-rc6. Full details are at

Bug#599816: Nested GRE locking bug

ns a fix for this, adding the perc_cpu xmit_recursion limit. We might push it to net-2.6 Thanks commit 745e20f1b626b1be4b100af5d4bf7b3439392f8f Author: Eric Dumazet Date: Wed Sep 29 13:23:09 2010 -0700 net: add a recursion limit in xmit path As tunnel devices are going to be loc

Bug#572201: forcedeth driver hangs under heavy load

Le mardi 13 avril 2010 à 14:43 -0700, David Miller a écrit : > Do you really come to the conclusion that TSO is broken with the above > test results? > > I would conclude that there is a TX checksumming issue, since merely > turning TSO off does not fix the problem whereas turning TX > checksummin

Bug#572201: forcedeth driver hangs under heavy load

Le mardi 13 avril 2010 à 16:25 +0100, stephen mulcahy a écrit : > Eric Dumazet wrote: > > OK, thanks for clarification. > > > > Last question, did you tried a vanilla kernel, aka 2.6.33.2 for > > example ? > > I built a Debian package from the vanilla 2.6.33.2 a

Bug#572201: forcedeth driver hangs under heavy load

Le mardi 13 avril 2010 à 16:08 +0100, stephen mulcahy a écrit : > Eric Dumazet wrote: > > > I am scratching my head, but I thought you told me that > > > > ethtool -K eth0 tso off > > ethtool -K eth0 tx on > > > > was working ? > > No, sorr

Bug#572201: forcedeth driver hangs under heavy load

Le mardi 13 avril 2010 à 15:49 +0100, stephen mulcahy a écrit : > Eric Dumazet wrote: > > Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit : > >> Ok, I've tried both of the following with my reproducer > >> > >> 1. ethtool -K eth0 tso off >

Bug#572201: forcedeth driver hangs under heavy load

Le mardi 13 avril 2010 à 15:27 +0100, stephen mulcahy a écrit : > Ok, I've tried both of the following with my reproducer > > 1. ethtool -K eth0 tso off > > RESULT: reproducer causes multiple hosts to be come unresponsive on > first run. > > 2. ethtool -K eth0 tx off > > RESULT: reproducer run

Bug#572201: forcedeth driver hangs under heavy load

Le mardi 13 avril 2010 à 11:03 +0100, stephen mulcahy a écrit : > Eric Dumazet wrote: > > OK it seems forcedeth has problem with checksums ? > > > > Try to change "ethtool -k eth0" settings ? > > > > ethtool -K eth0 tso off tx off > > Yes, t

Bug#572201: forcedeth driver hangs under heavy load

Le lundi 12 avril 2010 à 17:11 +0100, stephen mulcahy a écrit : > Eric Dumazet wrote: > > Le lundi 12 avril 2010 à 14:19 +0100, stephen mulcahy a écrit : > > > > Do you have some netfilters rules ? > > > > Hi Eric, > > I don't have any netfilters ru

Bug#572201: forcedeth driver hangs under heavy load

Le lundi 12 avril 2010 à 14:19 +0100, stephen mulcahy a écrit : > Does that help? Well, yes, because it seems a TCP problem. r...@node20:~# tcpdump host node20 and node05 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), ca

Bug#572201: forcedeth driver hangs under heavy load

Le lundi 12 avril 2010 à 13:39 +0100, stephen mulcahy a écrit : > stephen mulcahy wrote: > > It doesn't - further testing over the weekend saw 6 of 45 machines drop > > off the network with this problem. Nothing in dmesg or system logs. > > Happy to run more tests if someone can advise on what sh