multipath flush always returns 1

Thanks which version are you using?

chuck

[Expired for multipath-tools (Ubuntu) because there has been no activity for 60 days.]

Adam,

thanks very much for the bug report and the patch.

Marking this Triaged as it has been confirmed elsewhere.

Per comment from Peter, this can actually cause a system crash, so marking this high priority.

I can easily reproduce this problem w/ natty's multipath-tools and can verify that the above fix works for me. I should be able to test an SRU if desired.

It's an indirect crash, if we're script driven, since the output is always
1, the user decided that the return value meant nothing and that
removing the actual path member was OK. Instead a crash occurred.

debs available for testing from ppa:peter-petrakis/storage for
all affected distributions. Please test.

root@kickseed:~# multipath -f 222d8000155636433
libdevmapper: libdm-common.c(489): Removed /dev/mapper/222d8000155636433
root@kickseed:~# echo $?
0
root@kickseed:~# lsb_release -r
Release: 10.04

apt-cache policy multipath-tools | grep Insta
  Installed: 0.4.8-14ubuntu4.10.04.2.1

SRU Justification:
 * During development where a customer is aiming to automate storage
 provisioning that includes a multipath component. Politely tearing
 down the dm table before physically removing the device is part of
 best practices for removing devices at runtime. Since multipath -f/-F
 always returns 1, the customer assumed that the return code was irrelevant
 and continued with device removal. In the cases where DM really wasn't
 finished flushing the outstanding I/O, a kernel crash occurred, since
 the customer essentially tore the backing store out from under multipath
 while there was pending I/O. All based on the faulty return value of
 multipath -f/-F.

 * The patch is pulled from upstream, with only minor modification to
 suit our older codebase. We're simply forwarding the return value
 from this dm table operation instead of dropping it.

 * Regression possibility is low, and the corrected return behavior
 may prevent further unnecessary kernel triage in the future.

 * TEST CASE: Make a multipath device busy, flush it, and immediately
 remove it, physically.

 * Inadvertent regression potential: None, if anything it'll improve
 best practices.

Hi Peter

Thanks very much for documenting the SRU justification and proposing branches for lucid, natty and maverick.

Unfortunately there is already a SRU in -proposed for multipath-tools (see bug 789229) so we need to let this complete SRU process to -updates for these three releases before uploading your proposed branches.

You will need to update each of your proposed branches with the changes from -updates once accepted and revise the debian/changelog version numbers as below:

 Natty: 0.4.8-14ubuntu10.3
 Maverick: 0.4.8-14ubuntu4.10.10.4
 Lucid: 0.4.8-14ubuntu4.10.04.4

Please can you also make sure that the branches target -proposed in the changelog, i.e. natty-proposed, instead of the standard 'natty' release pocket - this will make sure it gets into the right part of the archive for SRU verification.

I'm going to mark all three merge proposals as 'Needs Fixing' for the time being as they all need to be updated.

You can find more detail on the SRU process here - https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.

Thanks again

Hi James,

Thanks for the feedback. Will track bug 789229 and rebase/propose
accordingly.

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

eol reached https://wiki.ubuntu.com/Releases

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".