-
Notifications
You must be signed in to change notification settings - Fork 30
Fix #581: Add CRC32 checksum verification for pushdata/fetchdata data channels #887
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: stable/v7.x
Are you sure you want to change the base?
Changes from 4 commits
8f27605
09e52c7
9a2ec70
147fcc8
ef7a447
d6fda84
19c777f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -71,6 +71,8 @@ class RaftReplDevMetrics : public sisl::MetricsGroup { | |
| REGISTER_COUNTER(read_err_cnt, "total read error count", "read_err_cnt", {"op", "read"}); | ||
| REGISTER_COUNTER(write_err_cnt, "total write error count", "write_err_cnt", {"op", "write"}); | ||
| REGISTER_COUNTER(fetch_err_cnt, "total fetch data error count", "fetch_err_cnt", {"op", "fetch"}); | ||
| REGISTER_COUNTER(data_checksum_mismatch_cnt, "CRC32 mismatches on push/fetch data channels", | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. can we distinguish push_data_checksum_mismatch_cnt and fetch_data_checksum_mismatch_cnt
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. reason?
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done — both To answer @xiaoxichen's "reason?": push and fetch are distinct data paths with different failure modes. A mismatch on push (leader → follower direct RPC) narrows the problem to in-flight corruption or a sender-side CRC bug. A mismatch on fetch (follower pulling from leader) points to the same class of issue on a different code path. Keeping them separate lets operators immediately identify which channel is affected without having to correlate log timestamps or RPC traces. |
||
| "data_checksum_mismatch_cnt", {"op", "checksum"}); | ||
|
|
||
| REGISTER_COUNTER(fetch_rreq_cnt, "total fetch data count", "fetch_data_req_cnt", {"op", "fetch"}); | ||
| REGISTER_COUNTER(fetch_total_blk_size, "total fetch data blocks size", "fetch_total_blk_size", {"op", "fetch"}); | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should not make any assumption of the layer above homestore. raft_repl_dev is not only used by homeobject , it`s probably used by other storage applicaion in the future.
if another application built on homestore has a very small first 4 bytes(let`s say 0x10, for example), the following logic will confuse the old version with the new one
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
who is "another" application as of now? If there is no one, then it is safe. Tomorrow after the PR merged if there is new application on top of homestore they already on new code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @JacksonYao287 — and that's a valid concern in principle, but the detection doesn't rely on the DataHeader magic at all. The code uses three independent gates before treating a response as the new format:
BufferHasIdentifier(raw_data + sizeof(uoffset_t), "FDRS")— bytes 4–7 must literally be the ASCII stringFDRS. This is emitted only byFinishSizePrefixedBuffer(..., "FDRS")in ouron_fetch_data_received, so it cannot accidentally appear in a future application's raw block data.data_fetch_max_size_kb(2 MB).flatbuffers::Verifier— validates internal FlatBuffer structure.Any future application's raw block data would need to accidentally have
0x46 0x44 0x52 0x53at byte offset 4, then pass the size check, then satisfy the Verifier — all three independently. The DataHeader magic example @xiaoxichen gave was illustrating why the size check works for the current application, but the "FDRS" identifier gate is what makes this safe for any future application.Also fully agree with @xiaoxichen: any new application built on top of HomeStore after this PR merges will already have the new receiver code, so there's no backward compatibility concern there either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my thought is that , as you said, we should have independent gate and not rely on the header magic(defined by the application).
@OmDoshi13 thanks for the change