linux-kernel - Re: Remove BKL from FAT/VFAT/MSDOS (v1) (was Re: Fw: Regression caused by bf726e "semaphore: fix,")

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: <alpine.LFD.1.10.0805161552510.3020@woody.linux-foundation.org>
Date:	Fri, 16 May 2008 15:58:22 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Remove BKL from FAT/VFAT/MSDOS (v1) (was Re: Fw: Regression
 caused by bf726e "semaphore: fix,")

On Fri, 16 May 2008, Linus Torvalds wrote:
>
> 				[...] but I do think this is at 
> least an interesting starting point, and it's at least not "totally 
> obviously broken".

To clarify: lock_super() is actually a much *stronger* lock than 
lock_kernel(), which is why testing is actually interesting: the locking 
hasn't been weakened, it's actually become much stricter (because unlike 
the kernel lock, the superblock lock is kept over scheduling events, and 
doesn't silently nest).

So the most likely failure case is not that some locking went away and 
you'd race on the data structures, it's that something deadlocks on itself 
if the locking isn't right.

There could be some implicit kernel lock I missed (ie something that acts 
like the "ioctl" callback I already mentioned), of course, so I'm not 
going to swear myself blue in the face that there isn't a new race, but on 
the whole this patch should be pretty safe from the angle that at least 
the obvious locking bugs should cause deadlocks, not race conditions.

And if you enable lockdep, the deadlocks aren't silent deaths, but clear 
"this is where you took it, and here is where you deadlocked due to 
nesting" reports in dmesg. So this should be eminently debuggable even by 
almost total newbies that are just interested in BKL removal.

		Linus
--
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/