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 EIO.
> > ENOTCONN is
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
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, s
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: [PATCH] dm-mpath: Retry ioctl
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 -0500,
> >>> Hannes Reinecke
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)?
> >
> > Should we start path
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 ude
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 Snitzer wrote:
>
> For
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 head, it didn't matter if a futu
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 Hannes was trying
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 partition ioctls be
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
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
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 valid when bdev becomes
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 if
> > > ti->len beco
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 not
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 (0x2285);
> > > >it returns -ENOIOCTLCMD, lat
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().
> > >
> > > $ dmesg
> > >
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.
> > [] d
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.
Wo
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 (e.g., unprivileged users) when th
21 matches
Mail list logo