From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <c375fdd1f9e99d3297783ffd139be38d@plan9.bell-labs.com>
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ether8139.c fix
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu,  7 Mar 2002 09:08:25 -0500
Topicbox-Message-UUID: 61312f02-eaca-11e9-9e20-41e7f4b1d025


<geoff@collyer.net> a crit dans le message news:<20020304000219.1ABC919999@mail.cse.psu.edu>...
> Line 494, in rtl8139receive(), reads
> 
> 				memmove(bp->rp, p, l);
> but should be
> 				memmove(bp->wp, p, l);
> 
> jmk has vetted this change.

This fix should be a noop.  Though the change should be made for
clarity, after the bp = iallocb(length), both bp->rp and
bp->wp point to the same spot.

However, looking at the code, if the packet wraps around the
buffer, and if the crc straddles the end of the ring buffer, the
code is just wrong.  It would be better as:

		bp = iallocb(length);
		if(p+length >= ctlr->rbstart+ctlr->rblen){
			l = ctlr->rbstart+ctlr->rblen - p;
			if(bp != nil){
				memmove(bp->rp, p, l);
				bp->wp += l;
			}
			length -= l;
			p = ctlr->rbstart;
		}
		if(length > 0 && bp != nil){
			memmove(bp->wp, p, length);
			bp->wp += length;
		}
		if(bp != nil){
			bp->wp -= 4;

One could rewrite the if-chain to be a bit more efficient, but
you should get the idea.

Of course, I'm assuming that the device allows the CRC to straddle
the end of the buffer.  If not, the code is fine as is.  However,
looking at memmove.s, it'll fault if the length is negative, which
I believe is the observed behaviour.