On Thu 08-03-12 11:04:21, NeilBrown wrote: > On Mon, 05 Mar 2012 21:29:59 -0800 "H. Peter Anvin" <hpa@xxxxxxxxx> wrote: > > > On 03/05/2012 06:27 PM, NeilBrown wrote: > > > > > > So it is still called fsync_bdev and invalidate_bdev as long as the > > > ioctl function for the underlying disk returns -EINVAL or -ENOTTY. > > > > > > The function that shows that warning is scsi_verify_blk_ioctl in > > > block/scsi_ioctl.c The worst it can do is return -ENOTTY, and that > > > is safe. > > > > > > So the warning is bogus, the code still works. > > > > > > > We should whitelist ioctls if they are legitimately used and harmless. > > Do we have a specific list? > > > > -hpa > > > > > > We had the following in our SLES kernel for a while, though it seems it > disappeared when we pulled in 3.0.18. > Jan: should we put this stuff back? Yeah, we should. I think it was removed by accident - partly because the patch doing the change was tagged as in mainline but it actually differed from mainline slightly. Honza > @@ -78,11 +83,19 @@ Index: linux-3.0-SLE11-SP2/block/scsi_ioctl.c > + case SG_GET_RESERVED_SIZE: > + case SG_SET_RESERVED_SIZE: > + case SG_EMULATED_HOST: > ++ case BLKFLSBUF: > ++ case BLKROSET: > + return 0; > + case CDROM_GET_CAPABILITY: > -+ /* Keep this until we remove the printk below. udev sends it > -+ * and we do not want to spam dmesg about it. CD-ROMs do > -+ * not have partitions, so we get here only for disks. > ++ case CDROM_DRIVE_STATUS: > ++ case FDGETPRM: > ++ case RAID_VERSION: > ++ case MTIOCGET: > ++#ifdef CONFIG_COMPAT > ++ case 0x801c6d02: /* MTIOCGET32 */ > ++#endif > ++ /* Keep this until we remove the printk below. udev/dd sends > ++ * these and we do not want to spam dmesg about it. CD-ROMs > ++ * & tapes do not have partitions, so we get here only for > ++ * disks. > + */ > + return -ENOTTY; > + default: > -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
