[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100922195349.GF19804@ZenIV.linux.org.uk>
Date: Wed, 22 Sep 2010 20:53:49 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: David Miller <davem@...emloft.net>, akpm@...ux-foundation.org,
sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT] Sparc
On Wed, Sep 22, 2010 at 12:08:53PM -0700, Linus Torvalds wrote:
> On Wed, Sep 22, 2010 at 11:53 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
> >
> > Um, no. ?You've *already* called get_signal_to_deliver(). ?There had been
> > no SIGSEGV in sight. ?You happily went on to set a sigframe for e.g.
> > SIGHUP, but ran out of stack. ?At that point you get force_sigsegv()
> > from handle_signal(). ?_NOW_ you have a pending SIGSEGV
>
> Ahh. Ok. Different case from the one I thought you were worried about.
> And yeah, I guess that one does require us to mess with the low-level
> asm code (although I do wonder if we could not make the whole
> do_notify_resume + reschedule code be generic C code - it's a lot of
> duplicated subtle asm as it is).
Worse than just that... Note that on sparc you need to deal with
fault_in_user_windows(), which can also trigger signals. So much
for merging it cross-architecture, even if we ignore the differences
between the ways we pass data required for restart to do_signal().
Note that e.g. on alpha we pass _two_ values - one for overwritten
v0 (syscall number), another for overwritten a3 (error flag), etc.
Worse, quite a few targets do not save all registers on syscall entry.
Callee-saved stuff doesn't have to be in pt_regs. Except that you
want *all* of them saved on stack when it's time to fill sigframes.
And once you've entered a C function you can't guarantee that compiler
hasn't already modified them; sure, they'll be restored on return, but
that doesn't help you to get to their values. So you get switch_stack
built on stack around calling do_notify_resume() on those. And you
really want to avoid doing that if you've got no signals - remember,
we hit that on exit from irqs as well, so it's one hell of a hot path.
For processors with big flat register file it can get very ugly.
There is a lot of ugly almost-duplication in there, no arguments about that.
Asm glue is actually not the worst part...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists