On Fri, Jul 12, 2002 at 01:49:15PM +0200, Kevin D. Kissell wrote:
> Whenever it's been my design responsibility, I made forks fail if
> there wasn't enough backing store to handle the process. Frankly,
> there are limits to the degree to which an OS should compromise
> its integrity for the sake of supporting badly concieved applications,
> be they Mozilla or the SGI integrated CAD environment. But
> even if you prefer to take the "speculative" or "optimistic" model
> for handling the situation, what IRIX did was insane: When, after
> having allowed too many unsupportable forks to succeed, they
> detected deadlock in the swap system, they killed processes
> *at random*. Including system daemons. At a *minimum*,
> a system should only terminate processes belonging to the
> user (and preferably the process group) who has been granted
> speculative fork success. Anything else is a massive "breach of
> contract" for a multiuser OS.
See linux/mm/oom_kill.c:oom_kill() ...
> IMHO, if someone really wanted to fix this in the OS,
> we'd get beyond the traditional Unix "fork" model.
> And if someone really wanted to avoid the problem in Mozilla or
> an IDE, one would have all subprograms launched by a tiny
> "launcher", who would recieve instructions and data via some
> form of IPC, fork itself, and exec as appropriate.
That or more Linux specific a clone/vfork & exec approach.
> But this is getting a bit off the topic. Is anyone aware of any
> IRIX applications ported to Linux that would break if we
> corrected the signal payload semantics?
As I said we even missimplemented the IRIX semantics. In IRIX the
sc_pc field of the frame is pointing to the instruction that was causing
the signal while we try to skip over it - with all the side effects that
we're just discussing. I tried that for both trap and break instructions.
So I suggest we simply remove the compute_return_epc() calls from do_bp
and do_trap. I haven't tested this but I'd assume this would also be
the behaviour that gdb is expecting. So that would follow the example
given by Linux/i386 and IRIX and should your ISV's problem. What more could
we ask for.
I still have to look over the other exceptions that may call
compute_return_epc() but it seems we should do the same thing for all
of them and not call compute_return_epc if we're going to send a signal.