On Tue, 2025-11-11 at 15:52 -0500, Benjamin Marzinski wrote:
> mpathpersist was incorrectly parsing the REPORT CAPABILITES service
> action output. In reality, the type mask is two bytes where the type
> information is stored in bits 7, 6, 5, 3, & 1 (0xea) of the first
> byte
> and bit 0 (0x01) of the second byte. libmpathpersist was treating
> these
> two bytes as a big endian 16 bit number, but mpathpersist was looking
> for bits in that number as if it was little endian number.
>
> Ideally, libmpathpersist would treat prin_capdescr.pr_type_mask as
> two bytes, like it does for the flags. But we already expose this
> as a 16 bit number, where we treated the input bytes as a big endian
> number. There's no great reason to mess with the libmpathpersist API,
> when we can just make mpathpersist treat this data like
> libmpathpersist
> provides it. So, fix mpathpersist to print the data out correctly.
>
> Additionally, instead of printing a 1 or a 0 to indicate if a type
> was
> supported or not, it was printing the value of the type flag. Also,
> Persist Through Power Loss Capable (PTPL_C) was being reported if any
> bit in flags[0] was set. Fix these as well. Reformat all of the
> capability printing lines, since it is less confusing than only
> reformatting some of them.
>
> Fixes: ae4e8a6 ("mpathpersist: Add new utility for managing
> persistent reservation on dm multipath device")
> Signed-off-by: Benjamin Marzinski <[email protected]>
Reviewed-by: Martin Wilck <[email protected]>
