linux-kernel - Re: [PATCH 3/6] fat: BKL ioctl pushdown

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]

Date:	Wed, 5 May 2010 22:16:35 +0200 (CEST)
From:	John Kacur <jkacur@...hat.com>
To:	OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
cc:	lkml <linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH 3/6] fat: BKL ioctl pushdown



On Thu, 6 May 2010, OGAWA Hirofumi wrote:

> John Kacur <jkacur@...hat.com> writes:
> 
> > On Thu, 6 May 2010, OGAWA Hirofumi wrote:
> >
> >> John Kacur <jkacur@...hat.com> writes:
> >> 
> >> > Convert fat_generic_ioctl and fat_dir_ioctl to unlocked_ioctls
> >> > and push down the bkl into those functions.
> >> 
> >> I guess this is the part of batch ioctl conversion stuff though, those
> >> ioctl of FAT don't need BKL at all. Because all of those should already
> >> be protected by inode->i_mutex.
> >> 
> >> Removing BKL and then cleanup after this patch would be almost same with
> >> reverting this patch. So, could you just convert to unlocked_ioctl
> >> instead?
> >
> > That's probably not a good idea, without a little bit more analysis, 
> > otherwise it's quite easy to introduce subtle bugs.
> 
> What analysis? Who do it? I thought about removing BKL of FAT from
> several years ago. I was reviewing FAT multiple times, and I'm always
> testing FAT without BKL.

This patch just makes explicit the hidden BKLs that FAT is already using 
related to ioctl. We would like to get this step done in time for the next
merge window, because then we can remove that hidden source.

This step is preparation for removing the BKL from the individual 
functions we've pushed it down into. In other words, we'll do the analysis 
to remove it later if you don't want to.

Thanks.

> 
> If you are going to do, could you do it instead of this patch?
> 
--
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/