linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Hannes Reinecke <hare@suse.de>, Mike Snitzer <snitzer@redhat.com>
Cc: 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, 2 Nov 2015 15:52:41 +0100	[thread overview]
Message-ID: <563778B9.7060900@redhat.com> (raw)
In-Reply-To: <56376B8C.5010001@suse.de>



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.

In any case, if we don't start path activation we should return
ENOTCONN, not ENOTTY.

Paolo

  parent reply	other threads:[~2015-11-02 14:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1446121463-17828-1-git-send-email-mauricfo@linux.vnet.ibm.com>
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
2015-11-02 14:52                 ` Paolo Bonzini [this message]
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=563778B9.7060900@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=dm-devel@redhat.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mauricfo@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).