Bug 860748 - multipath -ll does not consider full blacklist
multipath -ll does not consider full blacklist
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: device-mapper-multipath (Show other bugs)
6.3
Unspecified Linux
medium Severity medium
: rc
: ---
Assigned To: Ben Marzinski
Gris Ge
:
Depends On:
Blocks: 810353
  Show dependency treegraph
 
Reported: 2012-09-26 11:48 EDT by Joe Lawrence
Modified: 2013-02-21 05:57 EST (History)
16 users (show)

See Also:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-21 05:57:39 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joe Lawrence 2012-09-26 11:48:21 EDT
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.
Comment 1 Joe Lawrence 2012-09-26 11:49:48 EDT
Bug 661984 appears to suffer from the same problem.
Comment 3 Ben Marzinski 2012-10-15 00:18:06 EDT
multipath now checks the blacklists as soon as it can.
Comment 6 Gris Ge 2013-01-22 06:14:25 EST
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 =====


VERIFY.
Comment 8 errata-xmlrpc 2013-02-21 05:57:39 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-0458.html

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