Hi!
> > > - freeze(p);
> > > + set_thread_flag(TIF_FREEZE);
> >
> > Shouldn't that be "set_ti_thread_flag(p->thread_info, TIF_FREEZE)"?
> > Otherwise you freeze current, not the thread "p".
>
> Correct. Which also means that we have not progressed yet beyond an
> academic version of the patch:
>
> ---
>
> Revise handling of freezing in the suspend code
>
> The current suspend code modifies thread flags from outside the context of process.
> This creates a SMP race.
>
> The patch fixes that by introducing a TIF_FREEZE flag (for all arches). Also
>
> - Uses a completion handler instead of waiting in a schedule loop in the refrigerator.
>
> - Introduces a semaphore freezer_sem to provide a way that multiple kernel
> subsystems can use the freezing ability without interfering with one another.
>
> - Include necessary definitions for the migration code if CONFIG_MIGRATE is set.
>
> - Removes PF_FREEZE
>
> Signed-off-by: Christoph Lameter <[email protected]>
This patch breaks suspend for me (first suspend works, second suspend
fails to freeze processes). [I was offline, that's why it took so
long.]
I see patches 1/2 and 2/2 submitted; if you still feel I should apply
some of them, tell me.
Pavel
--
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |