linux-kernel - Re: [PATCH] BKL: Remove BKL from isofs

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: <201009201313.11526.arnd@arndb.de>
Date:	Mon, 20 Sep 2010 13:13:11 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Jan Kara <jack@...e.cz>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] BKL: Remove BKL from isofs

On Monday 20 September 2010, Jan Kara wrote:
>   Hmm, looking through the code, I actually don't see a reason
> why we should need any per-sb lock at all. The filesystem is always
> read-only and we don't seem to have any global data structures that
> change. But that needs some testing I guess - I'll try to do that.

Ok, great! The BKL was basically as wrong as the global mutex protecting
the operations anyway, because it does not document what data is
actually getting protected in any of all the drivers that I'm converting
to a private mutex.

Given more time for code inspection and some testing, you can probably
come up with a good explanation why the BKL is not needed in all those
places, but since nobody ever bothered to do this for the last decade
for all these drivers, my approach was to simply prove (in a rather lose
sense) that I can't make it worse by converting to a 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/