From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mike Snitzer <snitzer@redhat.com>
Subject: Re: v4.3-rc2 dm-mq bug
Date: Fri, 25 Sep 2015 14:49:40 -0400
Message-ID: <20150925184940.GA22799@redhat.com>
References: <56044A6E.90900@sandisk.com> <20150924211804.GA16328@redhat.com>
	<56046AD7.7080400@sandisk.com> <20150924230103.GA17394@redhat.com>
	<56056997.2000001@sandisk.com>
Reply-To: device-mapper development <dm-devel@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <dm-devel-bounces@redhat.com>
Content-Disposition: inline
In-Reply-To: <56056997.2000001@sandisk.com>
List-Unsubscribe: <https://www.redhat.com/mailman/options/dm-devel>,
	<mailto:dm-devel-request@redhat.com?subject=unsubscribe>
List-Archive: <https://www.redhat.com/archives/dm-devel>
List-Post: <mailto:dm-devel@redhat.com>
List-Help: <mailto:dm-devel-request@redhat.com?subject=help>
List-Subscribe: <https://www.redhat.com/mailman/listinfo/dm-devel>,
	<mailto:dm-devel-request@redhat.com?subject=subscribe>
Sender: dm-devel-bounces@redhat.com
Errors-To: dm-devel-bounces@redhat.com
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>, device-mapper development <dm-devel@redhat.com>
List-Id: dm-devel.ids

On Fri, Sep 25 2015 at 11:34am -0400,
Bart Van Assche <bart.vanassche@sandisk.com> wrote:

> On 09/24/2015 04:01 PM, Mike Snitzer wrote:
> >I'm not referring to the removal of a DM mpath device's underlying SRP
> >paths.  The __dm_destroy() path is only used when destroying a DM
> >device.  The only DM device used by multipath is the DM mpath device.
> >
> >So somehow your test is running the equivalent of:
> >  dmsetup remove <toplevel_DM_mpath_device>
> >
> >While IO is being issued directly to that device.
> 
> Hello Mike,
> 
> One of the steps in my test is to remove all dm devices that have
> been created on top of SRP paths. The call trace at the start of
> this thread was triggered by the following command (unloading the
> SRP initiator is only possible after all holders of SRP paths have
> been removed):
> 
> for p in /sys/class/srp_remote_ports/*; do echo 1 >$p/delete & done;
> wait; dmsetup remove_all; modprobe -r ib_srp
> 
> The I/O was probably generated by multipathd itself (a path check).

I'd be surprised, the multipathd path checks go direct to the underlying
paths.  But I would also use 'multipath -F' before 'dmsetup remove_all'
in your test sequence -- could be that alone "fixes" the problem.