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

Hannes Reinecke hare at suse.de
Mon Nov 2 15:29:03 UTC 2015


On 11/02/2015 04:14 PM, Mike Snitzer wrote:
> On Mon, Nov 02 2015 at  9:36am -0500,
> Hannes Reinecke <hare at suse.de> wrote:
[ .. ]
>> From b0d5848e91cfc3b97adb49121085c994b707eac3 Mon Sep 17 00:00:00 2001
>> From: Hannes Reinecke <hare at suse.de>
>> Date: Mon, 2 Nov 2015 15:33:58 +0100
>> Subject: [PATCH] dm-mpath: Retry ioctl if paths need to be initialized
>>
>> If paths need to be initialized (m->queue_io is set) we should
>> be starting the initialization and retry the ioctl to retrieve
>> the final status.
>> At the same time, we should _not_ wait for queue_if_no_path
>> to go away as this might take forever, resulting in the
>> ioctl to be stuck.
> 
> I understand your goal.. but the patch is a bit incomplete.
> 
> In your patch the activation is still in progress; so there is no
> bdev.. so it'll yield false positives still.
> 
Right.

> And DM core has retry via -ENOTCONN.. yet you're adding it to
> multipath_ioctl (meaning nothing will use DM core's retry logic now).
> 
Yeah, I've just noticed.

> Also, you still haven't established what it is about
> scsi_verify_blk_ioctl() that you see as beneficial.  If we return EAGAIN
> to userspace that should "fix" the udev worker issue (so no need for
> extra ioctl verification.. which you're clearly still implicitly
> overloading with the hopes that it is more generally applicable than
> just being concerned about whether an ioctl is valid against a
> partition).
> 
Personally, I would happily drop the call to scsi_verify_blk_ioctl
altogether; it'll be called via sd_ioctl() later on anyway.
And if we don't have valid/accessible paths I'd rather return an
error code indicating that instead of trying to figure out what the
error would be if we would have had a valid path.

If we can agree on that everything would become _so much_ easier...

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare at 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)




More information about the dm-devel mailing list