On 02/11/2015 08:28, Hannes Reinecke wrote: > > With the original code we would need to wait for path activation > before we would be able to figure out if the ioctl is valid. > However, the callback to verify the ioctl is sd_ioctl(), which as > a first step calls scsi_verify_ioctl(). > So my reasoning was that we can as well call scsi_verify_ioctl() > early, and allow it to filter out known invalid ioctls. > Then we wouldn't need to wait for path activation and return > immediately. That in principle makes sense. Unfortunately, before path activation you can only find out if a ioctl is valid. You cannot find out which ioctls are _in_valid, because path activation sets the bdev and that might make all ioctls valid. > Incidentally, in the 'r == -ENOTCONN' case, we're waiting > for path activation, but then just bail out with -ENOTCONN. > As we're not resetting -ENOTCONN, where's the point in activate the > paths here? > Shouldn't we retry to figure out if -ENOTCONN is still true? That makes sense too. You've done the work, might as well reap the benefits... Paolo -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
