kpartx: verify GUID partition entry size

This patch pulls in some kernel code to catch a corrupt GUID partition
table with the wrong size.

Signed-off-by: Boris Ranto <branto@redhat.com>
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
multipath-tools: check header file instead of intalled lib

Hi,
attached patch checks the header file instead of an installed lib for
dm_task_struct. Since distros have this lib add different patchs the
check should be more reliable.
Cheers,
 -- Guido

From: =?UTF-8?q?Guido=20G=C3=BCnther?= <agx@sigxcpu.org>
Date: Sun, 30 Aug 2009 13:38:55 +0200
Subject: [PATCH] check header file for defintion of dm_task_no_flush

instead of checking the so for the symbol (which seems to be hard to
find).

Acked-by: Hannes Reinecke <hare@suse.de>
multipath: set ACT_RESIZE when the size has changed

When the multipath path devices change size, multipath can't be reloaded
with noflush set.  So, don't set the action to ACT_RELOAD, which will
cause the multipath device to get stuck in SUSPEND. Use ACT_RESIZE.

Also, I was seeing some messages that were getting cut off with the
128 byte messages size, so I doubled that, and the log area size.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
multipath: handle offlined paths

The kernel does not allow multipath to load tables containing offline
devices. Because of this, if you try add a path to a multipath device with
an offline path, the multipathd will continually, retry and fail to reload
the table. I've limited the retries to three to avoid livelocking.

Also, if you map included a offline path, multipath was crashing because
it couldn't get the required sysfs information before calling get_state().
It now checks for this in multipath, like it does in multipathd

Lastly, multipathd would keep reprinting the last checker message for
offlined paths, instead of something useful. It now prints a "path offline"
message.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Fix for Red Hat bz #737072.

CVSROOT:        /cvs/dm
Module name:    multipath-tools
Branch:         RHEL5_FC6
Changes by:     bmarzins@sourceware.org    2011-10-24 13:41:32

Modified files:
        path_priority/pp_alua: rtpg.c

Log message:
        Fix for bz #737072. Shorten the timeout for the alua prio callout function
        from 5 minutes to 1 minute.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/multipath-tools/path_priority/pp_alua/rtpg.c.diff?cvsroot=dm&only_with_tag=RHEL5_FC6&r1=1.3.2.5&r2=1.3.2.6
Memory leak in add_map_without_path()

mpp->alias is allocated, so we cannot just set it to NULL in
case of failure.

Signed-off-by: Hannes Reinecke <hare@suse.de>
Use VECTOR_SIZE for vector_foreach_slot_after()

Signed-off-by: Hannes Reinecke <hare@suse.de>
multipath: better argument type checking

The way that multipath decided what you passed in as an argument didn't
always work.  If the argument was the name of a file, then multipath
assumed that it was a path.  That meant if you were in /dev/mapper and ran

# multipath -f <mpath_device_name>

It would fail, since it thought you gave it a path name, instead of a
multipath device name.  Now multipath will only treat the argument
as a path name if it is a block device with a different major number than
device-mapper's.  Also, I've switched the MAJOR/MINOR/MKDEV macros to
work like kpartx, so that they can handle minor numbers over 255.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
multipathd: Open stdout/stderr in read/write mode

stdin is supposed to accept input, so better open
the console redirection fd in read/write mode.

Signed-off-by: Hannes Reinecke <hare@suse.de>
multipath: don't set queue_if_no_path without multipathd

If multipathd is not running, when all paths to a device have failed, there's
no way for them to automatically get restored.  If the device is set to queue,
whatever is accessing it will hang forever. This can lead to problems if it
happens at boot-up.  This patch unsets queue_if_no_path for all devices created
when multipathd is not running. When multipathd starts, it will automatically
get reset queue_if_no_path to the proper value.  This new behaviour can be
overridden using the new "-q" option to multipath.

This version of the patch contacts multipathd's client socket to tell if it's
running.

Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
multipath.conf.5: Document rr_min_io_rq

Parameter is used for newer kernels and should be documented.

References: bnc#774610

Signed-off-by: Hannes Reinecke <hare@suse.de>
multipath: Handle blocked FC rports

Occasionally, FC HBAs might lose track of the status of the
remote ports. For these cases I/O is stuck forever as the
normal 'fast_io_fail' mechanism isn't invoked.

To handle these cases I've implemented a 'sysfs_set_fc_rport_state'
function which will be set the port_state attribute to 'blocked'
manually. The function can be called manually via 'suspend path'
or when the tur checker returns a TIMEOUT.
The port state can be unset with the 'resume path' CLI command.

References: bnc#787438

Signed-off-by: Hannes Reinecke <hare@suse.de>
multipathd: add path when transitioned from 'blocked' state

When a path is discovered in 'blocked' state it won't be added
to the path list as we cannot get the path uuid.
And any further check will fail here as the uuid won't be
recovered. So add a check in checkerloop() to re-add the
path if it gets out of a 'blocked' state.

References: bnc#789008

Signed-off-by: Hannes Reinecke <hare@suse.de>
Document 'infinity' as possible value for dev_loss_tmo

infinity is a valid value for dev_loss_tmo, so we should be
documenting it.

References: bnc#802837,bnc#803262

Signed-off-by: Hannes Reinecke <hare@suse.de>
alua: Do not add preferred path priority for active/optimized

When a path is in active/optimized we should disregard the
'preferred path' bit when calculating the priority.
Otherwise we'll end up with having two different priorities
(one for 'active/optimized (preferred)' and one for
'active/optimized (non-preferred)').
Which will result in two different path groups and a
sub-optimal path usage.

References: bnc#802456

Signed-off-by: Hannes Reinecke <hare@suse.de>
multipath: Increase dev_loss_tmo prior to fast_io_fail

There are several constraints when setting fast_io_fail and
dev_loss_tmo.
dev_loss_tmo will be capped automatically when fast_io_fail is
not set. And fast_io_fail can not be raised beyond dev_loss_tmo.

So to increase dev_loss_tmo and fast_io_fail we first need
to increase dev_loss_tmo to the given fast_io_fail
setting, then set fast_io_fail, and then set dev_loss_tmo
to the final setting.

References: bnc#800353

Signed-off-by: Hannes Reinecke <hare@suse.de>