linux-kernel - Re: nbd locking problems

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

Message-Id: <201101282230.53148.arnd@arndb.de>
Date:	Fri, 28 Jan 2011 22:30:53 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Soren Hansen <soren@...ux2go.dk>, linux-kernel@...r.kernel.org,
	Dave Hansen <haveblue@...ibm.com>
Subject: Re: nbd locking problems

On Friday 28 January 2011 22:18:26 Serge E. Hallyn wrote:
> As Dave just explained to me, BKL is released when you sleep :)  I
> assume that's how it gets released around the kthread_create().  I
> think you're right that the new mutex is superfluous, but I'd like to
> look through the ioctl code and make sure there's no shared state which
> we need to protect.  I don't see how there could be, or rather, if there
> were, then it was broken before.

Good analysis. The mass-conversion from BKL to per-driver mutex indeed
assumes that no ioctl blocks for an indefinite amount of time, as nbd
evidently does. I think it's quite likely that the nbd driver does not
require any sort of locking to replace the BKL, it certainly seems
to have reasonable locking rules by itself, the ioctl function got
the BKL only because of an earlier push down from the global VFS ioctl
function.

	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/