From: Mike Snitzer <snitzer@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Bart Van Assche <Bart.VanAssche@sandisk.com>,
"dm-devel@redhat.com" <dm-devel@redhat.com>,
"hch@lst.de" <hch@lst.de>, "hare@suse.com" <hare@suse.com>,
"stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH 02/13] dm-mpath: Avoid that path removal can trigger an infinite loop
Date: Thu, 27 Apr 2017 11:36:42 -0400 [thread overview]
Message-ID: <20170427153642.GC22608@redhat.com> (raw)
In-Reply-To: <87938548-937c-004d-741b-ef3bd8c4ccc0@suse.de>
On Thu, Apr 27 2017 at 11:13am -0400,
Hannes Reinecke <hare@suse.de> wrote:
> On 04/27/2017 05:11 PM, Bart Van Assche wrote:
> > On Thu, 2017-04-27 at 07:46 +0200, Hannes Reinecke wrote:
> >> On 04/26/2017 08:37 PM, Bart Van Assche wrote:
> >>> + clone = blk_get_request(q, rq->cmd_flags | REQ_NOMERGE, GFP_ATOMIC);
> >>> if (IS_ERR(clone)) {
> >>> /* EBUSY, ENODEV or EWOULDBLOCK: requeue */
> >>> - return r;
> >>> + pr_debug("blk_get_request() returned %ld%s - requeuing\n",
> >>> + PTR_ERR(clone), blk_queue_dying(q) ?
> >>> + " (path offline)" : "");
> >>> + if (blk_queue_dying(q)) {
> >>> + atomic_inc(&m->pg_init_in_progress);
> >>> + activate_path(pgpath);
> >>> + return DM_MAPIO_REQUEUE;
> >>> + }
> >>> + return DM_MAPIO_DELAY_REQUEUE;
> >>> }
> >>> clone->bio = clone->biotail = NULL;
> >>> clone->rq_disk = bdev->bd_disk;
> >>
> >> At the very least this does warrant some inline comments.
> >> Why do we call activate_path() here, seeing that the queue is dying?
> >
> > Hello Hannes,
> >
> > activate_path() is not only able to activate a path but can also change
> > the state of a path to offline. The body of the activate_path() function
> > makes that clear and that is why I had not added a comment above the
> > activate_path() call:
> >
> > static void activate_path(struct pgpath *pgpath)
> > {
> > struct request_queue *q = bdev_get_queue(pgpath->path.dev->bdev);
> >
> > if (pgpath->is_active && !blk_queue_dying(q))
> > scsi_dh_activate(q, pg_init_done, pgpath);
> > else
> > pg_init_done(pgpath, SCSI_DH_DEV_OFFLINED);
> > }
> >
> So why not call 'pg_init_done()' directly and avoid the confusion?
Doing so is sprinkling more SCSI specific droppings in code that should
be increasingly transport agnostic. Might be worth renaming
activate_path() to activate_or_offline_path() ?
Mike
next prev parent reply other threads:[~2017-04-27 15:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170426183728.10821-1-bart.vanassche@sandisk.com>
2017-04-26 18:37 ` [PATCH 01/13] dm-mpath: Split activate_path() Bart Van Assche
2017-04-26 18:37 ` [PATCH 02/13] dm-mpath: Avoid that path removal can trigger an infinite loop Bart Van Assche
2017-04-27 5:46 ` [dm-devel] " Hannes Reinecke
2017-04-27 15:11 ` Bart Van Assche
2017-04-27 15:13 ` Hannes Reinecke
2017-04-27 15:36 ` Mike Snitzer [this message]
2017-04-26 18:37 ` [PATCH 03/13] dm-mpath: Delay requeuing while path initialization is in progress Bart Van Assche
2017-04-27 5:47 ` [dm-devel] " Hannes Reinecke
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=20170427153642.GC22608@redhat.com \
--to=snitzer@redhat.com \
--cc=Bart.VanAssche@sandisk.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.com \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=stable@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).