On 6/6/19 7:26 PM, 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. > Yes, I agree. So let's restrict userspace to only ever setting 'RUNNING' or 'OFFLINE'. None of the other states make sense to set from userspace. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@xxxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg)
