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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/641151 Title: multipath flush always returns 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/641151/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
