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

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

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

On Mon, Nov 02 2015 at 10:45am -0500, Paolo Bonzini 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

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

On Mon, Nov 02 2015 at 2:28am -0500, Hannes Reinecke wrote: > On 10/31/2015 11:47 PM, Mike Snitzer wrote: > > > > For Hannes, and in my head, it didn't matter if a future bdev satisfies > > the length condition. I don't think Hannes was trying to guard against > > dangerous

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

On Mon, Nov 02 2015 at 9:52am -0500, Paolo Bonzini 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)? > > >

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

On 11/02/2015 04:14 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 9:36am -0500, > Hannes Reinecke wrote: [ .. ] >> From b0d5848e91cfc3b97adb49121085c994b707eac3 Mon Sep 17 00:00:00 2001 >> From: Hannes Reinecke >> Date: Mon, 2 Nov 2015 15:33:58 +0100 >> Subject:

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

On 11/02/2015 02:31 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 2:28am -0500, > Hannes Reinecke wrote: > >> On 10/31/2015 11:47 PM, Mike Snitzer wrote: >>> >>> For Hannes, and in my head, it didn't matter if a future bdev satisfies >>> the length condition. I don't think

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

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

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

On Mon, Nov 02 2015 at 8:56am -0500, Hannes Reinecke wrote: > On 11/02/2015 02:31 PM, Mike Snitzer wrote: > > On Mon, Nov 02 2015 at 2:28am -0500, > > Hannes Reinecke wrote: > > > >> On 10/31/2015 11:47 PM, Mike Snitzer wrote: > >>> > >>> For Hannes, and in my

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

On 11/02/2015 03:12 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 8:56am -0500, > Hannes Reinecke wrote: > >> On 11/02/2015 02:31 PM, Mike Snitzer wrote: >>> On Mon, Nov 02 2015 at 2:28am -0500, >>> Hannes Reinecke wrote: >>> On 10/31/2015 11:47 PM, Mike

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

On 11/02/2015 03:52 PM, Paolo Bonzini 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,

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

On Mon, Nov 02 2015 at 9:36am -0500, Hannes Reinecke wrote: > On 11/02/2015 03:12 PM, Mike Snitzer wrote: > > On Mon, Nov 02 2015 at 8:56am -0500, > > Hannes Reinecke wrote: > > > >> On 11/02/2015 02:31 PM, Mike Snitzer wrote: > >>> On Mon, Nov 02 2015 at 2:28am

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

On 02/11/2015 08:28, Hannes Reinecke wrote: > > With the original code we would need to wait for path activation > before we would be able to figure out if the ioctl is valid. > However, the callback to verify the ioctl is sd_ioctl(), which as > a first step calls scsi_verify_ioctl(). > So my

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

On 31/10/2015 23:47, Mike Snitzer wrote: > Yes, with your commit ec8013be ("dm: do not forward ioctls from logical > volumes to the underlying device") you added protections to disallow > issuing ioctls to a partition that could impact the rest of the device. > > Given that I can see why you're

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

On 10/31/2015 11:47 PM, Mike Snitzer wrote: > On Sat, Oct 31 2015 at 3:07pm -0400, > Paolo Bonzini wrote: > >> >> >> On 31/10/2015 19:13, Mike Snitzer wrote: But that's wrong, I think. It's a false positive in scsi_verify_blk_ioctl(). If the ioctl is

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

On Sat, Oct 31 2015 at 11:33am -0400, Paolo Bonzini wrote: > > > On 29/10/2015 14:18, Mike Snitzer wrote: > > > 4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285); > > >it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl(). > > > > > >

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

On Sat, Oct 31 2015 at 2:13P -0400, Mike Snitzer wrote: > On Sat, Oct 31 2015 at 11:33am -0400, > Paolo Bonzini wrote: > > > > > > > On 29/10/2015 14:18, Mike Snitzer wrote: > > > > 4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO

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

On 31/10/2015 19:13, Mike Snitzer wrote: > > But that's wrong, I think. It's a false positive in > > scsi_verify_blk_ioctl(). > > > > If the ioctl is valid when bdev becomes non-NULL (and it will be if > > ti->len becomes equal to i_size_read(bdev->bd_inode) >> SECTOR_SHIFT), > > you should

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

On 29/10/2015 14:18, Mike Snitzer wrote: > > 4) dmesg shows that scsi_verify_blk_ioctl() failed for SG_IO (0x2285); > >it returns -ENOIOCTLCMD, later replaced with -ENOTTY in vfs_ioctl(). > > > > $ dmesg > > <...> > > [] device-mapper: multipath: Failing path 65:144. > > []

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

On Sat, Oct 31 2015 at 3:07pm -0400, Paolo Bonzini wrote: > > > On 31/10/2015 19:13, Mike Snitzer wrote: > > > But that's wrong, I think. It's a false positive in > > > scsi_verify_blk_ioctl(). > > > > > > If the ioctl is valid when bdev becomes non-NULL (and it will be

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

On Thu, Oct 29 2015 at 8:24am -0400, Mauricio Faria de Oliveira wrote: > This reverts commit a1989b330093578ea5470bea0a00f940c444c466. > > That commit introduced a regression at least for the case of the SG_IO ioctl() > running without CAP_SYS_RAWIO capability

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

Hi Mike, On 10/29/2015 11:18 AM, Mike Snitzer wrote: Sorry but I fail to see why your request to revert is viable. No problem. Thanks for moving this for a discussion on a proper fix. I'm somewhat new to kernel and SCSI workings and its community process, so that's certainly appreciated.