> i'm not convinced that you've explained why this change is
> correct or why it could solve the problem. after all, the
> NNOTED array is only 5 entries long. what if one gets 5
> user notes before the system note?
> do you kill the process (isn't this how it works now?),
> make notes unreliable
> > I'm not claiming anyone to be wrong. I want to solve
> > this problem.
>
> i'm not sure there is a problem with notes. but i really can't
> answer that question. someone with a better understanding
> of what notes are supposed to be could answer this.
>
> > I also noted that i think this is
> I'm not claiming anyone to be wrong. I want to solve
> this problem.
i'm not sure there is a problem with notes. but i really can't
answer that question. someone with a better understanding
of what notes are supposed to be could answer this.
> I also noted that i think this is the correct beh
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
> 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
> 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/tra
> > i can reproduce it with this:
> >
> > http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/
> >
> > 8c test.c
> > 8a int80.s
> > 8l test.8 int80.8
> > ./8.out
> >
> > 8.out 12490667: suicide: sys: trap: general protection violation
> > pc=0x1333
>
> okay. it seems pretty clea
> i can reproduce it with this:
>
> http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/
>
> 8c test.c
> 8a int80.s
> 8l test.8 int80.8
> ./8.out
>
> 8.out 12490667: suicide: sys: trap: general protection violation
> pc=0x1333
okay. it seems pretty clear from the code that you'r
Kernel Panic wrote:
http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/
8c test.c
8a int80.s
8l test.8 int80.8
./8.out
8.out 12490667: suicide: sys: trap: general protection violation
pc=0x1333
the parent process loops and does "fake" syscalls while
the child posts notes to it
erik quanstrom wrote:
it would also be interesting to know if you are
seeing this randomly or if you can reliable reproduce
this condition.
i can reproduce it with this:
http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/
8c test.c
8a int80.s
8l test.8 int80.8
./8.out
8.out 1249
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 ha
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
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.
T
13 matches
Mail list logo
