Bug #47302
include/encoding: Fix encode/decode of float types on big-endian systems
0%
Description
Currently, floating-point types use "raw" encoding, which means they're simply copied as byte stream.
This means that if the decoding happens on a machine that differs in byte order from the source machine, the returned value will be incorrect. As one effect of this problem, a big-endian OSD node cannot join a cluster where the MON node is little-endian (or vice versa), because the OSDMap (incremental) structure contains floating-point values, and as a result of this conversion problem, the OSD node will crash with an assertion failure as soon as it receives any OSDMap update from the MON.
This should be fixed by always encoding floating-point values in little-endian byte order just as is done for integers. (Note that this still assumes source and target machines used the same floating-point format except for byte order. But given that nearly all platforms these days use IEEE binary32/binary64 for float/double, that seems a reasonable assumption.)
Related issues
History
#1 Updated by Ulrich Weigand over 3 years ago
#2 Updated by Kefu Chai over 3 years ago
- Status changed from New to Resolved
- Assignee set to Ulrich Weigand
- Pull request ID set to 36992
#3 Updated by Ulrich Weigand over 3 years ago
Thanks! Can we backport this to Octopus and Nautilus like the other encoding/decoding fixes?
#4 Updated by Nathan Cutler over 3 years ago
- Status changed from Resolved to Pending Backport
- Backport set to nautilus octopus
#5 Updated by Nathan Cutler over 3 years ago
- Copied to Backport #47350: nautilus: include/encoding: Fix encode/decode of float types on big-endian systems added
#6 Updated by Nathan Cutler over 3 years ago
- Copied to Backport #47351: octopus: include/encoding: Fix encode/decode of float types on big-endian systems added
#7 Updated by Nathan Cutler over 3 years ago
- Status changed from Pending Backport to Resolved
While running with --resolve-parent, the script "backport-create-issue" noticed that all backports of this issue are in status "Resolved" or "Rejected".