 Up |
|
|
  |
Author: Kernel PanicKernel Panic Date: Aug 28, 2008 06:27
I run into an interesting problem with linuxemu.
The problem *seems* to be that traps can be
enqueued in the process note array *after* some
other note causing notify() to kill us.
Please correct me if i miss(understand) something
here. It just hit my mind after hours of late night
debugging.
The case:
If some other process sends a note with postnote(). The
kernel will enqueue the note in the target process.
(The note is marked as Nuser)
notestate of the target process:
note[0] = {Nuser, "usernote"}
nnote = 1
notified = 0
This note will be "delivered" when notify() is called.
notify is called on:
- after a syscall
- after interrupt/trap handling (timer interrupt?)
|
| Show full article (2.24Kb) |
|
| | 12 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Aug 28, 2008 07:14
it looks like you get the second trap while
you are still in your notify handler, since
i think this test
(up->notified || up->notify==0)
is for a proc in a notify handler getting a system
trap (or a proc with no notify handler).
it would be very interesting to know what the system
trap is. it would also be interesting to know if you are
seeing this randomly or if you can reliable reproduce
this condition.
- erik
|
| |
|
| | no comments |
|
|
Author: Kernel PanicKernel Panic Date: Aug 28, 2008 08:38
erik quanstrom wrote:
> it looks like you get the second trap while
> you are still in your notify handler, since
> i think this test
> (up->notified || up->notify==0)
> is for a proc in a notify handler getting a system
> trap (or a proc with no notify handler).
>
right, the problem is, my note handler never sees the
*real* trap. the message passed to the notehandler is the
string posted from the other process. "sig" in the case
of linuxemu. the ureg has the trap field set to 0xD. the
pc is right on the INT 0x80 instruction., but we get the
"sig", not "sys: trap: general protection ..."
(Of course! because that was the context/event that brougth
it into the kernel in the first place. But i think it picked the wrong
note for delivery, and keeps the NDebug note pending.)
|
| Show full article (1.42Kb) |
| no comments |
|
|
Author: Kernel PanicKernel Panic Date: Aug 29, 2008 03:07
erik quanstrom wrote:
> it would also be interesting to know if you are
> seeing this randomly or if you can reliable reproduce
> this condition.
>
> - erik
>
--
cina
--
cinap
|
| |
| 8 Comments |
|
|
Author: Kernel PanicKernel Panic Date: Aug 29, 2008 03:13
Kernel Panic wrote:
arg... swap parent <-> child... but you'll see it in the code.
--
cinap
|
| |
| no comments |
|
|
Author: erik quanstromerik quanstrom Date: Aug 29, 2008 11:30
okay. it seems pretty clear from the code that you're dead meat
if you receive a note while you're in the note handler. that is,
up->notified = 1. it looks pretty clear that this is intentional.
i don't see why one couldn't get 3-4 note before the note handler
is called, however.
given this, calling sleep() from the note handler is an especially
bad idea.
|
| Show full article (1.14Kb) |
| 7 Comments |
|
|
Author: cinap_lenrekcinap_lenrek Date: Aug 29, 2008 19:22
> From: cinap_lenrek@gmx.de
> Subject: Re: [9fans] notes and traps
> Date: Fri, 29 Aug 2008 14:26:48 -0400
>
> okay. it seems pretty clear from the code that you're dead meat
> if you receive a note while you're in the note handler. that is,
> up->notified = 1. it looks pretty clear that this is intentional.
> i don't see why one couldn't get 3-4 note before the note handler
> is called, however. ...
|
| Show full article (4.52Kb) |
| 6 Comments |
|
|
Author: erik quanstromerik quanstrom Date: Aug 29, 2008 20:38
> No! Notes are bufferd in the up->note[] array. If you are in the note handler,
> another process *can* send you further (NUser) notes without doing any harm.
>
> If we are in the note handler (up->notified == 1) and notify() gets hit,
> it will do nothing and return 0 see:
>
> /sys/src/9/pc/trap.c: notify()
> ...
> if(n->flag!=NUser && (up->notified || up->notify==0)){
> if(n->flag == NDebug)
> pprint("suicide: %%sn", n->msg);
> qunlock(&up->debug);
> pexit(n->msg, n->flag!=NDebug);
> }
>
> if(up->notified){
> qunlock(&up->debug);
> splhi();
> return 0;
> } ...
|
| Show full article (1.83Kb) |
| 5 Comments |
|
|
Author: cinap_lenrekcinap_lenrek Date: Aug 29, 2008 22:51
> i think you may be misunderstanding what i'm saying.
> the test for n->flag does not appear to be accidental.
> i am not quite sure why that test is there, but i go on
> the assumption that presotto knew what he was doing.
> if you're going to claim he was wrong, i think you'd better
> have good reasons.
I'm not claiming anyone to be wrong. I want to solve
this problem.
> including explaining why it's okay
> to not terminate a process which has not handed a system
> note when it gets another.
which has not handled what? All it checks is if here is *any* note
handled currently. And if the *next* note to be handled is
a system note.
If here are any other implications in the check i dont see
here please tell.
|
| Show full article (2.35Kb) |
| 4 Comments |
|
|
|
|
|
Author: Steve SimonSteve Simon Date: Aug 30, 2008 03:56
purely as an aside
this detailed conversation on how notes are handled in the
kernel is very interesting, I was trying to understand this myself
recently and gave up; I will now try again.
Thanks,
-Steve
|
| |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
