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

Simplified OOM handling #141

Open
OlliV opened this issue Jun 3, 2017 · 3 comments
Open

Simplified OOM handling #141

OlliV opened this issue Jun 3, 2017 · 3 comments

Comments

@OlliV
Copy link
Member

OlliV commented Jun 3, 2017

The issue is two fold, the usual case is that a syscall gets ENOMEM as a result of a call to a function declared in kmalloc.h, and the rarer case is that a kernel subsystem runs out of memory and can't continue proper operation. In the former case it would be a lot easier to just quit instead of trying to rollback and keep half-operational. These code paths are practically never tested properly.

The first case is quite often a result of the user passing an absurdly huge buffer size as an argument, in which case we should actually do input validation and not even try to allocate a kernel buffer for the data. Usually instead of allocating a kernel buffer uio buffer wrapping should be preferred, which reads and writes directly from and to the user space. The only problem is that it makes input validation impossible in case it's necessary, because another thready could alter the data while the other thread is executing the syscall code.

@OlliV
Copy link
Member Author

OlliV commented Jun 3, 2017

#142

@OlliV
Copy link
Member Author

OlliV commented Feb 11, 2020

#150

@OlliV
Copy link
Member Author

OlliV commented Jul 15, 2021

What is also being done is moving back to statically allocate as much as possible. This will make the boot procedure faster and more reliable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant