| 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
| ||
|
Message-ID: <20080621071253.GA17557@2ka.mipt.ru> Date: Sat, 21 Jun 2008 11:12:53 +0400 From: Evgeniy Polyakov <johnpol@....mipt.ru> To: Travis Stratman <tstratman@...cinc.com> Cc: netdev@...r.kernel.org Subject: Re: data received but not detected On Fri, Jun 20, 2008 at 04:06:12PM -0500, Travis Stratman (tstratman@...cinc.com) wrote: > This is what I have been focusing on. I'm still trying to figure out a > good way to see if the interrupt is triggered for a specific packet > because I have no way of determining which packet it will freeze on and > if I put any prints in the interrupt handler or poll function it slows > things down enough that the problem disappears. It may or may not be the driver issue, but the way it works with NAPI. Or driver just looses interrupt (or if it has weird interrupt coalescing/mitigation feature) under the load. What about adding a counter into interrupt handler and napi polling callback with ability to clear/read it via driver ioctl (or just clear it when first small packet is recived and dump when module is unloaded), so can determine via tcpdump how many packets were actually received and what counter is. It can be trivial issue with work_done < or <= than budget, which was a frequent error in drivers for a while, and with your protocol it can be fatal until next received packet. -- Evgeniy Polyakov -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists