On 11/02/2015 04:14 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 9:36am -0500, > Hannes Reinecke <hare@xxxxxxx> wrote: [ .. ] >> From b0d5848e91cfc3b97adb49121085c994b707eac3 Mon Sep 17 00:00:00 2001 >> From: Hannes Reinecke <hare@xxxxxxx> >> 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@xxxxxxx +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) -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
