On 31/10/2015 19:13, Mike Snitzer wrote: > > But that's wrong, I think. It's a false positive in > > scsi_verify_blk_ioctl(). > > > > If the ioctl is valid when bdev becomes non-NULL (and it will be if > > ti->len becomes equal to i_size_read(bdev->bd_inode) >> SECTOR_SHIFT), > > you should not return -ENOIOCTLCMD aka ENOTTY, because userspace doesn't > > think the ioctls can go away and come back. So Hannes's patch broke the > > userspace ABI. :( > > Huh? All that Hannes' patch did was add early verification of the ioctl > if there are no paths, since: there is no point queueing an ioctl that > is invalid. > > [snip discussion of Christoph's patches] > > The point is scsi_verify_blk_ioctl() is saying the ioctl isn't valid. > It has nothing to do with the existance of a bdev or not; but everything > to do with the unprivledged user's request to issue an ioctl.
... but the call is skipped (and all ioctls are valid) if ti->len == i_size_read(bdev->bd_inode) >> SECTOR_SHIFT. Therefore, until you have the bdev you don't know which ioctls are valid, and you must assume all of them are. You can't do anything unsafe anyway until you have the bdev. This is the reasoning prior to Hannes's change. Afterwards, you end up calling scsi_verify_blk_ioctl() when bdev == NULL. If the future bdev satisfies the above condition on ti->len, this means that ioctl(SG_IO) switches from ENOTTY to available. Userspace is clearly not expecting that. > Paolo, AFAIK unprivledged ioctls is one of your pet-projects so your > insight on what, if anything, needs changing to support them is the > insight I think we need. I hope the above provides some extra information. Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
