Linux Device Mapper development
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: Mike Snitzer <snitzer@redhat.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	hch@lst.de,
	Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>,
	dm-devel@redhat.com, linux-scsi@vger.kernel.org
Subject: Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]
Date: Mon, 02 Nov 2015 16:29:03 +0100	[thread overview]
Message-ID: <5637813F.7070401@suse.de> (raw)
In-Reply-To: <20151102151446.GB23665@redhat.com>

On 11/02/2015 04:14 PM, Mike Snitzer wrote:
> On Mon, Nov 02 2015 at  9:36am -0500,
> Hannes Reinecke <hare@suse.de> wrote:
[ .. ]
>> From b0d5848e91cfc3b97adb49121085c994b707eac3 Mon Sep 17 00:00:00 2001
>> From: Hannes Reinecke <hare@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@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

  reply	other threads:[~2015-11-02 15:29 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29 12:24 [PATCH] Revert "dm mpath: fix stalls when handling invalid ioctls" Mauricio Faria de Oliveira
2015-10-29 12:33 ` Mauricio Faria de Oliveira
2015-10-29 13:18 ` IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"] Mike Snitzer
2015-10-29 14:47   ` [dm-devel] " Mauricio Faria de Oliveira
2015-10-31 15:33   ` Paolo Bonzini
2015-10-31 18:13     ` Mike Snitzer
2015-10-31 18:36       ` Mike Snitzer
2015-10-31 19:07       ` Paolo Bonzini
2015-10-31 22:47         ` Mike Snitzer
2015-11-02  7:28           ` Hannes Reinecke
2015-11-02  9:57             ` Paolo Bonzini
2015-11-02 13:31             ` Mike Snitzer
2015-11-02 13:56               ` Hannes Reinecke
2015-11-02 14:12                 ` Mike Snitzer
2015-11-02 14:36                   ` Hannes Reinecke
2015-11-02 15:14                     ` Mike Snitzer
2015-11-02 15:29                       ` Hannes Reinecke [this message]
2015-11-02 14:52                 ` Paolo Bonzini
2015-11-02 15:05                   ` Mike Snitzer
2015-11-02 15:45                     ` Paolo Bonzini
2015-11-02 15:49                       ` Mike Snitzer
2015-11-02 15:32                   ` Hannes Reinecke
2015-11-02  9:55           ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5637813F.7070401@suse.de \
    --to=hare@suse.de \
    --cc=dm-devel@redhat.com \
    --cc=hch@lst.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mauricfo@linux.vnet.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=snitzer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox