-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Fix in-place save for DefaultSessionResumptionStorage #23062
Conversation
src/protocols/secure_channel/DefaultSessionResumptionStorage.cpp
Outdated
Show resolved
Hide resolved
26113c2
to
ae0fbe3
Compare
Nodes that already exist in the DefaultSessionResumptionStorage index are consuming additional entries in the index on save, and aren't cleaned from the link and state tables first. This has the following consequences: 1. If session resumption storage is full, this causes unnecessary eviction of records for other nodes. 2. This pulls the index out of sync from the backing state table because duplicate entries in the index for a given node only map map to a single node-id-keyed entry in the state table. 3. An entry in the link table is leaked on each occurrence, as the resumption-id-keyed link entry will be orphaned once its associated state table entry is overwritten. This commit fixes the problem by first deleting the link table entry before saving a record for a node that already exists in the table. Save is also simplified in this case by not rewriting the index, as the node is already in the index.
ae0fbe3
to
e0007b3
Compare
PR #23062: Size comparison from 0bff5ad to e0007b3 Increases (32 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, linux, nrfconnect, psoc6, qpg, telink)
Decreases (6 builds for cc13x2_26x2)
Full report (32 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, linux, nrfconnect, psoc6, qpg, telink)
|
src/protocols/secure_channel/tests/TestDefaultSessionResumptionStorage.cpp
Show resolved
Hide resolved
PR #23062: Size comparison from 0bff5ad to 03fb7d9 Increases above 0.2%:
Increases (35 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, k32w, linux, nrfconnect, psoc6, qpg, telink)
Decreases (6 builds for cc13x2_26x2)
Full report (35 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, k32w, linux, nrfconnect, psoc6, qpg, telink)
|
PR #23062: Size comparison from 0bff5ad to 1029f85 Increases (37 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, nrfconnect, psoc6, qpg, telink)
Decreases (6 builds for cc13x2_26x2)
Full report (37 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, nrfconnect, psoc6, qpg, telink)
|
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.
Nice catch!
src/protocols/secure_channel/tests/TestDefaultSessionResumptionStorage.cpp
Show resolved
Hide resolved
NL_TEST_ASSERT(inSuite, vector.cats.values[1] == outCats.values[1]); | ||
NL_TEST_ASSERT(inSuite, vector.cats.values[2] == outCats.values[2]); | ||
|
||
// Validate retreiveal by resumption ID. |
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.
"retrieval"
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.
PR here: #23110.
src/protocols/secure_channel/tests/TestDefaultSessionResumptionStorage.cpp
Show resolved
Hide resolved
src/protocols/secure_channel/tests/TestDefaultSessionResumptionStorage.cpp
Show resolved
Hide resolved
Apply suggestions per bzbarsky-apple
…3062) Nodes that already exist in the DefaultSessionResumptionStorage index are consuming additional entries in the index on save, and aren't cleaned from the link and state tables first. This has the following consequences: 1. If session resumption storage is full, this causes unnecessary eviction of records for other nodes. 2. This pulls the index out of sync from the backing state table because duplicate entries in the index for a given node only map to a single node-id-keyed entry in the state table. 3. An entry in the link table is leaked on each occurrence, as the resumption-id-keyed link entry will be orphaned once its associated state table entry is overwritten. A symptom of this can be seen in the DeleteAll(FabricIndex fabricIndex) method, which will often log errors due to the index being out of sync form the state table. This commit fixes the problem by first deleting the link table entry before saving a record for a node that already exists in the table. Save is also simplified in this case by not rewriting the index, as the node is already in the index. To prevent future problems, unit test code has been added for DefaultSessionResumptionStorage to verify that DeleteAll is completing without errors and that no link or state table entries are leaked. (cherry picked from commit f6d585a)
) Apply suggestions per bzbarsky-apple (cherry picked from commit 2a1cf85)
…3062) Nodes that already exist in the DefaultSessionResumptionStorage index are consuming additional entries in the index on save, and aren't cleaned from the link and state tables first. This has the following consequences: 1. If session resumption storage is full, this causes unnecessary eviction of records for other nodes. 2. This pulls the index out of sync from the backing state table because duplicate entries in the index for a given node only map to a single node-id-keyed entry in the state table. 3. An entry in the link table is leaked on each occurrence, as the resumption-id-keyed link entry will be orphaned once its associated state table entry is overwritten. A symptom of this can be seen in the DeleteAll(FabricIndex fabricIndex) method, which will often log errors due to the index being out of sync form the state table. This commit fixes the problem by first deleting the link table entry before saving a record for a node that already exists in the table. Save is also simplified in this case by not rewriting the index, as the node is already in the index. To prevent future problems, unit test code has been added for DefaultSessionResumptionStorage to verify that DeleteAll is completing without errors and that no link or state table entries are leaked.
…3062) Nodes that already exist in the DefaultSessionResumptionStorage index are consuming additional entries in the index on save, and aren't cleaned from the link and state tables first. This has the following consequences: 1. If session resumption storage is full, this causes unnecessary eviction of records for other nodes. 2. This pulls the index out of sync from the backing state table because duplicate entries in the index for a given node only map to a single node-id-keyed entry in the state table. 3. An entry in the link table is leaked on each occurrence, as the resumption-id-keyed link entry will be orphaned once its associated state table entry is overwritten. A symptom of this can be seen in the DeleteAll(FabricIndex fabricIndex) method, which will often log errors due to the index being out of sync form the state table. This commit fixes the problem by first deleting the link table entry before saving a record for a node that already exists in the table. Save is also simplified in this case by not rewriting the index, as the node is already in the index. To prevent future problems, unit test code has been added for DefaultSessionResumptionStorage to verify that DeleteAll is completing without errors and that no link or state table entries are leaked.
* Fix in-place save for DefaultSessionResumptionStorage (#23062) Nodes that already exist in the DefaultSessionResumptionStorage index are consuming additional entries in the index on save, and aren't cleaned from the link and state tables first. This has the following consequences: 1. If session resumption storage is full, this causes unnecessary eviction of records for other nodes. 2. This pulls the index out of sync from the backing state table because duplicate entries in the index for a given node only map to a single node-id-keyed entry in the state table. 3. An entry in the link table is leaked on each occurrence, as the resumption-id-keyed link entry will be orphaned once its associated state table entry is overwritten. A symptom of this can be seen in the DeleteAll(FabricIndex fabricIndex) method, which will often log errors due to the index being out of sync form the state table. This commit fixes the problem by first deleting the link table entry before saving a record for a node that already exists in the table. Save is also simplified in this case by not rewriting the index, as the node is already in the index. To prevent future problems, unit test code has been added for DefaultSessionResumptionStorage to verify that DeleteAll is completing without errors and that no link or state table entries are leaked. (cherry picked from commit f6d585a) * Minor style and comment fixes for #23062 (#23110) Apply suggestions per bzbarsky-apple (cherry picked from commit 2a1cf85)
Nodes that already exist in the DefaultSessionResumptionStorage index are consuming additional entries in the index on save, and aren't cleaned from the link and state tables first. This has the following consequences:
This commit fixes the problem by first deleting the link table entry before saving a record for a node that already exists in the table. Save is also simplified in this case by not rewriting the index, as the node is already in the index.
Fixes #23044