From 78ae87c3cd723c8a8dcd67d4e4cbc6d63671c108 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Sun, 3 Jun 2007 13:50:41 -0700 Subject: [PATCH] vanishing ioctl handler debugging We've had several reoprts of the CPU jumping to 0x00000000 is do_ioctl(). I assume that there's a race and someone is zeroing out the ioctl handler while this CPU waits for the lock_kernel(). The patch adds code to detect this, then emits stuff which will hopefuly lead us to the culprit. Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- fs/ioctl.c | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/fs/ioctl.c b/fs/ioctl.c index 479c1038ed4..8c90cbc903f 100644 --- a/fs/ioctl.c +++ b/fs/ioctl.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include @@ -20,6 +21,7 @@ static long do_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) { int error = -ENOTTY; + void *f; if (!filp->f_op) goto out; @@ -29,10 +31,16 @@ static long do_ioctl(struct file *filp, unsigned int cmd, if (error == -ENOIOCTLCMD) error = -EINVAL; goto out; - } else if (filp->f_op->ioctl) { + } else if ((f = filp->f_op->ioctl)) { lock_kernel(); - error = filp->f_op->ioctl(filp->f_path.dentry->d_inode, - filp, cmd, arg); + if (!filp->f_op->ioctl) { + printk("%s: ioctl %p disappeared\n", __FUNCTION__, f); + print_symbol("symbol: %s\n", (unsigned long)f); + dump_stack(); + } else { + error = filp->f_op->ioctl(filp->f_path.dentry->d_inode, + filp, cmd, arg); + } unlock_kernel(); } -- 2.34.1