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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 05 May 2014 16:56:53 -0400 (EDT) From: David Miller <davem@...emloft.net> To: soren.brinkmann@...inx.com Cc: michal.simek@...inx.com, nicolas.ferre@...el.com, git@...inx.com, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, netdev@...r.kernel.org Subject: Re: [PATCH 5/5] net: macb: Fix race between HW and driver From: Soren Brinkmann <soren.brinkmann@...inx.com> Date: Sun, 4 May 2014 15:43:02 -0700 > Under "heavy" RX load, the driver cannot handle the descriptors fast > enough. In detail, when a descriptor is consumed, its used flag is > cleared and once the RX budget is consumed all descriptors with a > cleared used flag are prepared to receive more data. Under load though, > the HW may constantly receive more data and use those descriptors with a > cleared used flag before they are actually prepared for next usage. > > The head and tail pointers into the RX-ring should always be valid and > we can omit clearing and checking of the used flag. > > Signed-off-by: Soren Brinkmann <soren.brinkmann@...inx.com> Isn't the RX_USED bit the only thing that controls what RX entries the chip will try to use? I can't see how you can just remove the RX_USED bit handling altogether. The problem actually seems to be that in the current code we clear the RX_USED bit before we actually reallocate the buffer and set it up. It should be a bug to see the RX_USED bit set in gem_rx_refill(), and the only reason why it can happen is exactly because you're clearing it too early in gem_rx(). This change doesn't seem to be correct, I'm not applying this series sorry. -- 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