Project

General

Profile

Actions

Bug #47015

closed

mds: decoding of enum types on big-endian systems broken

Added by Ulrich Weigand over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
-
Target version:
% Done:

0%

Source:
Community (dev)
Tags:
Backport:
octopus,nautilus
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
MDS
Labels (FS):
Pull request ID:
Crash signature (v1):
Crash signature (v2):

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.


Related issues 2 (0 open2 closed)

Copied to CephFS - Backport #47080: octopus: mds: decoding of enum types on big-endian systems brokenResolvedNathan CutlerActions
Copied to CephFS - Backport #47081: nautilus: mds: decoding of enum types on big-endian systems brokenResolvedNathan CutlerActions
Actions

Also available in: Atom PDF