On Thu, Dec 19, 2024 at 10:36:49PM +0100, Luca wrote:
I tried a lower value, like 2GB, but some process is mapping
4GB at once during boot and it just hangs when the allocation
fails.
Which process is that?
Its task name is `exec` and it's using vm_map. The log in question is:
[vm_map] [task exec] map size: 0, requested size: 4294967296, hard limit:
2147483648
One big point to address is how to enforce the ability to change this limit,
e.g. an unprivileged task shouldn't be able to increase its own memory
limit. You could reuse the host privileged port, but maybe it could make
sense to have a dedicated one for resource limits?
Correct. To be honest, at this poit, I haven't thought about it. I was just
toying with a POC implementation. Having the host privileged port means being
root essentially, right?
One additional point would be at least in task_create(), I guess the new
task would have the same restriction as the one creating it.
Yes, indeed. A quick look at kern/task.c shows I should check vm_map_fork:
} else if (inherit_memory) {
new_task->map = vm_map_fork(parent_task->map);
To experiment I'd suggest creating a test program as the ones in the tests/
folder in gnumach source, so you can try every single case and easily debug
it. Currently they can only be run on GNU/Linux as they require qemu.
I will try to set one up. But, I have an unusual environment for a FLOSS
developer, hehe.
----
Index: gnumach-1.8+git20240714/vm/vm_map.c
It would be better to create the patches from the git repository instead of
the debian package, and then use git-format-patch and git-send-mail.
Sorry, I've fallen in the temptation of `dpkg-buildpackage` and friends :)