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

propagate additional process loading errors to main.rs #1770

Merged
merged 2 commits into from Apr 30, 2020

Conversation

hudson-ayers
Copy link
Contributor

Pull Request Overview

This pull request modifies process::create() to return an error in 3 cases where previously it just returned an empty process slot -- if there is an error initializing the process, if there is an error allocating the MPU region for that process's flash, or if there is not enough memory to meet the amount requested by that process (or the minimum amount currently required by the kernel).

It adds one new ProcessLoadError variant: ProcessLoadError::NotEnoughMemory. Failures with allocating an MPU region or initializing a process are treated as InternalError's.

This PR fixes #1764 by making it so that failing to load a valid process is no longer a silent failure if the board chooses to handle the error.

Testing Strategy

This pull request was tested by flashing 4 apps, each requesting 8kB of RAM, and observing they work as expected, then flashing 5 apps, each requesting 8kB of RAM, and observing that load_processes() fails, causing a debug message to be printed to the screen.

TODO or Help Wanted

This modifies the existing behavior of load_processes() so that it returns as soon as any process fails to load, whereas currently it will continue trying to load processes even if one fails for one of the above 3 reasons. I think this behavior is better, especially given that boards can redefine load_processes if they want to, but am open to pushback on this.

Documentation Updated

  • No updates are required.

Formatting

  • Ran make formatall.

jrvanwhy
jrvanwhy previously approved these changes Apr 17, 2020
alistair23
alistair23 previously approved these changes Apr 17, 2020
Copy link
Contributor

@bradjc bradjc left a comment

Choose a reason for hiding this comment

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

Thanks for looking into this.

app_flash.as_ptr() as usize,
app_flash.as_ptr() as usize + app_flash.len(),
process_name
);
}
return Ok((None, 0));
return Err(ProcessLoadError::InternalError);
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm not sure making this error InternalError is right. I think we want to save the internal error for only issues where the kernel is wrong. In this case, however, I think an app loaded with a length in flash that the MPU doesn't expect will cause an error, which is maybe arguably a kernel error, but the fix is to correct the app size, not patch the kernel.

Likely a new error would be better, one that indicates it could be the app or a bad MPU implementation.

@hudson-ayers hudson-ayers dismissed stale reviews from alistair23 and jrvanwhy via 18970bc April 20, 2020 16:56
@hudson-ayers
Copy link
Contributor Author

Added a new error type for when the MPU does not support the flash length of an app

@ppannuto
Copy link
Member

These are good changes, but since we're stalled on merging for a bit for 1.5 anyway, maybe this should keep bubbling up these errors and address #1225?

@hudson-ayers
Copy link
Contributor Author

These are good changes, but since we're stalled on merging for a bit for 1.5 anyway, maybe this should keep bubbling up these errors and address #1225?

I think that this does address #1225, at least for the process loading case? These errors are returned from load_processes() where they can be handled by main.rs (and are handled by main.rs, at least for Imix).

@ppannuto
Copy link
Member

Ohh.. my memory of that interface was stale, I think bf5610f really fixed #1225. I'll close that one out. Sorry for the noise!

@bradjc
Copy link
Contributor

bradjc commented Apr 30, 2020

bors r+

@bors
Copy link
Contributor

bors bot commented Apr 30, 2020

This PR was included in a batch that successfully built, but then failed to merge into master (it was a non-fast-forward update). It will be automatically retried.

@bradjc bradjc merged commit a8a1357 into tock:master Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Lack of Error Signaling when insufficient app memory available
5 participants