Synchronous method in asynchronous signal callback

[Lennart Poettering]

On Wed, 27.05.15 10:43, Ray Strode (halfline at gmail.com) wrote:

> Hey,
> 
> > GLib's "do not handle OOM" policy is correct for the 99% case. Many
> > who believe they should be handling OOM are probably wrong. And of
> > those who should be, many are probably making a token effort that's
> > broken in practice.
> Yea it turns out even the kernel just punts and calls the OOM killer
> for small allocations:
> 
> https://lwn.net/Articles/627419/
> 
> Interesting excerpt:
> 
> [changing the "too small to fail" behavior now] is scary for a couple
> of reasons. One is that not all kernel developers are diligent about
> checking every memory allocation and thinking about a proper recovery
> path. But it is worse than that: since small allocations do not fail,
> almost none of the thousands of error-recovery paths in the kernel now
> are ever exercised. They could be tested if developers were to make
> use of the the kernel's fault injection framework, but, in practice,
> it seems that few developers do so. So those error-recovery paths are
> not just unused and subject to bit rot; chances are that a
> discouragingly large portion of them have never been tested in the
> first place.
> 
> If the unwritten "too small to fail" rule were to be repealed, all of
> those error-recovery paths would become live code for the first time.
> In a sense, the kernel would gain thousands of lines of untested code
> that only run in rare circumstances where things are already going
> wrong. There can be no doubt that a number of obscure bugs and
> potential security problems would result.

To tackle this problem we hare heavily using the gcc cleanup attribute
in systemd, so that vast majority of our error paths actually are
generated by the compiler instead of manually written. There are some
manual error paths left, but almost all are now automatic. Also, we
made sure to make our destructors idempotent so that the order doesn't
really matter in which they are called.

But yeah, OOM handling is still not fun. I am pretty sure though that
the kernel could benefit from the cleanup extension too...

Lennart

-- 
Lennart Poettering, Red Hat