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 10:45am -0500,
Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote:

> 
> 
> On 02/11/2015 16:05, Mike Snitzer wrote:
> > > 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...
> 
> This makes sense... though of course testing the impact of this on
> userspace is going to be hard. :(  Chances are that userspace is not
> expecting EAGAIN either.
> 
> Even if they did, how would someone know that they can now retry the
> ioctl after getting EAGAIN?  Should they just do it in a loop?

Turns out multipath (userspace) has a udev rule for this now (prajnoha
pointed this out):
http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=multipath/11-dm-mpath.rules

So now I'm wondering if we _need_ to do any retries in kernel (aside
from while activation is active)?

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel



[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux