From: Andrew Morton Date: Sun, 3 Jun 2007 20:50:41 +0000 (-0700) Subject: vanishing ioctl handler debugging X-Git-Tag: v2.6.22-rc4~7 X-Git-Url: https://err.no/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=78ae87c3cd723c8a8dcd67d4e4cbc6d63671c108;p=linux-2.6 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 --- diff --git a/fs/ioctl.c b/fs/ioctl.c index 479c1038ed..8c90cbc903 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(); }