Pavel Machek wrote:
> > The problem is that there are comparisons of pointers to task_struct when
> > deciding if the task is alive. If one task dies and other one starts, it is
> > possible (is it?) that the task structure of the newly created task resides
> > at the very address where was the
Hi!
> The problem is that there are comparisons of pointers to task_struct when
> deciding if the task is alive. If one task dies and other one starts, it is
> possible (is it?) that the task structure of the newly created task resides
> at the very address where was the dead one's, so comparing
Hi!
The problem is that there are comparisons of pointers to task_struct when
deciding if the task is alive. If one task dies and other one starts, it is
possible (is it?) that the task structure of the newly created task resides
at the very address where was the dead one's, so comparing
Pavel Machek wrote:
The problem is that there are comparisons of pointers to task_struct when
deciding if the task is alive. If one task dies and other one starts, it is
possible (is it?) that the task structure of the newly created task resides
at the very address where was the dead
As nobody responded to my previous posting
( http://www.uwsg.indiana.edu/hypermail/linux/kernel/0106.1/0219.html )
I had no other options than to try to solve a problem myself.
The problem was that linux fails to do a cleanup if a program does
vm86()/VM86_REQUEST_IRQ without VM86_FREE_IRQ (see
As nobody responded to my previous posting
( http://www.uwsg.indiana.edu/hypermail/linux/kernel/0106.1/0219.html )
I had no other options than to try to solve a problem myself.
The problem was that linux fails to do a cleanup if a program does
vm86()/VM86_REQUEST_IRQ without VM86_FREE_IRQ (see
6 matches
Mail list logo
