netdev - Re: [PATCH] sky2: RX lockup fix

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: <1196900326.21996.1.camel@localhost.localdomain>
Date:	Wed, 05 Dec 2007 18:18:46 -0600
From:	Peter Tyser <ptyser@...-inc.com>
To:	Stephen Hemminger <shemminger@...ux-foundation.org>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] sky2: RX lockup fix

On Wed, 2007-12-05 at 16:40 -0500, Stephen Hemminger wrote:
> > I looked over Marvell's most recent sk98lin driver and it looks like
> > they had a "workaround" for the Yukon XL that the sky2 doesn't have yet.
> > The sk98lin driver disables the RX MAC FIFO flush feature for all
> > revisions of the Yukon XL.
> > 
> > According to skgeinit.c of the sk98lin driver, "Flushing must be enabled
> > (needed for ASF see dev. #4.29), but the flushing mask should be
> > disabled (see dev. #4.115)".  Nice.   I implemented this same change in
> > the sky2 driver and verified that the RX lockup I was seeing was
> > resolved.
> > 
> 
> 
> Without the flush, does flow control still work? My concern is that
> integrating this would cause pause packets (and over/under length packets)
> to not be handled correctly.

My understanding is that "bad" packets should still be filtered in
sky2_receive() when a packet's status is compared against
GMR_FS_ANY_ERR.  This comparison should prevent over/under length
packets from making their way up the stack.  This comparison also uses
the same value that was previous programmed to the RX MAC FIFO Flush
Mask, so there shouldn't be any change in the types of bad packets that
are discarded.

I don't believe that disabling RX filtering should affect the handling
of flow control packets specifically either.  The comparison in
sky2_receive() to GMR_FS_ANY_ERR does allow valid flow control packets
to be received. (I'm not intimately familiar with sky2/Linux's handling
of flow control packets, so take the above with a grain of salt)

As I understand it, the only real downside of disabling RX filtering at
the hardware level is that the CPU has to investigate every incoming
packet's status, even the ones that it is going to drop due to length,
crc, etc.  This adds some overhead, but I don't believe it should affect
the driver's operation.

--
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