Hi,
On Saturday, 9 December 2006 16:35, Rafael J. Wysocki wrote:
> On Saturday, 9 December 2006 00:36, Pavel Machek wrote:
> > Hi!
> >
> > > > > I wonder if we should start a test suite ;-).
> > > > >
> > > > > > This means, however, that with this patch the behavior of a process
> > > > > > (g
Hi,
On Saturday, 9 December 2006 00:36, Pavel Machek wrote:
> Hi!
>
> > > > I wonder if we should start a test suite ;-).
> > > >
> > > > > This means, however, that with this patch the behavior of a process
> > > > > (gdb)
> > > > > after the resume may be different to its normal behavior, whi
Hi!
> > > I wonder if we should start a test suite ;-).
> > >
> > > > This means, however, that with this patch the behavior of a process
> > > > (gdb)
> > > > after the resume may be different to its normal behavior, which is
> > > > wrong.
> > >
> > > Yep.
>
> Okay, I think I know what to d
Hi,
On Friday, 8 December 2006 12:49, Rafael J. Wysocki wrote:
> On Friday, 8 December 2006 12:21, Pavel Machek wrote:
> > Hi!
> >
> > > > > > > ...after resume.
> > > > > >
> > > > > > This is because of how signal_wake_up() works, I think..
> > > > > >
> > > > > > > But I think it is right ap
Hi,
On Friday, 8 December 2006 12:49, Rafael J. Wysocki wrote:
> On Friday, 8 December 2006 12:21, Pavel Machek wrote:
> > Hi!
> >
> > > > > > > ...after resume.
> > > > > >
> > > > > > This is because of how signal_wake_up() works, I think..
> > > > > >
> > > > > > > But I think it is right ap
Hi,
On Friday, 8 December 2006 12:21, Pavel Machek wrote:
> Hi!
>
> > > > > > ...after resume.
> > > > >
> > > > > This is because of how signal_wake_up() works, I think..
> > > > >
> > > > > > But I think it is right approach.
> > > >
> > > > Okay, with the appended patch applied everything s
Hi!
> > > > > ...after resume.
> > > >
> > > > This is because of how signal_wake_up() works, I think..
> > > >
> > > > > But I think it is right approach.
> > >
> > > Okay, with the appended patch applied everything seems to work and I don't
> > > see any undesirable side-effects.
> >
> > I p
On Wednesday, 6 December 2006 00:45, Pavel Machek wrote:
> Hi!
>
> > > > ...after resume.
> > >
> > > This is because of how signal_wake_up() works, I think..
> > >
> > > > But I think it is right approach.
> >
> > Okay, with the appended patch applied everything seems to work and I don't
> > s
Hi!
> > > ...after resume.
> >
> > This is because of how signal_wake_up() works, I think..
> >
> > > But I think it is right approach.
>
> Okay, with the appended patch applied everything seems to work and I don't
> see any undesirable side-effects.
I promise to try it... tommorow. Looks very
Hi,
On Tuesday, 5 December 2006 23:45, Rafael J. Wysocki wrote:
> On Tuesday, 5 December 2006 23:36, Pavel Machek wrote:
> > Hi!
> >
> > > ... and it fails to freeze processes if there's a stopped task (to verify,
> > > run vi, press ^Z, and try to suspend).
> >
> > Ok, here's better version. (N
Hi,
On Tuesday, 5 December 2006 23:36, Pavel Machek wrote:
> Hi!
>
> > ... and it fails to freeze processes if there's a stopped task (to verify,
> > run vi, press ^Z, and try to suspend).
>
> Ok, here's better version. (Notice it only differs by one bit ;-).
>
> Ok, something is still weird. B
Hi!
> ... and it fails to freeze processes if there's a stopped task (to verify,
> run vi, press ^Z, and try to suspend).
Ok, here's better version. (Notice it only differs by one bit ;-).
Ok, something is still weird. Bash reports spurious...
[2]+ Stopped vi
...after resume.
On Tuesday, 5 December 2006 23:19, Pavel Machek wrote:
> Hi!
>
> > > Actually, what do you think about this patch? It removes special
> > > handling of TASK_TRACED, and should do the trick, too...
> > >
> > > diff --git a/kernel/power/process.c b/kernel/power/process.c
> > > index 7bcc976..d56e49
Hi!
> > Actually, what do you think about this patch? It removes special
> > handling of TASK_TRACED, and should do the trick, too...
> >
> > diff --git a/kernel/power/process.c b/kernel/power/process.c
> > index 7bcc976..d56e494 100644
> > --- a/kernel/power/process.c
> > +++ b/kernel/power/proc
On Tuesday, 5 December 2006 22:26, Rafael J. Wysocki wrote:
> On Tuesday, 5 December 2006 22:03, Rafael J. Wysocki wrote:
> > Okay, I have replaced my [1/2] with the patch below ...
> >
> > On Tuesday, 5 December 2006 11:34, Pavel Machek wrote:
<--snip-->
>
> Well, now the task that was stopped b
On Tuesday, 5 December 2006 22:03, Rafael J. Wysocki wrote:
> Okay, I have replaced my [1/2] with the patch below ...
>
> On Tuesday, 5 December 2006 11:34, Pavel Machek wrote:
<--snip-->
> ... and it fails to freeze processes if there's a stopped task (to verify,
> run vi, press ^Z, and try to s
Hi,
Okay, I have replaced my [1/2] with the patch below ...
On Tuesday, 5 December 2006 11:34, Pavel Machek wrote:
> Hi!
>
> > Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
> > considered by the freezer as unfreezeable. However, there may be a race
> > between the
Hi,
On Tuesday, 5 December 2006 16:27, Pavel Machek wrote:
> Hi!
>
> > > >(2) the race between the delivery of
> > > > the continuation signal and the freezer is damn hard to trigger (still
> > > > I think
> > > > I can wirte some artificial code that would trigger this, although it
> > > > wou
Hi!
> > >(2) the race between the delivery of
> > > the continuation signal and the freezer is damn hard to trigger (still I
> > > think
> > > I can wirte some artificial code that would trigger this, although it
> > > would
> > > involve a kernel thread sending SIGCONT to a user space process -
Hi,
On Tuesday, 5 December 2006 15:26, Rafael J. Wysocki wrote:
> On Tuesday, 5 December 2006 15:12, Pavel Machek wrote:
> > Hi!
> >
> > > > > Actually, what do you think about this patch? It removes special
> > > > > handling of TASK_TRACED, and should do the trick, too...
> > > >
> > > > I was
Hi,
On Tuesday, 5 December 2006 15:12, Pavel Machek wrote:
> Hi!
>
> > > > Actually, what do you think about this patch? It removes special
> > > > handling of TASK_TRACED, and should do the trick, too...
> > >
> > > I was surprised, but the patch seems to work okay. Can you replace
> > > your 1
Hi,
On Tuesday, 5 December 2006 15:13, Pavel Machek wrote:
> Hi!
>
> > > Actually, what do you think about this patch? It removes special
> > > handling of TASK_TRACED, and should do the trick, too...
> >
> > Well, I don't think so,
>
> > > @@ -1702,7 +1702,9 @@ finish_stop(int stop_count)
Hi!
> > > Actually, what do you think about this patch? It removes special
> > > handling of TASK_TRACED, and should do the trick, too...
> >
> > I was surprised, but the patch seems to work okay. Can you replace
> > your 1/2 with this one, and see what breaks?
>
> I don't think anything will _v
Hi!
> > Actually, what do you think about this patch? It removes special
> > handling of TASK_TRACED, and should do the trick, too...
>
> Well, I don't think so,
> > @@ -1702,7 +1702,9 @@ finish_stop(int stop_count)
> > read_unlock(&tasklist_lock);
> > }
> >
> > - schedu
Hi,
On Tuesday, 5 December 2006 12:24, Pavel Machek wrote:
> Hi!
>
> > > Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it
> > > is
> > > considered by the freezer as unfreezeable. However, there may be a race
> > > between the freezer and the delivery of the continuation
Hi!
> > Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
> > considered by the freezer as unfreezeable. However, there may be a race
> > between the freezer and the delivery of the continuation signal to the task
> > resulting in the task running after we have finished
Hi,
On Tuesday, 5 December 2006 11:34, Pavel Machek wrote:
> Hi!
>
> > Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
> > considered by the freezer as unfreezeable. However, there may be a race
> > between the freezer and the delivery of the continuation signal to th
Hi!
> Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
> considered by the freezer as unfreezeable. However, there may be a race
> between the freezer and the delivery of the continuation signal to the task
> resulting in the task running after we have finished freezing
Hi!
> Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
> considered by the freezer as unfreezeable. However, there may be a race
> between the freezer and the delivery of the continuation signal to the task
> resulting in the task running after we have finished freezing
Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is
considered by the freezer as unfreezeable. However, there may be a race
between the freezer and the delivery of the continuation signal to the task
resulting in the task running after we have finished freezing other tasks.
30 matches
Mail list logo
