netdev - Re: [PATCH] ksz884x: fix receive polling 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] [day] [month] [year] [list]

Message-Id: <20121219.124517.1102318399340089630.davem@davemloft.net>
Date:	Wed, 19 Dec 2012 12:45:17 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	buytenh@...tstofly.org
Cc:	Tristram.Ha@...rel.com, dannyfeng@...cent.com,
	netdev@...r.kernel.org, cphealy@...il.com
Subject: Re: [PATCH] ksz884x: fix receive polling race condition

From: Lennert Buytenhek <buytenh@...tstofly.org>
Date: Tue, 18 Dec 2012 14:57:00 +0100

> The ksz884x driver does receive processing in a custom tasklet, and
> seems to be assuming that since it takes its private interface spinlock
> with spin_lock_irq(), it won't be running concurrently with its own
> interrupt handler, as it cannot be preempted by it, but since its
> interrupt handler doesn't do any locking whatsoever, the receive
> processing tasklet and interrupt handler can end up running concurrently
> on different CPUs.
> 
> As a result of this, the ksz884x receive path ends up locking up fairly
> easily, when the receive processing tasklet's reenabling of receive
> interrupts (due to it being done with polling the receive ring) races
> with the interrupt handler's disabling of receive interrupts (due to a
> new receive interrupt coming in) resulting in the receive interrupt
> being masked but the receive processing tasklet not being scheduled.
> 
> Fix this by making the ksz884x interrupt handler take its private
> interface spinlock.  This requires upgrading the spin_lock() in the
> transmit cleanup tasklet to a spin_lock_irq(), as otherwise the IRQ
> handler can preempt transmit cleanup and deadlock the system, but
> with those two changes, no more receive lockups have been observed.
> 
> Reported-by: Chris Healy <cphealy@...il.com>
> Signed-off-by: Lennert Buytenhek <buytenh@...tstofly.org>

Applied, thanks.
--
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