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 13:29:28 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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

On Monday 26 April 2010, Ingo Molnar wrote:
> This could be done all automated for a hundred old drivers if need to be. 
> There would be no bkl_ioctl's left.

I don't think it can be fully automated. For the majority of the modules,
your approach would work fine, but there are still the well-known
pitfalls in corner cases:

- recursive uses in functions outside of ioctl (possibly none left
  after the TTY layer is done, but who knows)
- lock-order problems with other mutexes (see DRM)
- code that depends on autorelease to allow one ioctl while another
  is sleeping. (a small number of drivers)

Semi-automated should be fine though. These rules are relatively
easy to check, so we can mass-convert all the trivial cases.

Examples for nontrivial modules are mostly file systems, see ncpfs,
afs, hpfs, ...

> 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 :-)

I think the immediate goal should be to get the BKL out of everthing
that's either used by real people or that's reasonably easy to do.
We have patches for almost all of these now [1], and I've been running
a kernel with CONFIG_BKL=n for a few weeks now. As we progress
through the remaining modules, an increasing number of systems can
run without this.

I see the next steps as:
1. make it possible to build a kernel without BKL, by removing the BKL
   from all core components for good, and making all users depend on
   CONFIG_BKL. Make it default y and put it under CONFIG_DEBUG.

2. Remove the BKL from all modules that are either easy to convert
   to a private mutex or that are relevant to real users (e.g.
   definitely DRM, but maybe not hpfs).

3. Change CONFIG_BKL to "default n, depends on DEPRECATED"

4. Remove the remaining modules that nobody knows how to fix
   or cares about. Possibly the number of modules here is close
   to zero.

5. Remove the implementation of the BKL, since no users are left.

Getting stage 1 done for 2.6.36 or even 2.6.35 should be possible but
still needs a lot of work. I think we should focus on that for now
and then see how much is left to do for the other stages.

This is still a temporary transition, but since we can't do all at
once, I don't see better way.

	Arnd

[1] http://kernelnewbies.org/BigKernelLock
--
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/