From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: dm mpath: Fix a dm_blk_ioctl() deadlock Date: Tue, 28 Jun 2016 14:59:14 -0400 Message-ID: <20160628185913.GA8185@redhat.com> References: <20160628181526.GA8013@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Bart Van Assche Cc: device-mapper development List-Id: dm-devel.ids On Tue, Jun 28 2016 at 2:29pm -0400, Bart Van Assche wrote: > On 06/28/2016 08:15 PM, Mike Snitzer wrote: > > This patch doesn't make sense. > > > > In the context of dm-mpath.c:multipath_prepare_ioctl, *bdev is only > > valid if r == 0. But r == -ENOTCONN so how can *bdev be valid? > > Sorry but the dm code is not my area of expertise. How about the patch > below? Please note that so far only the queue-length path selector has > been tested. Can we go back to what it is you've experienced? is it that you have 'queue_if_no_path' enabled and are issuing ioctls to an mpath device (while removing underlying paths) you'll experience a live-lock (_not_ deadlock) once no valid paths exist? If that isn't what you're hitting then I'd like to better understand how a request_queue that is "dying" isn't able to keep itself up enough to fail IO issued to it (to allow normal error handling to trap the IO failure). Mike