All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: device-mapper development <dm-devel@redhat.com>
Subject: Re: dm mpath: Fix a dm_blk_ioctl() deadlock
Date: Tue, 28 Jun 2016 15:33:03 -0400	[thread overview]
Message-ID: <20160628193302.GB8300@redhat.com> (raw)
In-Reply-To: <873d69e4-f668-b0f0-0e87-3e2cf9b92fca@sandisk.com>

On Tue, Jun 28 2016 at  3:16pm -0400,
Bart Van Assche <bart.vanassche@sandisk.com> wrote:

> On 06/28/2016 08:59 PM, Mike Snitzer wrote:
> >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).
> 
> Hello Mike,
> 
> Since I started testing kernel v4.7-rc<n> I noticed about twenty
> times that systemd-udevd got stuck in truncate_inode_pages(). I have
> not yet seen this with any older kernel version. queue_if_no_path is
> indeed enabled in my tests. The test I run consists of running fio
> on top of an mpath device and repeatedly removing and restoring the
> underlying devices. The test script is available at
> https://github.com/bvanassche/srp-test/blob/master/tests/02. Please
> let me know if you need more information.

I'm not going to be able to setup this test and chase this in the
near-term.  If you want this fixed soon then I'll need you to continue
chasing this.

Something else must be going on.  I fail to see how avoiding dying
queues, like your 2nd path selectors patch does, should be needed.

A dying queue, and the underlying device that is being torn down, still
needs to complete (fail) any of its outstanding IO -- or IO issued to it
e.g. via __blkdev_driver_ioctl -- right?

Could your driver's queue maybe not be getting torn down like it did in the
past? -- if it lingers in this "dying" state then that could start to
explain why this is happening all of a sudden in v4.7-rc<n>.  Would be
nice to know if that is what is happening.

But you've definitely seen that your path selector patch, that skips
selecting paths with dying queues, avoids this live-lock issue?

      reply	other threads:[~2016-06-28 19:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-28  9:07 [PATCH] dm mpath: Fix a dm_blk_ioctl() deadlock Bart Van Assche
2016-06-28 18:15 ` Mike Snitzer
2016-06-28 18:29   ` Bart Van Assche
2016-06-28 18:59     ` Mike Snitzer
2016-06-28 19:16       ` Bart Van Assche
2016-06-28 19:33         ` Mike Snitzer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160628193302.GB8300@redhat.com \
    --to=snitzer@redhat.com \
    --cc=bart.vanassche@sandisk.com \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.