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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 02 2015 at  9:52am -0500,
Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:

> 
> 
> 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.

Currently, if we don't start path activation we're returning EIO.
ENOTCONN is used for when we do start path activation (and ENOTCONN is
the means for DM core to retry)

We _could_ change the ENOTCONN to be EAGAIN and EIO to ENOTCONN...
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux