lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 17 Jun 2008 02:29:09 -0700 (PDT) From: David Miller <davem@...emloft.net> To: mingo@...e.hu Cc: kuznet@....inr.ac.ru, vgusev@...nvz.org, mcmanus@...ksong.com, xemul@...nvz.org, netdev@...r.kernel.org, ilpo.jarvinen@...sinki.fi, linux-kernel@...r.kernel.org, e1000-devel@...ts.sourceforge.net, rjw@...k.pl Subject: Re: [TCP]: TCP_DEFER_ACCEPT causes leak sockets From: Ingo Molnar <mingo@...e.hu> Date: Tue, 17 Jun 2008 11:27:06 +0200 > when i originally reported it i debugged it back to missing e1000 TX > completion IRQs. I tried various versions of the driver to figure out > whether new workarounds for e1000 cover it but it was fruitless. There > is a 1000 msec internal watchdog timer IRQ within e1000 that gets things > going if it's stuck. Then that explains your latency, the chip is getting stuck and TX interrupts stop, right. > But the line sch_generic.c:222 problem is new. It could be an > escallation of this same problem - not even the hw-internal watchdog > timeout fixing up things? So basically two levels of completion failed, > the third fallback level (a hard reset of the interface) helped things > get going. High score from me for networking layer robustness :-) I think it is an escallation of the same problem. My first thought is that there must have been some change to the reset logic and it isn't as foolproof as it used to be, especially under load. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists