linux-kernel - Re: [Bugme-new] [Bug 29172] New: releasing loop on top of other loop leads to deadlock

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

Message-Id: <201102180916.42494.arnd@arndb.de>
Date:	Fri, 18 Feb 2011 09:16:42 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Maciej Rutecki <maciej.rutecki@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [Bugme-new] [Bug 29172] New: releasing loop on top of other loop leads to deadlock

On Thursday 17 February 2011, Andrew Morton wrote:
> On Tue, 15 Feb 2011 10:00:57 GMT
> bugzilla-daemon@...zilla.kernel.org wrote:
> 
> > https://bugzilla.kernel.org/show_bug.cgi?id=29172
> 
> post-2.6.37 deadlock in loop.  I'd agree with the reporter that Arnd might be involved ;)

Yes, sounds right, we should fix it and get the fix into stable.

This comes from an automated conversion that was done under the assumption that
it cannot break from making the locking stricter. A related bug happened in the
nbd driver, and I think the solution here should also be to remove the new
mutex. Upon closer review of the code, I cannot see any reason why it would
actually be needed: there is no global data to be protected and all device
specific data is protected by another mutex.

	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/