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: Wed, 02 May 2007 16:21:06 -0400 From: David Acker <dacker@...net.com> To: Milton Miller <miltonm@....com> CC: Scott Feldman <sfeldma@...ox.com>, Jeff Garzik <jeff@...zik.org>, e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Andrew Morton <akpm@...ux-foundation.org>, John Ronciak <john.ronciak@...el.com>, Jesse Brandeburg <jesse.brandeburg@...el.com>, Jeff Kirsher <jeffrey.t.kirsher@...el.com>, Auke Kok <auke-jan.h.kok@...el.com> Subject: Re: [PATCH] e100 rx: or s and el bits David Acker wrote: > Milton Miller wrote: >> In commit d52df4a35af569071fda3f4eb08e47cc7023f094, the description >> talks about emulating another driver by setting addtional bits and >> the being unable to test when submitted. Seeing the & operator to >> set more bits made me suspicious, and indeed the bits are defined >> in positive logic: >> >> cb_s = 0x4000, >> cb_el = 0x8000, >> >> So anding those together would be 0. I'm guessing they should >> be or'd, but don't have hardware here to test, much like the >> committed patch. In fact, I'll let someone else do the compile >> test too. I'll update the comment. >> > > I wonder if this worked for me because the hardware also spun on the > link field being NULL? Since the RU base is also set to 0, the > calculated physical address would be 0 as well. I would imagine if the > hardware tried to read/write to very low addresses across PCI, there > would be issues. I will retest with a small receive pool to try to hit > the problem. > I will also run these tests with the new patch and with a smaller > receive pool (default is 256) to make the pool run out more often. So far my testing has shown both the original and the new version of the S-bit patch work in that no corruption seemed to occur over long term runs. The previous S-bit patch may have only worked due to something specific about how my PCI companion chip handles I/O to low memory addresses (from dereferencing a link address of 0). Perhaps the e100 handles the NULL link as well, but given that the manual does not seem to state what happens when the hardware encounters a buffer with a link of 0, I think Milton's fix is the proper way to do it. The old eepro driver did set both bits although it did it with a hardcoded constant. I will continue testing with slab debug on but that will take longer. Has anyone tried this on other platforms? -Ack - 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