linux-kernel - Re: [GIT PULL v2] Preparation for BKL'ed ioctl removal

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:	Sun, 25 Apr 2010 19:39:15 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Arnd Bergmann <arnd@...db.de>, LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Al Viro <viro@...iv.linux.org.uk>,
	Jan Blunck <jblunck@...e.de>, Ingo Molnar <mingo@...e.hu>,
	John Kacur <jkacur@...hat.com>
Subject: Re: [GIT PULL v2] Preparation for BKL'ed ioctl removal

On Sat, Apr 24, 2010 at 03:15:23PM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 24 Apr 2010, Arnd Bergmann wrote:
> > 
> > With CONFIG_BKL disabled, we gain a few cyles in the scheduler,
> 
> That has _nothing_ to do with the ioctl's though.
> 
> Stop mixing things up.
> 
> There are two totally independent issues:
> 
>  - making the BKL ioctl's be explicit and findable
> 
>  - eventually getting rid of the BKL entirely
> 
> and I think you guys are totally mixing things up, and making things WORSE 
> in the process.
> 
> The notion of having _three_ different "ioctl()" function pointers just 
> makes me want to gag. And there is absolutely _zero_ reason for it. Tjhere 
> is no way in hell that we want to have every subsystem maintainer try to 
> independently do their own ioctl's. Most of the drivers that have those 
> things are basically unmaintained or on the back burner anyway.
> 
> So don't make the current ugly ioctl situation worse. Not even as a 
> stop-gap, because there is absolutely _zero_ upside to making yet another 
> new crazy temporary ioctl interface.

Our final goal was not to have three different ioctl interfaces. This state was
only deemed to be temporary. This was the only way to make the change
smoother and don't conflict with other trees with a single monolithic patch.

But if you are ok with a single one, then we are going this way and we'll send it for
the next merge window.

> And don't try to conflate the issue of ioctl and BKL. There are still 
> code-paths that do lock_kernel() without the ioctl's, so the whole ioctl 
> renaming has _zero_ to do with CONFIG_BKL.

It's true, but once it gets pushed down/dropped from every core parts (which
is what we are working on currently in parallel), lock_kernel() and .bkl_ioctl
is only going to be used by unmaintained drivers. This is the time where having
a CONFIG_BKL is going to make sense. And it won't be a question of saving some
bytes but improve efficiency of schedule() for those who don't need such old or
unmaintained drivers.

May be we should only start to focus on this new config once this state is reached.

And to prepare for that, are you ok with this scheme of:

-	.ioctl = foo,
+	.unlocked_ioctl = bkl_ioctl,
+	.bkl_ioctl	= foo,

...done at the same time as the big rename patch.
This will prepare to remove the bkl from vfs and build it conditionally
from the bkl lib, once the bkl is out the core?

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