[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.1.10.1009300218380.25860@tp.orcam.me.uk>
Date: Thu, 30 Sep 2010 02:50:17 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...esourcery.com>
To: David Daney <ddaney@...iumnetworks.com>
cc: Al Viro <viro@....linux.org.uk>, ralf@...ux-mips.org,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: [PATCH 3/5] mips: sanitize restart logics
On Wed, 29 Sep 2010, David Daney wrote:
> > Put the original syscall number into ->regs[0] when we leave syscall
> > with error. Use it in restart logics. Everything else will have
> > it 0 since we pass through SAVE_SOME on all the ways in. Note that
> > in places like bad_stack and inllegal_syscall we leave it 0 - it's
> > not restartable.
> >
>
> IIRC Userspace getcontext/setcontext rely on regs[0] having a value of zero in
> the when the signal handlers are invoked.
Not exactly. These GNU C library functions rely on the magic value of
"1" there to recognise contexts they created themselves and which must
therefore be handled by themselves internally (these contexts are not
complete and only preserve the call-saved registers as specified by the
respective MIPS ABIs, and are therefore unsafe to be passed to the
rt_sigreturn(2) syscall). All the other values, including of course "0",
are not treated specially and the context is passed to rt_sigreturn(2) as
usually. This only matters in cases where e.g. setcontext(3) is used to
exit from or return to a signal handler.
> I haven't fully traced through the code, but I hope that this 'invariant'
> holds both before and after this patch. I think Maciej did the work on
> getcontext/setcontext, he may know for sure what the requirements are.
Thanks for the heads-up, David -- I would have surely missed this e-mail
from the flood I get. I think the change is safe as MIPS/Linux only uses
syscall numbers from 4000 up (not sure why such a non-round number was
chosen; one like 4096 would seem more appropriate to me but there you go),
so there should be no clash unless an invalid syscall number has a chance
to be stored there.
For how exactly the magic value is used please have a look at
sysdeps/unix/sysv/linux/mips/*context.S in glibc-ports and search for
"magic flag" (yes, I know these pieces of assembly butchered and mixed
with CPP mince require some mind-twistedness to parse; sorry about that,
but I tried my best and put some comments throughout so that the magic
flag is easy to find ;) ).
Maciej
--
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