[PATCH] multipath-tools: multipathd makes offline devices active

[PATCH] multipath-tools: multipathd makes offline devices active

[Kiyoshi Ueda]

Hi Christophe,

multipathd(8) continues calling reinstate_path() in checkerloop(),
if multipathd(8) is started on the system which has multipath maps
including offline devices.
The reason is pp->checkfn() returns -1 for offline devices and
pp->state of these paths are 1.
(I'm using "echo offline > /sys/block/sd?/device/state" for the testing.)

As a result, multipathd(8) makes offline devices active state.
And this behavior also affects the no_path_retry feature, since 
struct multipath.nr_active is incremented in reinstate_path().

The following patch fixes this problem.
If the return value from pp->checkfn is -1, the path isn't available.
So I think that we can ignore it.

Any comments?


diff --git a/multipathd/main.c b/multipathd/main.c
index 4275a37..3d2848c 100644
--- a/multipathd/main.c
+++ b/multipathd/main.c
@@ -1239,7 +1239,12 @@ checkerloop (void *ap)
 			}
 			newstate = pp->checkfn(pp->fd, checker_msg,
 					       &pp->checker_context);
-			
+			if (newstate < 0) {
+				condlog(2, "%s: unusable path", pp->dev);
+				pathinfo(pp, conf->hwtable, 0);
+				continue;
+			}
+
 			if (newstate != pp->state) {
 				pp->state = newstate;
 				LOG_MSG(1, checker_msg);

Thanks,
Kiyoshi Ueda

Re: [PATCH] multipath-tools: multipathd makes offline devices active

[Christophe Varoqui]

On ven, 2005-11-11 at 18:43 -0500, Kiyoshi Ueda wrote:
> Hi Christophe,
> 
> multipathd(8) continues calling reinstate_path() in checkerloop(),
> if multipathd(8) is started on the system which has multipath maps
> including offline devices.
> The reason is pp->checkfn() returns -1 for offline devices and
> pp->state of these paths are 1.
> (I'm using "echo offline > /sys/block/sd?/device/state" for the testing.)
> 
> As a result, multipathd(8) makes offline devices active state.
> And this behavior also affects the no_path_retry feature, since 
> struct multipath.nr_active is incremented in reinstate_path().
> 
> The following patch fixes this problem.
> If the return value from pp->checkfn is -1, the path isn't available.
> So I think that we can ignore it.
> 
Looks correct, indeed.
Thanks, applied.

Regards,
cvaroqui