Re: Sigcontext->sc_pc Passed to User

[Ralf Baechle <ralf@oss.sgi.com>]

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.

  Ralf