Description of problem:
Multipath currently has logic in the TUR checker's checker thread handling to fall back to synchronous mode in the event that the thread stops responding (i.e. a pthread_cancel() fails):

428                 if (ct->thread) {
429                         /* pthread cancel failed. continue in sync mode */
430                         pthread_mutex_unlock(&ct->lock);
431                         condlog(3, "%d:%d: tur thread not responding, "
432                                 "using sync mode", TUR_DEVT(ct));
433                         return tur_check(c->fd, c->timeout, c->message,
434                                          ct->wwid);
435                 }

This turns out to be the wrong thing to do: if the async thread has gone off into the weeds (generally it's blocked in the kernel while SCSI EH work takes place) the last thing we want to do is to cause multipathd to block in the same place.

Instead just report the path as down.

Version-Release number of selected component (if applicable):
multipath-tools-0.4.9-*.el6

How reproducible:
Difficult

Steps to Reproduce:
1. Requires fabric faults and driver handling that cause an SG_IO ioctl() from the daemon to block uninterruptibly for long enough that the next check sees the thread as stuck, attempts to cancel it, fails and then switches to sync mode.

Fault injection is probably the best way to recreate this under controlled conditions.

Actual results:

multipathd switches to sync TUR and blocks in D state in SG_IO ioctl()

Expected results:
multipathd reports the path as unavailable and continues other normal activity.

Additional info: