Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

[Hannes Reinecke <hare@suse.de>]

On 11/02/2015 03:52 PM, Paolo Bonzini wrote:
> 
> 
> On 02/11/2015 14:56, Hannes Reinecke wrote:
>> But then the real question remains:
>>
>> What is the 'correct' behaviour for ioctls when no path retry
>> is active (or when no paths are present)?
>>
>> Should we start path activation?
>> If so, should we wait for path activation to finish, risking udev
>> killing the worker for that event (udev has a built-in timeout of
>> 120 seconds, which we might easily exceed when we need to activate
>> paths for large installations or slow path activation ... just
>> thinking of NetApp takeover/giveback cycle)?
>> If we're not waiting for path activation, where would be the point
>> in starting it, seeing that we're not actually interested in the result?
>> And if we shouldn't start a path activation, what is the point of
>> having code for it in the first place?
> 
> That's a fair question, and it depends on what said udev worker actually
> does.
> 
Point is, we have no idea whatsoever what udev might be doing.

And experience shows that while most admins/distros etc have a fair
knowledge of writing valid udev rules, more often than not the
'queue_if_no_path' feature from multipath totally escapes them.
So we will be finding ourselves in positions where programs from
udev rules issue ioctls to devices where queue_if_no_path is active.

Plus it's a really daunting task to validate all udev rules to check
if any of those programs might issue ioctls and blank them out for
the queue_if_no_path case.
I did a review once for SUSE, but even that might be obsoleted now
as rules are being changed all the time.

> In any case, if we don't start path activation we should return
> ENOTCONN, not ENOTTY.
> 
No problem with that.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare@suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html