linux-kernel - Re: [PATCH 1/3] spi: spi-xilinx: Remove ISR race condition

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: <20130604173210.GL31367@sirena.org.uk>
Date:	Tue, 4 Jun 2013 18:32:10 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Michal Simek <michal.simek@...inx.com>
Cc:	linux-kernel@...r.kernel.org, Michal Simek <monstr@...str.eu>,
	Peter Crosthwaite <pcrost@...inx.com>,
	Peter Crosthwaite <peter.crosthwaite@...alogix.com>,
	Grant Likely <grant.likely@...aro.org>,
	spi-devel-general@...ts.sourceforge.net,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/3] spi: spi-xilinx: Remove ISR race condition

On Tue, Jun 04, 2013 at 04:02:34PM +0200, Michal Simek wrote:

> The ISR currently consumes the rx buffer data and re-enables transmission
> from within interrupt context. This is bad because if the interrupt
> occurs again before the ISR exits, the new interrupt will be erroneously
> cleared by the still completing ISR.

> Simplified the ISR by just setting the completion variable and exiting with
> no action. Then just looped the transmit functionality in
> xilinx_spi_txrx_bufs().

Applied but this is a bit sad, having to defer the refill to process
context means that we're adding extra latency which takes us further
away from being able to saturate the bus.  There ought to be a way to
avoid the issue though I can't think of a non-racy one - I guess level
triggered interrupts aren't an option?

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)