linux-kernel - Re: [patch 47/54] Staging: hv: make gVmbusConnection.ChannelLock a real spinlock

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: <200907210139.19672.arnd@arndb.de>
Date:	Tue, 21 Jul 2009 01:39:19 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	virtualization@...ts.linux-foundation.org
Cc:	"Greg Kroah-Hartman" <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
	virtualization@...ts.osdl.org, Sam Ramji <sramji@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Hank Janssen <hjanssen@...rosoft.com>,
	shemminger@...ux-foundation.org
Subject: Re: [patch 47/54] Staging: hv: make gVmbusConnection.ChannelLock a real spinlock

On Friday 17 July 2009, Greg Kroah-Hartman wrote:
> I don't think we really want to be doing a irqsave for this code, but I
> left it alone to preserve the original codepath.  It should be reviewed
> later.

This patch does not preserve the original code path if any of the
callers has a different irq state from the others. When flags is
shared, releasing the lock actually sets the irq state to whatever
another thread was using when failing to acquire the lock while
it was held.

The patch of course looks good, but the comment is misleading.

	Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/