Description of problem:
multipath -ll command can take a long time to complete processing a device that
should have been blacklisted by vendor.

Version-Release number of selected component (if applicable):
device-mapper-multipath-0.4.9-56.el6.x86_64

How reproducible:
Every time.

Steps to Reproduce:
1. Insert USB Floppy drive, wait for kernel to give it device node.
2. Run multipath -ll -v3
  
Actual results:
Watch multipath open USB floppy device node and appear to hang.  About a
minute later, multipath continues.

Expected results:
Multipath should have consulted the blacklist given information present in 
sysfs, like vendor/model/etc. and stopped processing this device.

Additional info:
Attached a USB floppy to box which has a few multipath LUNS.

[root@localhost ~]# lsscsi | grep USB
[357:0:0:0]  disk    NEC      USB UF000x       1.50  /dev/sdy

[root@localhost ~]# multipath -ll -v4

Sep 20 09:57:53 | Discover device /sys/block/sr1
Sep 20 09:57:53 | sr1: device node name blacklisted

 [ ... snip a bunch of blacklisted devices ... ]

Sep 20 09:57:53 | Discover device /sys/block/sdy
Sep 20 09:57:53 | sdy: not found in pathvec
Sep 20 09:57:53 | sdy: mask = 0x5
Sep 20 09:57:53 | sdy: dev_t = 65:128
Sep 20 09:57:53 | sdy: size = 2880
Sep 20 09:57:53 | sdy: subsystem = scsi
Sep 20 09:57:53 | sdy: vendor = NEC
Sep 20 09:57:53 | sdy: product = USB UF000x
Sep 20 09:57:53 | sdy: rev = 1.50
Sep 20 09:57:53 | sdy: h:b:t:l = 357:0:0:0
Sep 20 09:58:16 | sdy: get_state
Sep 20 09:58:16 | loading /lib64/multipath/libcheckreadsector0.so checker
Sep 20 09:58:16 | sdy: path checker = readsector0 (config file default)
Sep 20 09:58:16 | sdy: checker timeout = 30000 ms (sysfs setting)
Sep 20 09:58:16 | sdy: state = running
Sep 20 10:00:28 | sdy: state = 2
Sep 20 10:00:28 | sdy: checker msg is "readsector0 checker reports path is down"

So here we notice that multipath decides that device *names* like "sr1" are
blacklisted, an no further processing of them is done.

A reminder of what the blacklist and its exceptions look from 
/etc/multipath.conf:

blacklist {
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z]"
        device {
                vendor  "*"
                product "*"
        }
}

# Make sure our multipath devices are enabled.

blacklist_exceptions {
        device {
                vendor  "Stratus"
                product "AA-D91900"
        }
        device {
                vendor  "Stratus"
                product "AA-D95000"
        }
        device {
                vendor  "Stratus"
                product "AA-D95200"
        }
}

Since the USB floppy drive is assigned "sdy", it passes the device node name
blacklist test and multipath decides to take a closer look.

The multipath user side call trace (read top-down)...

libmultipath/discovery.c:

path_discover(vector pathvec, struct config * conf, char * devname, int flag)

	if (filter_devnode(conf->blist_devnode, conf->elist_devnode,
			   devname) > 0)
		return 0;

	[ ... snip ... ]

		pp = store_pathinfo(pathvec, conf->hwtable,
				    devname, flag);

store_pathinfo(vector pathvec, vector hwtable, char * devname, int flag)

	if (pathinfo(pp, hwtable, flag))
		goto out;

pathinfo(struct path *pp, vector hwtable, int mask)

	/*
	 * fetch info available in sysfs
	 */
	if (mask & DI_SYSFS && sysfs_pathinfo(pp))
		return 1;

	/*
	 * fetch info not available through sysfs
	 */
	if (pp->fd < 0)
		pp->fd = opennode(pp->dev, O_RDONLY);

opennode(char * dev, int mode)

	return open(devpath, mode);


Notice that path_discover will return if the device node name doesn't pass
the blacklist filter.  That is how devices like "sr1" are handled.

In the case of "sdy", it continues on into store_pathinfo, then pathinfo
where information from sysfs is first retrieved, then more information by
opening the device node.  This is where the process appears to hang.

Earlier in pathinfo, the sysfs_pathinfo call (by way of scsi_sysfs_pathinfo)
filled in the struct path *pp structure with information like the vendor,
product, revision...  All information included in the blacklist.
Unfortunately the information required to consult the blacklist was not
propagated down this far in the call stack.