Bug 860748 - multipath -ll does not consider full blacklist
Summary: multipath -ll does not consider full blacklist
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath
Version: 6.3
Hardware: Unspecified
OS: Linux
Target Milestone: rc
: ---
Assignee: Ben Marzinski
QA Contact: Gris Ge
Depends On:
Blocks: 810353
TreeView+ depends on / blocked
Reported: 2012-09-26 15:48 UTC by Joe Lawrence
Modified: 2013-02-21 10:57 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Multipath was not checking the device type and wwid blacklists as soon as this information was available for a path device Consequence: Multipath could hang for a long time before determining that a path device was invalid. Fix: Multipath now checks the device type and wwid blacklists as soon as this information is available for a path device Result: Multipath no longer hangs for a while before blacklisting invalid paths.
Clone Of:
Last Closed: 2013-02-21 10:57:39 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0458 normal SHIPPED_LIVE device-mapper-multipath bug fix and enhancement update 2013-02-20 21:07:30 UTC

Description Joe Lawrence 2012-09-26 15:48:21 UTC
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):

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 

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)...


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.

Comment 1 Joe Lawrence 2012-09-26 15:49:48 UTC
Bug 661984 appears to suffer from the same problem.

Comment 3 Ben Marzinski 2012-10-15 04:18:06 UTC
multipath now checks the blacklists as soon as it can.

Comment 6 Gris Ge 2013-01-22 11:14:25 UTC
On RHEL 6.3 GA device-mapper-multipath-0.4.9-56.el6.x86_64, multipath will try to check path status even disk is blacklisted:
===== paths list =====
uuid hcil    dev dev_t pri dm_st chk_st vend/prod/rev        dev_st
     1:0:0:0 sda 8:0   -1  undef undef  ATA,WDC WD1600BEVS-0 running

On device-mapper-multipath-0.4.9-63.el6.x86_64, it dirrectly skip blacklisted paths:
===== no paths =====


Comment 8 errata-xmlrpc 2013-02-21 10:57:39 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.