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.
