Straw man of user space unable to cope with errors [LWN.net]

Straw man of user space unable to cope with errors

Posted Mar 11, 2015 9:57 UTC (Wed) by andresfreund (subscriber, #69562)
In reply to: Straw man of user space unable to cope with errors by iq-0
Parent article: Allowing small allocations to fail

> But the 'user space coping with errors' is just a straw man. User space copes with what it encounters. If we never return ENOMEM, most programs won't cope with that. Start returning ENOMEM and the few programs/frameworks/libraries/virtuals-machines that matter will cope with them, just like they cope with the occasional EINTR return from a syscall. And the more they're exposed to it, the better they'll cope with it.

I don't find that convincing. With EINTR you know that retrying makes sense, and it's easy enough to get them during normal testing. Note that EINTR was already annoying enough to many people , so that SA_RESTART has been introduced.

This would essentially mean that you need to wrap every syscall in a retry loop. But you need to have smarts about how these retry loops look, because ENOMEM *does* have other meanings than 'kernel internal memory allocation failed'. E.g. shmget() will return ENOMEM on some platforms if you exceed configured limits.

So realistically what will happen is that userspace programs will just exit with an error.

> And the most critical applications (like database, webservers and the like) are cross platform. So they're pretty likely to have proper handling of ENOMEM because I don't think many other systems made the decision to handle scarce resource allocation in the most difficult place cope with such problems

I don't think that's the case for many syscalls.

to post comments

Straw man of user space unable to cope with errors

Posted Mar 11, 2015 10:56 UTC (Wed) by tao (subscriber, #17563) [Link] (3 responses)

I've long been a proponent for SIGDANGER, as available in AIX. This doesn't solve the ENOMEM risk, to be sure, but it makes it more likely that the apps getting killed are those that do not handle memory properly, and also makes it less likely that the system runs out of memory in the first place (since any low memory conditions will trigger cache flushes, etc.)

Straw man of user space unable to cope with errors

Posted Mar 12, 2015 10:01 UTC (Thu) by iq-0 (subscriber, #36655) [Link] (2 responses)

Please no signal. Handling ENOMEM in multithreaded daemons is often a simple case of aborting or failing a single request (and thus also freeing up resources in the daemon itself, often releasing things like filedescriptors and the like as well). A signal would not confer any specificity about what caused it.

Sure normal programs should be allowed to be killed, but you'd pretty soon end up with a situation that all daemons would block this flag (since they can't really handle it gracefully). And on servers that effectively everything running (that really take up resources).

The only benefit would be if such a signal could be used to release all internal buffers, but that is often a problem that needs temporary resources and often needs to wait for other threads/processes to enter a quiescent state (and that possibly keep claiming resources until then). So that would only work before you have a problem.

Straw man of user space unable to cope with errors

Posted Mar 12, 2015 10:32 UTC (Thu) by tao (subscriber, #17563) [Link] (1 responses)

SIGDANGER isn't intended or used to signal that the system is *out of memory*. SIGDANGER is used to convey to processes (that choose to register a handler for this) that memory is dangerously low.

Imagine how awesome it'd be to have memory hogging browsers (for instance) empty up cached memory? At the same time the signal could also be used by the UI to let the user know that something is a bit wrong (obviously such a feature should be used with a bit of caution -- getting to know that the system is low on memory at the same time Chrome frees up 4GB of cache would be rather pointless).

Straw man of user space unable to cope with errors

Posted Mar 12, 2015 19:42 UTC (Thu) by pbonzini (subscriber, #60935) [Link]

See the memory pressure cgroup mechanism.

Straw man of user space unable to cope with errors

Posted Mar 12, 2015 9:53 UTC (Thu) by iq-0 (subscriber, #36655) [Link]

> This would essentially mean that you need to wrap every syscall in a retry loop. But you need to have smarts about how these retry loops look, because ENOMEM *does* have other meanings than 'kernel internal memory allocation failed'. E.g. shmget() will return ENOMEM on some platforms if you exceed configured limits.

> I don't think that's the case for many syscalls.

Many syscalls don't necessarily require memory allocation. And I'm not suggesting each and every memory allocation should be returned to user-space. Retries in the memory allocating code or at the syscall level inside the kernel (and outside of critical sections so that we can back-off a little and possibly be killable when it's in an infinite retry loop) is a good solution for most syscalls that users won't normally expect ENOMEM from.

But certain interactions with the kernel like, mostly related to I/O (which most programs already have to deal with corner cases) should allow for ENOMEM. Userspace can then take appriopriate action, retry is a valid option, but deferring or aborting equally so.

> So realistically what will happen is that userspace programs will just exit with an error.

Yup. For programs that don't care about handling this situation (it's not like being killed, they do it themselves). Otherwise we'd get hanging systems, OOM-killed processes and general nastyness.