netdev - Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and el bits)

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <46558896.9070505@roinet.com>
Date:	Thu, 24 May 2007 08:44:06 -0400
From:	David Acker <dacker@...net.com>
To:	Milton Miller <miltonm@....com>
CC:	Jeff Garzik <jgarzik@...ox.com>, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
	John Ronciak <john.ronciak@...el.com>,
	Jesse Brandeburg <jesse.brandeburg@...el.com>,
	Scott Feldman <sfeldma@...ox.com>,
	"Kok, Auke" <auke-jan.h.kok@...el.com>
Subject: Re: [PATCH] fix e100 rx path on ARM (was [PATCH] e100 rx: or s and
 el bits)

Milton Miller wrote:
> On May 23, 2007, at 4:32 PM, David Acker wrote:
>> Milton Miller wrote:
>>> My current reading of the manual is that the C bit will not be
>>> set on an RFD that is size 0.  It goes on to processes EL and
>>> S, and decides to stop and interrupt RNR or suspend, or just
>>> go to the next packet.
>> I double checked this with a quick experiment and it appears you are 
>> correct.
>>
>> What about if we always did the following:
>> set the size:
>> sync();
>> clear el-bit
>> sync()
>>
>> Then if the hardware sees just the size set, the packet completes but 
>> with the el-bit and we know we need to restart since it completed.
>> If it sees the size == 0, and the el bit set, it stops and RNR 
>> interrupts.
> 
> I think this is exposed to a hole and a race:  we don't know if the 
> hardware
> read the RFD before we set the size or after, just that it was before 
> the EL
> bit was cleared.  If it read it before the size was set, then it will not
> set the C bit.  If it reads it after the size is set, it will complete it.
Yep...I too got sidetracked!  My test time got lost to two 2 month old 
twins needing to be fed or else! :-)

> 
> For coherent DMA we can always observe the C bit.  But for the 
> incoherent DMA
> case, our store to clear the EL bit may overwrite the dma from the 
> device to
> the beginning of the packet, or the write to EOF, F, and size, and/or the
> write to C, OK, and status bits to tell us its done.  In the worst case, we
> would overwrite the beginning of the data but catch the C bit and even the
> actual size, and therefore would receive corrupted data.
> 
> We can only detect the hardware went RNR when it does so or decide we 
> won the
> race when it receives and completes the next frame.
Yes, I agree.

>> When we find a buffer that is not completed but has the el-bit set, we 
>> read the status byte of the status control block to see if the RU is 
>> in the no resources state.  If it isn't, it means that we found that 
>> buffer  before the hardware did and thus need to wait for it.  We will 
>> either find it on the next poll or enable interrupts and get told 
>> about it by hardware.
>>
>> What do you think?
> 
> I think the second part is good ...
Cool.  That part seemed to work well in my tests.

I will reply to your next mail to discuss your plan so that I get it all 
in one message.
-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