On Thu, 2019-06-06 at 10:26 -0700, Bart Van Assche wrote: > On 6/5/19 10:46 PM, Hannes Reinecke wrote: > > Why not simply '-EPERM' ? > > > Translating a state into something else seems counterproductive. > > Personally I'm OK with returning -EPERM for attempts from user space > to > change the device state into SDEV_BLOCK. The state translation is > something that was proposed about two months ago (see also > https://www.mail-archive.com/linux-scsi@xxxxxxxxxxxxxxx/msg82610.html > ). > > > And, while we're at it: > > The only meaningful states to be set from userspace are 'RUNNING', > > 'OFFLINE', and 'BLOCK'. > > Everything else relates to the internal state machine and really > > shouldn't be touched from userspace at all. > > So I'd rather filter out everything _but_ the three states, avoid > > similar issue in the future. > > Can you please clarify why you think it is useful to change the SCSI > device state from user space into SDEV_BLOCK? As one can see in > scsi_device_set_state() transitions from SDEV_BLOCK into the > following > states are allowed: SDEV_RUNNING, SDEV_OFFLINE, > SDEV_TRANSPORT_OFFLINE > and SDEV_DEL. The mpt3sas driver and also the FC, iSCSI and SRP > transport drivers all can call scsi_internal_device_unblock_nowait() > or > scsi_target_unblock(). So at least for this LLD and these transport > drivers if the device state is set to SDEV_BLOCK from user space > that > change can be overridden any time by kernel code. So I'm not sure it > is > useful to change the device state into SDEV_BLOCK from user space. > > Bart. I have never used block (SDEV_BLOCK) from userspace, only ever running and offline I did not even know that was a possibility. What would that be possibly used for. Regards Laurence
