netdev - [PATCH 0/3]: via-velocity: Fixes for locking issues

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

Message-ID: <20100205165253.3f316b98@marrow.netinsight.se>
Date:	Fri, 5 Feb 2010 16:52:53 +0100
From:	Simon Kagstrom <simon.kagstrom@...insight.net>
To:	netdev@...r.kernel.org, davem@...emloft.net, davej@...hat.com,
	ben@...adent.org.uk
Subject: [PATCH 0/3]: via-velocity: Fixes for locking issues

Hi!

This series of patches fixes a set of locking issues in the
via-velocity driver. Since some of the problems were introduced in
2.6.33-rc1 (with my patches, sorry!), it would be good if they could
get in before the final 2.6.33 release.

The patches are (the third one is the complex one):

  * A small cleanup to remove unused parameters for rx_srv and tx_srv

  * Take the spinlock from set_coalesce

  * Fix races that occur with shared interrupts

We have a system where the interrupt for the VIA card is shared with a
USB controller. The last patch fixes a deadlock situation, which we can
trigger on our UP with spinlock debugging, where the VIA driver is
executing in velocity_poll (the NAPI poll callback) when the USB
controller interrupts the CPU. Since the interrupt controller takes the
(already held) lock, it will deadlock.

Some questions about the implementation though:

The patch uses spin_trylock in the interrupt handler, and returns
IRQ_NONE if it's already held. Here is a place where I'm unsure about
the right way though. Another alternative is to use spin_lock_irqsave
in velocity_poll(), but I'd like to avoid turning the interrupts off
for "long" periods of time when the actual velocity interrupt can't
happen anyway (since it is turned off while executing velocity_poll().

With spin_trylock and spinlock debugging on our UP, we get a bug from
the debugging code:

  BUG: spinlock trylock failure on UP on CPU#0, swapper/0

which looking at the debug code isn't unexpected since spin_trylock is
called from an interrupt handler. In this case though, I don't think
this is an actual error.

We don't have access to any multiprocessor machine with a VIA NIC (I
guess they are not very common), so I haven't been able to test these
patches on actual SMP hardware.

The locking in via-velocity in general would be good to look over, I
think.

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