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
| ||
|
Date: Thu, 15 May 2008 10:44:57 +0200 (CEST) From: Jan Engelhardt <jengelh@...ozas.de> To: Jonathan Corbet <corbet@....net> 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 On Wednesday 2008-05-14 23:45, Jonathan Corbet wrote: >Sez Ingo: >1: We could add an unlocked_open() to the file_operations structure; > drivers could be converted over as they are verified not to need the > BKL on open. Disadvantages are that it grows this structure for a > relatively rare case - most open() calls already don't need the BKL. > But it's a relatively easy path without flag days. 1b: add a .locked_open and move all BKL-requiring code to use that. When time comes and BKL is gone, .locked_open can be removed again, and no rename was ever done for BKL-free code. >2: Create a char_dev_ops structure for char devs and use it instead of > file_operations. I vaguely remember seeing Al mutter about that a > while back. Quite a while back. This mirrors what was done with > block devices, and makes some sense - there's a lot of stuff in > struct file_operations which is not really applicable to char devs. > Then struct char_dev_ops could have open() and locked_open(), with > the latter destined for removal sometime around 2015 or so. Iff you create a new char_dev_ops, don't clutter it with the old stuff. BKL-using code could continue using file_operations, would not it? >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 This is the BSD/Solaris tactic, heh :) -- 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/
Powered by blists - more mailing lists