netdev - RE: [PATCH -next v2 3/4] net: w5100: increase TX timeout period

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]

Date:	Mon, 16 May 2016 09:33:05 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Akinobu Mita' <akinobu.mita@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:	Mike Sinkovsky <msink@...monline.ru>,
	"David S . Miller" <davem@...emloft.net>
Subject: RE: [PATCH -next v2 3/4] net: w5100: increase TX timeout period

From: netdev-owner@...r.kernel.org Akinobu Mita
> Sent: 14 May 2016 06:56
> This increases TX timeout period from one second to 5 seconds which is
> the default value if the driver doesn't explicitly set
> net_device->watchdog_timeo.
> 
> The one second timeout is too short for W5100 with SPI interface mode
> which doesn't support burst READ/WRITE processing in the SPI transfer.
> If the packet is transmitted while RX packets are being received at a
> very high rate, the TX transmittion work in the workqueue is delayed
> and the watchdog timer is expired.

ISTM that if RX traffic can cause a 1 second timeout to expire I can
see no reason why it shouldn't also cause a 5 second timer to expire.

I'm guessing that something needs to be done to cause the SPI
block to discard receive frames (I guess the hardware will be discarding
them as well) in order to allow frames to be transmitted.

Given the 'damp string' nature of SPI, you might even want to give
transmits priority over receives.

	David