linux-kernel - Re: [announce] "kill the Big Kernel Lock (BKL)" tree

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: <87bq387cyn.fsf@basil.nowhere.org>
Date:	Thu, 15 May 2008 00:11:44 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	corbet@....net (Jonathan Corbet)
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Alexander Viro <viro@....linux.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [announce] "kill the Big Kernel Lock (BKL)" tree

corbet@....net (Jonathan Corbet) writes:
>
> 3: Provide a new form of cdev_add() which lets the driver indicate
>    that the BKL is not needed on open (or anything else?).  At a
>    minimum, it could just be a new parameter on cdev_add which has a
>    value of zero or FIXME_I_STILL_NEED_BKL.  Still some churn but easier
>    to script and smaller because a lot of drivers are still using
>    register_chrdev() - something else worth fixing.
>
>    A more involved form might provide a new chardev_add() which takes
>    the new char_dev_ops structure too.  Mapping between new and old
>    operations vectors would be done internally to avoid breaking older
>    drivers before they can be fixed.
>
> 4: Just find every char dev open() function and shove in lock_kernel()
>    calls, then remove the call from chrdev_open().  The disadvantage
>    here is that, beyond lots of work and churn, there's no way to know
>    which ones you missed.

In general when changing semantics drastically you should force
compile errors by renaming the respective entry point. That
has been the standard Linux method for this for years.

I've been also pondering a variant of 1, but 3 might be better.

> I kind of like the combination of 2 and 3, done in such a way that
> there's no "every driver must change" flag day.  This could be an
> interesting project, even...  Thoughts?

I doubt it will be very interesting, but it would be useful.
The goal less being to get rid of BKL in old drivers, but not 
requiring BKL in new drivers. Basically all BKL assumptions
in interfaces really should go.

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