Astractly, I think this really overcomplicates the API a lot. If these are truly generally useful (and I think that remains to be demonstrated), they should be additions to the existing API, rather than a sidestep with prctl.

I also worry about some other more concrete things:

1. Doesn't this allow unprivileged applications to potentially bypass memory.high constraints set by a system administrator?
2. What's the purpose of PR_MEMACT_KILL, compared to memory.max?
3. Why add this entirely separate signal delivery path when we already have eventfd/poll/inotify support, which makes a lot more sense for modern applications?

Reply via email to