netdev - Re: sky2 driver fails to handle "rx length error: status 0x5d60100 length 2982" gracefully

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] [day] [month] [year] [list]

Message-ID: <AANLkTimGFu8PPBtjkT+H4agjQ_Dvfqr3K2RFy1Z_78x+@mail.gmail.com>
Date:	Tue, 17 Aug 2010 13:05:49 -0700
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	Stephen Hemminger <shemminger@...ux-foundation.org>,
	Linux NetDev <netdev@...r.kernel.org>
Subject: Re: sky2 driver fails to handle "rx length error: status 0x5d60100
 length 2982" gracefully

> Also, the driver could schedule a reset (that is what the watchdog does),
> but it looks like the receive DMA is walking past the end of the packet
> and that is really dangerous since it could clobber random memory.

I'm not sure to what watchdog you are referring.
I'm not aware of this machine having a hw (or sw) watchdog.

> You might want to increase the size of rx DMA buffer and dump the
> contents of the receive buffer to see if there is a memory corruption

Is this something that is a userspace tweak (how? pointers please?),
or do you mean to modify the kernel source code and recompile.

> risk. If the End Of Frame DMA hardware is not working, there is a real
> danger if the driver silently continues.

Agreed, although that does seem to be what the driver is currently
doing... silently continuing.

---

BTW, I've run into the issue once more and I've verified that turning
off all acceleration options
doesn't fix the problem (ethtool -k eth0 rx off tx off sg off tso off
gso off [ufo/gro/lro already were off]), nor does trying to get
the network card to renegotiate the link speed (ethtool -s eth0 speed
10; sleep 5; ethtool -s eth0 speed 1000; sleep 5; ethtool -r eth0).

I am now testing to see if the problem ever occurs if all the
acceleration options are turned off.
Of late the occurrence rate seems to be pretty steady at about twice per week.

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