On Friday 23 May 2008, Alan Cox wrote: > --- a/drivers/char/raw.c > +++ b/drivers/char/raw.c > @@ -116,13 +116,15 @@ static int raw_release(struct inode *inode, struct file *filp) > /* > * Forward ioctls to the underlying block device. > */ > -static int > -raw_ioctl(struct inode *inode, struct file *filp, > - unsigned int command, unsigned long arg) > +static long raw_ioctl(struct file *filp, unsigned int command, > + unsigned long arg) > { > + long ret; > struct block_device *bdev = filp->private_data; > - > - return blkdev_ioctl(bdev->bd_inode, NULL, command, arg); > + lock_kernel(); > + ret = blkdev_ioctl(bdev->bd_inode, NULL, command, arg); > + unlock_kernel(); > + return ret; > } > > static void bind_device(struct raw_config_request *rq) blkdev_ioctl and compat_blkdev_ioctl are converted already (they take the BKL in all places of doubt), so you can call these directly without calling lock_kernel() again. However, reading through that code again, I noticed two nastybits: * there is no compat_raw_ioctl function, so any user space program trying 32 bit block ioctl calls on a raw device has been broken ever since my patch that moved the block compat_ioctl handlers into the block/compat_ioctl.c file. The same problem seems to exist on pktcdvd.c. * If any block driver had implemented unlocked_ioctl, it would be even worse: The raw driver passes filp->private_data->bd_inode as the inode and NULL as the file. blkdev_ioctl drops the inode argument when calling into a driver and only passes filp, so if a driver then tries to access filp->f_mapping->host, it gets a NULL pointer dereference. Fortunately, no block driver to date implements unlocked_ioctl, and compat_ioctl was protected from this bug by the missing compat_raw_ioctl. I suppose the right fix for this will be to make the blkdev unlocked_ioctl and compat_ioctl take a bdev argument instead of file and inode. Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html