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?