netdev - RE: [PATCH RFC 04/30] net: fec: fix interrupt handling races

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: <063D6719AE5E284EB5DD2968C1650D6D1725F962@AcuExch.aculab.com>
Date:	Fri, 20 Jun 2014 12:39:57 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Russell King' <rmk+kernel@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
CC:	Fugang Duan <B38611@...escale.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH RFC 04/30] net: fec: fix interrupt handling races

From: Russell King
> While running: while :; do iperf -c <HOST> -P 4; done, transmit timeouts
> are regularly reported.  With the tx ring dumping in place, we can see
> that all entries are in use, and the hardware has finished transmitting
> these packets.  However, the driver has not reclaimed these ring
> entries.
> 
> This can occur if the interrupt handler is invoked at the wrong moment -
> eg:
> 
> 	CPU0				CPU1
> 	fec_enet_tx()
> 					interrupt, IEVENT = FEC_ENET_TXF
> 					FEC_ENET_TXF cleared
> 					napi_schedule_prep()
> 	napi_complete()
> 
> The result is that we clear the transmit interrupt, but we don't trigger
> any cleaning of the transmit ring.  Instead, use a different strategy:
> 
> - When receiving a transmit or receive interrupt, disable both tx and rx
>   interrupts, but do not acknowledge them.  Schedule a napi poll.  Don't
>   loop.
> 
> - When we are polled, read IEVENT, acknowledging the pending transmit
>   and receive interrupts, before then going on to process the
>   appropriate rings.
> 
> This allows us to avoid the race, and has a number of other advantages:
> - we cut down on the number of transmit interrupts we have to process.
> - we only look at the rings which have pending events.
> - we gain additional throughput: the iperf total bandwidth increases
>   from about 180Mbps to 240Mbps:
...

It is usually possible to reduce the interrupt count even further by:
1) processing the rings.
2) clear the IRQ.
3) check the rings for new entries, if any start again.
This means that you don't take the interrupt for anything that completes
while processing the earlier ring entries.

The slight downside is that it is easy to exit the ISR before the IRQ
line actually drops - resulting in a spurious interrupt.

(patch 24 seems to be similar).

	David



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