Linux Device Mapper development
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Christophe Varoqui <christophe.varoqui@opensvc.com>,
	Benjamin Marzinski <bmarzins@redhat.com>
Cc: dm-devel@redhat.com, Martin Wilck <mwilck@suse.com>
Subject: [PATCH v5 17/21] libmultipath: pathinfo: don't blank wwid if checker fails
Date: Fri,  2 Nov 2018 13:21:21 +0100	[thread overview]
Message-ID: <20181102122125.30906-18-mwilck@suse.com> (raw)
In-Reply-To: <20181102122125.30906-1-mwilck@suse.com>

Blanking a WWID is a dangerous operation. E.g. configure() would
consider the path in question as invalid and orphan it if the
WWID is blank. Don't do this checker failures which may be transient
or indicate a badly configured or otherwise malfunctioning checker.
Moreover, we try to determine WWID even if path_offline returns
PATH_DOWN in the first place, so why should we not if the checker
has a problem?

Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Martin Wilck <mwilck@suse.com>
---
 libmultipath/discovery.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 5e59e273..a6159e4a 100644
--- a/libmultipath/discovery.c
+++ b/libmultipath/discovery.c
@@ -1944,9 +1944,6 @@ int pathinfo(struct path *pp, struct config *conf, int mask)
 		if (path_state == PATH_UP) {
 			pp->chkrstate = pp->state = get_state(pp, conf, 0,
 							      path_state);
-			if (pp->state == PATH_UNCHECKED ||
-			    pp->state == PATH_WILD)
-				goto blank;
 			if (pp->state == PATH_TIMEOUT)
 				pp->state = PATH_DOWN;
 			if (pp->state == PATH_UP && !pp->size) {
-- 
2.19.1

  parent reply	other threads:[~2018-11-02 12:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-02 12:21 [PATCH v5 00/21] libmultipath: checkers overhaul Martin Wilck
2018-11-02 12:21 ` [PATCH v5 01/21] libmultipath: fix use of uninitialized memory in write() Martin Wilck
2018-11-02 12:21 ` [PATCH v5 02/21] libmultipath: fix memory leaks from scandir() use Martin Wilck
2018-11-02 12:21 ` [PATCH v5 03/21] libmultipath/checkers: replace message by msgid Martin Wilck
2018-11-02 16:05   ` Benjamin Marzinski
2018-11-02 12:21 ` [PATCH v5 04/21] libmultipath/checkers: cciss_tur: use message id Martin Wilck
2018-11-02 12:21 ` [PATCH v5 05/21] libmultipath/checkers: directio: " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 06/21] libmultipath/checkers: emc_clariion: " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 07/21] libmultipath/checkers: hp_sw: " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 08/21] libmultipath/checkers: rdac: " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 09/21] libmultipath/checkers: readsector0: " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 10/21] libmultipath/checkers: tur: " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 11/21] multipathd: improve checker message logging Martin Wilck
2018-11-02 16:54   ` Benjamin Marzinski
2018-11-02 12:21 ` [PATCH v5 12/21] libmultipath/checkers: support unsupported paths Martin Wilck
2018-11-02 12:21 ` [PATCH v5 13/21] libmultipath: clariion checker: leave unsupported paths alone Martin Wilck
2018-11-02 12:21 ` [PATCH v5 14/21] libmultipath: hp_sw " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 15/21] libmultipath: rdac " Martin Wilck
2018-11-02 12:21 ` [PATCH v5 16/21] libmultipath: tur " Martin Wilck
2018-11-02 12:21 ` Martin Wilck [this message]
2018-11-02 12:21 ` [PATCH v5 18/21] multipathd: check_path: improve logging for "unusable path" case Martin Wilck
2018-11-02 12:21 ` [PATCH v5 19/21] libmultipath: coalesce_paths: improve logging of orphaned paths Martin Wilck
2018-11-02 12:21 ` [PATCH v5 20/21] libmultipath: sync_map_state: log failing paths Martin Wilck
2018-11-02 12:21 ` [PATCH v5 21/21] libmultipath/checkers: cleanup class/instance model Martin Wilck
2018-11-14  7:39 ` [PATCH v5 00/21] libmultipath: checkers overhaul Christophe Varoqui

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=20181102122125.30906-18-mwilck@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=christophe.varoqui@opensvc.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox