Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-118515

There are many bugs in multipath's persistent reservation handling

Linking RHIVOS CVEs to...Migration: Automation ...Sync from "Extern...XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Normal Normal
    • rhel-9.8
    • rhel-9.0.0
    • device-mapper-multipath
    • None
    • device-mapper-multipath-0.8.7-40.el9
    • No
    • Moderate
    • ZStream
    • rhel-storage-dm
    • 7
    • 9
    • 3
    • Dev ack
    • False
    • False
    • Hide

      None

      Show
      None
    • Yes
    • None
    • Regression Exception
    • Requested
    • None
    • Bug Fix
    • Hide
      Cause: Numerous mpathpersist operations did not work for a multipath device, the way the equivalent sg_persist operation works for a SCSI device. Additionally, there were multiple corner cases where a multipath device's persistent reservations could end up in an inconsistent state.
      Consequence: mpathpersist commands could fail when they were not supposed to, and multipath devices could fail to write to a device they should be allowed to, or succeed in writing to a device where they shouldn't be allowed to.
      Fix: Multiple areas of libmpathpersist were redesigned or fixed
      Result: mpathpersist commands on multipath devices work the same as sg_persist commands on SCSI devices, and I/O to multipath devices always works the way it should, given the device's persistent reservation state
      Show
      Cause: Numerous mpathpersist operations did not work for a multipath device, the way the equivalent sg_persist operation works for a SCSI device. Additionally, there were multiple corner cases where a multipath device's persistent reservations could end up in an inconsistent state. Consequence: mpathpersist commands could fail when they were not supposed to, and multipath devices could fail to write to a device they should be allowed to, or succeed in writing to a device where they shouldn't be allowed to. Fix: Multiple areas of libmpathpersist were redesigned or fixed Result: mpathpersist commands on multipath devices work the same as sg_persist commands on SCSI devices, and I/O to multipath devices always works the way it should, given the device's persistent reservation state
    • Proposed
    • Unspecified
    • Unspecified
    • Unspecified
    • All
    • None

      What were you trying to do that didn't work?

      Multipath's persistent reservation handling through the libmpathpersist library (that is used by the mpathpersist command) has many corner cases where it does the wrong thing, for instance:

      If a path failed or returned a reservation conflict while libmpathpersist was doing a command, it could fail instead of retrying on another path.

      If a RELEASE command was run on a multipath device that was not holding the reservation it would fail, instead of succeeding, like the SCSI Spec says.

      If a RELEASE command was run on a multipath device, but the path holding the reservation was unavailable, it would try to work around the issue and release the reservation, but would usually fail and leave the device in an inconsistent state.

      If REGISTER or REGISTER AND IGNORE were run to update the key of a multipath device holding a reservation, but the path holding the reservation was down. The reservation would still be held by the old key.

      If a multipath device had a registered key, and the key was unregistered while a path was down, when the failed path was restored, it would still have a registered key.

      When libmpathpersist attempted to register a key, and failed, it would leave the device in an inconsistent state.

      If a path came back online while libmpathpersist was unregistering or changing a registered key, the path could end up getting the old key, or possibly no key, registered on it.

      If a RESERVE command was run on a multipath device already holding a reservation, it would fail if the path holding the reservation was down.

      If a multipath device preempted its own registered key, it was leaving the device in an inconsistent state.

      If a multipath device holding a reservation unregistered its key, it could leave the device in an inconsistent state

      What is the impact of this issue to you?

      This can cause multipath to write to devices it shouldn't be able to, or not write to devices that it should be able to. It can also cause multipath persistent reservation commands to fail when they shouldn't.

      Please provide the package NVR for which the bug is seen:

      This issue exists in all supported versions of device-mapper-multipath.

      How reproducible is this bug?:

      Some of the bugs are trivial to reproduce.

      Steps to reproduce

      Varies by bug.

      Expected results

      Multipath persistent reservations work like they would for a scsi device

      Actual results

      Multipath persistent reservations fail when they shouldn't or leave the device in an inconsistent state.

              rhn-engineering-bmarzins Benjamin Marzinski
              rhn-engineering-bmarzins Benjamin Marzinski
              Benjamin Marzinski Benjamin Marzinski
              Lin Li Lin Li
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated: