-
Notifications
You must be signed in to change notification settings - Fork 3k
Fix max_keys reset limitation #9054
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
Conversation
@theamirocohen, thank you for your changes. |
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.
LGTM
@theamirocohen Can you add more details to the commit msg ? The fix does not look that trivial. cc @NeilMacMullen for review |
I set this to 5.12 but I noticed this is updating private method, so no functional change there (fix can go to the next patch) ? |
Yes, fix can go to next patch |
Persist the max_keys value through a soft-reset, also prohibit max_keys set under predefined default value (16)
2dfff96
to
eff5227
Compare
CI started |
Test run: FAILEDSummary: 1 of 11 test jobs failed Failed test jobs:
|
Interesting. Error indicates that the NRF52_DK failed to flash. CI job restarted: |
Fix issue NvStore does not correctly persist values through reset
Resolves #8785
The former NvStore implementation did not persist the max_keys value through a soft-reset, a set value would have disappear after reset, meaning NvStore would start over with its default max_keys value which may cause data to be lost.
We added the max_keys value to master record (written to non volatile area) so we can read and update its value after reset.
Furthermore we added the restriction of setting max_keys to be bigger than the default predefined keys value (16), and in case we have set max_keys to a new value and want to set it again to a smaller value the operation will fail if there are keys that might be lost (if keys were store at that gap).