Re: [RFC] Fix SMP brokenness for PF_FREEZE and make freezing usablefor other purposes

[Christoph Lameter]

On Tue, 28 Jun 2005, Kirill Korotaev wrote:

> > > <<<< is it intentionaly? or you just lost CONFIG_MIGRATE?
> > It is intentional. freeze_processes and thaw_processes are only needed for
> > suspend. One only needs to freeze a couple of processes for process
> > migration.
> But PM and your migrate code can be not the only users of it.

freeze_processes and thaw_processes is not needed by the migrate 
code.

> > Hmm... If we wait to clear both flags until after the completion
> > notification then we do not have the race right? But then we need to move
> > the signal recalc since it tests for TIF_FREEZE too.
> It is almost ok, but it is still not fine :)
> 
> look what happens if you call freeze/unfreeze in a loop:
> 
> refrigerator:
> awakes
> 
> freezer:
> check PF_FROZEN, it is still set, skips task and thinks it is finished
> freezing.
> 
> refrigerator:
> clears PF_FROZEN and TIF_FREEZE and returns.
> 
> I think you can fix this by moving PF_FROZEN check and set in both places
> under siglock.

I do not think this is necessary because 
freezing and awakening are not done concurrently. First you will 
freeze a number of processes (and no awakening occurs).

Then some action occurs (migration, suspend). Then complete_all 
is invoked. No freezing occurs during the awakening period.

It would be great if you can fix this issue with a patch. But taking a 
lock only makes sense if you can use it to coordinate multiple updates
of variables. I.e. take siglock for clearing PF_FROZEN and TIF_FREEZE and
then use it while checking the state of PF_FROZEN and TIF_FREEZE.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/