Bug #47015
closedmds: decoding of enum types on big-endian systems broken
0%
Description
When a struct member that has enum type needs to be encoded or
decoded, we need to use an explicit integer type, since there
are no encode routines for the enum type. (This is probably
to avoid introducing dependencies on implementation-defined
choices by the compiler to use a particular underlying type.)
This leads to code sequences along the lines of:
encode((int32_t)state, bl);
and
decode((int32_t&)(state), bl);
The encode line is actually fine, but the decode line is
incorrect on big-endian systems if the underlying type of
the enum differs from the explicitly chosen integer type.
This is because this performs in effect a pointer cast,
and will write the decoded int32_t value into the memory
backing the "state" member variable. If the sizes differ,
the value is written into the wrong bytes of "state" on
big-endian systems.
This bug showed up initially as invalid health-status values
causing Ceph daemon aborts on s390x. Code review uncovered
a number of other instances of the same enum decode pattern.