Dave Chinner wrote:
> I really don't care about the OOM Killer corner cases - it's
> completely the wrong way line of development to be spending time on
> and you aren't going to convince me otherwise. The OOM killer a
> crutch used to justify having a memory allocation subsystem that
> can't provide forward progress guarantee mechanisms to callers that
> need it.
I really care about the OOM Killer corner cases, for I'm
(1) seeing trouble cases which occurred in enterprise systems
under OOM conditions
(2) trying to downgrade OOM "Deadlock or Genocide" attacks (which
an unprivileged user with a login shell can trivially trigger
since Linux 2.0) to OOM "Genocide" attacks in order to allow
OOM-unkillable daemons to restart OOM-killed processes
(3) waiting for a bandaid for (2) in order to propose changes for
mitigating OOM "Genocide" attacks (as bad guys will find how to
trigger OOM "Deadlock or Genocide" attacks from changes for
mitigating OOM "Genocide" attacks)
I started posting to linux-mm ML in order to make forward progress
about (1) and (2). I don't want the memory allocation subsystem to
lock up an entire system by indefinitely disabling memory releasing
mechanism provided by the OOM killer.
> I've proposed a method of providing this forward progress guarantee
> for subsystems of arbitrary complexity, and this removes the
> dependency on the OOM killer for fowards allocation progress in such
> contexts (e.g. filesystems). We should be discussing how to
> implement that, not what bandaids we need to apply to the OOM
> killer. I want to fix the underlying problems, not push them under
> the OOM-killer bus...
I'm fine with that direction for new kernels provided that a simple
bandaid which can be backported to distributor kernels for making
OOM "Deadlock" attacks impossible is implemented. Therefore, I'm
discussing what bandaids we need to apply to the OOM killer.
_______________________________________________
xfs mailing list
xfs@xxxxxxxxxxx
http://oss.sgi.com/mailman/listinfo/xfs
