From: "D.J. Barrow" <barrow_dj@yahoo.com>
To: Gary Thomas <gdt@linuxppc.org>
Cc: linuxppc-dev <linuxppc-dev@lists.linuxppc.org>
Subject: I believe I found a bug in /arch/ppc/kernel/signal.c
Date: Mon, 22 Feb 1999 06:36:57 -0800 (PST) [thread overview]
Message-ID: <19990222143657.28939.rocketmail@send206.yahoomail.com> (raw)
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 ]]
next reply other threads:[~1999-02-22 14:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-02-22 14:36 D.J. Barrow [this message]
1999-02-22 18:53 ` I believe I found a bug in /arch/ppc/kernel/signal.c Benjamin Herrenschmidt
1999-02-23 14:35 ` Lauro Whately
-- strict thread matches above, loose matches on Subject: below --
1999-02-24 12:45 D.J. Barrow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19990222143657.28939.rocketmail@send206.yahoomail.com \
--to=barrow_dj@yahoo.com \
--cc=gdt@linuxppc.org \
--cc=linuxppc-dev@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.