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:	Mon, 26 Apr 2010 09:25:41 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>, John Kacur <jkacur@...hat.com>
Subject: Re: [GIT PULL v2] Preparation for BKL'ed ioctl removal


* Frederic Weisbecker <fweisbec@...il.com> wrote:

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

The scheduler will be helped most by getting rid of the BKL altogether. We are 
in reaching distance of that now ...

CONFIG_BKL would really just elongate the migration period, unnecessarily so.

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

Once that state is achived we can just get rid of the BKL and mass-push 
per-driver mutexes into those remaining drivers - in a possibly scripted way. 
Something like:

  foo-driver.c

  DEFINE_MUTEX(foo_mutex);

  foo_ioctl()
  {
	mutex_lock(&foo_mutex);
	...
	mutex_unlock(&foo_mutex);
  }

  foo_open()
  {
	mutex_lock(&foo_mutex);
	...
	mutex_unlock(&foo_mutex);
  }

This could be done all automated for a hundred old drivers if need to be. 
There would be no bkl_ioctl's left.

That, even if it looks somewhat coarse is still better than having _yet 
another_ 'temporary transition'. The Big Kernel Lock was supposed to be 
transitionary to begin with. It's been 10+ years and counting :-)

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