I believe I found a bug in /arch/ppc/kernel/signal.c

I believe I found a bug in /arch/ppc/kernel/signal.c

[D.J. Barrow]

Hi Gary/Others,
I'm currently using 2.1.123 ( yup I know this is old but the bug on
reading the source is still in 2.1.124 DR4 ) & possibly is still
there. Unfortunately my net connection isn't good enough to download
the latest 2.2 stuff in less than a few hours.

The bug manifested itself in tftp, when longjmp'ing out
of the signal handler on timeouts.

Resulting in....
a )sys_sigreturn not get called 
b) signals queued & trampoline stuff on the user stack being trashed.
c) SIGALRM being blocked forever.

The stuff works on intel & it also works if I kludge handle signal not
to block SIGALRM.

I originally thought fixing longjmp with a syscall would be a good
idea on conversing with other hackers it isn't.

The code here I believe can be simplified if you didn't do all the
queueing in handle_signal & remove the while/dequeue loop from
do_signal & make do_signal also work as sys_sigreturn & unblock the
signals just before sending them, this way I don't think you'll lose
any ( however I haven't fully investigated any possible problems
caused unblocking signals before sending them ). As sys_sigreturn is
getting called for every signal delivered, there is no benefit gained
by queueing them in the first place.

If you still aren't maintaining signal.c anymore could someone forward
on this bug report.

Also could you tell me a good place where I can find some info on the
rt_signal stuff & tell me if a fix gets/already is posted....






_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: I believe I found a bug in /arch/ppc/kernel/signal.c

[Benjamin Herrenschmidt]

On Mon, Feb 22, 1999, D.J. Barrow <barrow_dj@yahoo.com> wrote:

>The bug manifested itself in tftp, when longjmp'ing out
>of the signal handler on timeouts.
>
>Resulting in....
>a )sys_sigreturn not get called 
>b) signals queued & trampoline stuff on the user stack being trashed.
>c) SIGALRM being blocked forever.

Note also that the people doing ShapeShifter (Mac runtime) told they are
having problem with alternate signal stacks. I didn't look very in depth
at the code, it looks like it's here but I didn't tested. I don't have
more details about their exact problem but if someone is going to look at
the signal stuffs, then think about eventually testing the alt stack.

(I think they need this because parts of MacOS ROM code will use R1 for
something else than stack, I love Apple ;-)

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>





[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: I believe I found a bug in /arch/ppc/kernel/signal.c

[Lauro Whately]

> On Mon, Feb 22, 1999, D.J. Barrow <barrow_dj@yahoo.com> wrote:

> The bug manifested itself in tftp, when longjmp'ing out
> of the signal handler on timeouts.
>
> Resulting in....
> a )sys_sigreturn not get called
> b) signals queued & trampoline stuff on the user stack being trashed.
> c) SIGALRM being blocked forever.

Have you tried the sigsetjmp/siglongjmp ?
I've met a similar problem a month ago and found that POSIX.1 does not
specify the effect of setjmp and longjmp on signal masks (SVR4 does not save
and restore the signal mask under  setjmp/longjmp, however 4.3 BSD save and
restore the signal mask) Instead, two new functions sigsetjmp and siglongjmp
are defined by POSIX.1
Those new ones are working ok with linux 2.1.x releases (I've been using them
with linuxppc 2.1.112)
It seems that the behavior of sigsetjmp/siglongjmp was changed to the POSIX.1
specification around the release 2.1.112.

--
 Lauro Whately
 Parallel Computing Lab. / COPPE
 Federal University of Rio de Janeiro
 Brazil
 =====================================
 "A distributed system is one on which I cannot get any work done, because a
 machine I have never heard of has crashed." -- Leslie Lamport




[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]

Re: I believe I found a bug in /arch/ppc/kernel/signal.c

[D.J. Barrow]

Thanks Lauro,

setjmp in glibc2 compiles to sigsetjmp(env,0) i.e. it doesn't save the
environment.

The sigsetjmp gets rid of the signal being blocked issue ( the main
symptom ), there still can be outstanding signals on the user stack
being trashed though.




---Lauro Whately <whately@cos.ufrj.br> wrote:
>
> > On Mon, Feb 22, 1999, D.J. Barrow <barrow_dj@yahoo.com> wrote:
> 
> > The bug manifested itself in tftp, when longjmp'ing out
> > of the signal handler on timeouts.
> >
> > Resulting in....
> > a )sys_sigreturn not get called
> > b) signals queued & trampoline stuff on the user stack being
trashed.
> > c) SIGALRM being blocked forever.
> 
> Have you tried the sigsetjmp/siglongjmp ?
> I've met a similar problem a month ago and found that POSIX.1 does not
> specify the effect of setjmp and longjmp on signal masks (SVR4 does
not save
> and restore the signal mask under  setjmp/longjmp, however 4.3 BSD
save and
> restore the signal mask) Instead, two new functions sigsetjmp and
siglongjmp
> are defined by POSIX.1
> Those new ones are working ok with linux 2.1.x releases (I've been
using them
> with linuxppc 2.1.112)
> It seems that the behavior of sigsetjmp/siglongjmp was changed to
the POSIX.1
> specification around the release 2.1.112.
> 
> --
>  Lauro Whately
>  Parallel Computing Lab. / COPPE
>  Federal University of Rio de Janeiro
>  Brazil
>  =====================================
>  "A distributed system is one on which I cannot get any work done,
because a
>  machine I have never heard of has crashed." -- Leslie Lamport
> 
> 
> 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request@lists.linuxppc.org ]]