Skip to content
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 is_valid_erase function to use get_erase_size with address #7953

Merged
merged 1 commit into from
Sep 27, 2018

Conversation

davidsaada
Copy link
Contributor

Description

The base BlockDevice class includes the is_valid_erase function checking whether the address and size given to the erase API are valid. This function used to call the get_erase_size function without the address argument, but this was a bug, as it would have failed valid calls to erase. It now calls get_erase_size with the address argument.
Just to clarify - this will work also for classes that don't implement get_erase_size with the address parameter, as it defaults to the one that doesn't have the address in the base class.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Breaking change

addr % get_erase_size() == 0 &&
size % get_erase_size() == 0 &&
addr % get_erase_size(addr) == 0 &&
size % get_erase_size(addr) == 0 &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You check that 'size' is aligned with current 'addr' but a large 'size' might take you to a 'dest' address in a different sector with a different 'erase-size' than 'addr'.
Basically I think you need to verify that:
( (addr+size) % get_erase_size(addr+size-1) == 0 )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right about my code, but your solution is also problematic, as it only checks one sector. The right solution would be to iterate on the remaining sectors. Will fix that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right about the problem in my code, but your solution probably won't work either (as both only cover one sector). Right solution is probably an iteration over the remaining of the sectors. I'll fix it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@davidsaada - My thinking is that if the 'start' delete address is aligned to its sector, and the 'end' delete address is aligned to its own sector - then every sector in between them will be fully erased - so there's no need to iterate. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right - better than iteration. Will fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Please review.

@davidsaada davidsaada force-pushed the david_is_valid_erase_fix branch 2 times, most recently from 49f14a4 to e1c0b85 Compare September 3, 2018 13:15
@0xc0170
Copy link
Contributor

0xc0170 commented Sep 26, 2018

/morph build

@mbed-ci
Copy link

mbed-ci commented Sep 26, 2018

Build : SUCCESS

Build number : 3166
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/7953/

Triggering tests

/morph test
/morph export-build
/morph mbed2-build

@mbed-ci
Copy link

mbed-ci commented Sep 26, 2018

@mbed-ci
Copy link

mbed-ci commented Sep 26, 2018

@cmonr cmonr merged commit 6b85ec7 into ARMmbed:master Sep 27, 2018
@davidsaada davidsaada deleted the david_is_valid_erase_fix branch December 6, 2018 13:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants