All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.