netdev - Re: [PATCHv5 3/4] sparc64: Avoid irqsave/restore on vio.lock if in

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: <20141025.142822.141874034124023889.davem@davemloft.net>
Date:	Sat, 25 Oct 2014 14:28:22 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	sowmini.varadhan@...cle.com
Cc:	netdev@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [PATCHv5 3/4] sparc64: Avoid irqsave/restore on vio.lock if
 in_softirq()

From: Sowmini Varadhan <sowmini.varadhan@...cle.com>
Date: Wed, 22 Oct 2014 18:12:45 -0400

> 
> For NAPIfied drivers , there is no need to
> synchronize by doing irqsave/restore on vio.lock in the I/O
> path.
> 
> Signed-off-by: Sowmini Varadhan <sowmini.varadhan@...cle.com>

Conditional locking is broken locking, and the bug you introduce
here is a good example of why that is.

If the vio->timer has to be triggered when vio_port_up() is
invoked, it will next run fron in_softirq() context regardless
of whether the user is sunvnet or sunvdc.  So it will elide
the locking regardless of who is using this vio context.

Never, ever, use conditional locking.

This locking is harmless overhead in a slow path, just leave
it alone for now.
--
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