From: Christoph Hellwig <hch@ns.caldera.de>
To: <Oliver.Neukum@lrz.uni-muenchen.de>
Cc: Horst von Brand <vonbrand@inf.utfsm.cl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Rick Lindsley <ricklind@us.ibm.com>
Subject: Re: [PATCH] Remove needless BKL from release functions
Date: Fri, 23 Nov 2001 11:47:10 +0100 [thread overview]
Message-ID: <200111231047.fANAlA105874@ns.caldera.de> (raw)
In-Reply-To: <Pine.SOL.4.33.0111231106530.7403-100000@sun3.lrz-muenchen.de>
In article <Pine.SOL.4.33.0111231106530.7403-100000@sun3.lrz-muenchen.de> you wrote:
> While this is doubtlessly true, please don't do things like removing the
> lock from interfaces like the call to open() in the input subsystem.
> People may depend on the lock being held there. Having open() under BKL
> simplifies writing USB device drivers.
Beeing completly single-threaded also simplifies writing unclean drivers..
BTW, I've attached a patch that fixes the largest input races (against 2.4.6),
I don't see how to change the total lack of locking for other data structures
without an API change, though.
Christoph
--
Whip me. Beat me. Make me maintain AIX.
--- linux-2.4.6/drivers/input/input.c Mon Jun 4 21:17:55 2001
+++ linux/drivers/input/input.c Sun Jul 8 22:58:10 2001
@@ -57,6 +57,7 @@
static devfs_handle_t input_devfs_handle;
static int input_number;
static long input_devices[NBITS(INPUT_DEVICES)];
+static DECLARE_MUTEX(input_lock);
void input_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
{
@@ -222,6 +223,8 @@
struct input_handler *handler = input_handler;
struct input_handle *handle;
+ down(&input_lock);
+
/*
* Initialize repeat timer to default values.
*/
@@ -257,6 +260,8 @@
input_link_handle(handle);
handler = handler->next;
}
+
+ up(&input_lock);
}
void input_unregister_device(struct input_dev *dev)
@@ -265,6 +270,8 @@
struct input_dev **devptr = &input_dev;
struct input_handle *dnext;
+ down(&input_lock);
+
/*
* Kill any pending repeat timers.
*/
@@ -294,6 +301,8 @@
if (dev->number < INPUT_DEVICES)
clear_bit(dev->number, input_devices);
+
+ up(&input_lock);
}
void input_register_handler(struct input_handler *handler)
@@ -301,6 +310,8 @@
struct input_dev *dev = input_dev;
struct input_handle *handle;
+ down(&input_lock);
+
/*
* Add minors if needed.
*/
@@ -324,6 +335,8 @@
input_link_handle(handle);
dev = dev->next;
}
+
+ up(&input_lock);
}
void input_unregister_handler(struct input_handler *handler)
@@ -332,6 +345,8 @@
struct input_handle *handle = handler->handle;
struct input_handle *hnext;
+ down(&input_lock);
+
/*
* Tell the handler to disconnect from all devices it keeps open.
*/
@@ -358,38 +373,60 @@
if (handler->fops != NULL)
input_table[handler->minor >> 5] = NULL;
+
+ up(&input_lock);
}
static int input_open_file(struct inode *inode, struct file *file)
{
- struct input_handler *handler = input_table[MINOR(inode->i_rdev) >> 5];
struct file_operations *old_fops, *new_fops = NULL;
+ struct input_handler *handler;
+ unsigned int minor = MINOR(inode->i_rdev), index;
int err;
- /* No load-on-demand here? */
- if (!handler || !(new_fops = fops_get(handler->fops)))
+ if (minor >= INPUT_DEVICES)
return -ENODEV;
- /*
- * That's _really_ odd. Usually NULL ->open means "nothing special",
- * not "no device". Oh, well...
- */
- if (!new_fops->open) {
- fops_put(new_fops);
- return -ENODEV;
+ down(&input_lock);
+ index = minor >> 5;
+ handler = input_table[index];
+
+ if (handler)
+ new_fops = fops_get(handler->fops);
+ if (!new_fops) {
+ char modname[32];
+
+ up(&input_lock);
+ sprintf(modname, "input-handler-%d", index);
+ request_module(modname);
+ down(&input_lock);
+
+ err = -ENODEV;
+ handler = input_table[index];
+ if (!handler)
+ goto end;
+ if (!(new_fops = fops_get(handler->fops)))
+ goto end;
}
+
old_fops = file->f_op;
file->f_op = new_fops;
- lock_kernel();
- err = new_fops->open(inode, file);
- unlock_kernel();
+ if (new_fops->open) {
+ lock_kernel();
+ err = new_fops->open(inode, file);
+ unlock_kernel();
+ } else
+ err = 0;
if (err) {
fops_put(file->f_op);
file->f_op = fops_get(old_fops);
}
+
fops_put(old_fops);
+end:
+ up(&input_lock);
return err;
}
next prev parent reply other threads:[~2001-11-23 10:47 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-11-21 23:32 David C. Hansen
2001-11-22 10:12 ` Oliver Neukum
2001-11-22 12:11 ` Christoph Hellwig
2001-11-22 12:30 ` Horst von Brand
2001-11-22 13:05 ` Christoph Hellwig
2001-11-23 9:44 ` Rick Lindsley
2001-11-23 10:10 ` Oliver.Neukum
2001-11-23 10:47 ` Christoph Hellwig [this message]
2001-11-23 11:24 ` Oliver Neukum
2001-11-26 17:46 ` David C. Hansen
2001-11-26 19:41 ` Flavio Stanchina
2001-11-26 19:53 ` David C. Hansen
2001-11-23 12:08 ` Rick Lindsley
-- strict thread matches above, loose matches on Subject: below --
2001-11-06 20:04 [PATCH] lp.c, eexpress.c jiffies cleanup Tim Schmielau
2001-11-06 21:15 ` Andreas Dilger
2001-11-06 21:37 ` Philip Blundell
2001-11-07 0:10 ` Andreas Dilger
2001-11-06 23:58 ` Tim Hockin
2001-09-20 20:07 XFS to main kernel source Gonyou, Austin
2001-09-20 20:14 ` Alan Cox
2001-09-20 20:16 ` Steve Lord
2001-09-20 20:25 ` Alan Cox
2001-09-20 20:26 ` Christoph Hellwig
2001-09-20 21:31 ` Steve Lord
2001-09-21 3:12 ` Andreas Dilger
2001-09-21 3:25 ` Steve Lord
2001-09-21 4:42 ` Nathan Scott
2001-09-21 5:58 ` Christoph Hellwig
2001-09-21 8:40 ` Narancs v1
2001-09-21 14:19 ` Alexander Viro
2001-09-21 14:45 ` Steve Lord
2001-09-20 20:40 ` Alexander Viro
2001-09-21 18:03 ` Steve Lord
2001-09-20 20:29 ` Horst von Brand
2001-09-20 20:50 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200111231047.fANAlA105874@ns.caldera.de \
--to=hch@ns.caldera.de \
--cc=Oliver.Neukum@lrz.uni-muenchen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ricklind@us.ibm.com \
--cc=vonbrand@inf.utfsm.cl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®