Comment 9 for bug 641151

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.