Re: [BUG] Code reordering in swsusp breaks suspend on SMP systems

Rafael J. Wysocki
2007-03-21T22:36:12Z

On Wednesday, 21 March 2007 23:21, Pavel Machek wrote:
> Hi!
>
> > Starting with 2.6.21-rc1 suspend to ram and disk doesn't work anymore on my system.
> >
> > I did a git-bisect and found that those commits break it:
> >
> > e3c7db621bed4afb8e231cb005057f2feb5db557 - [PATCH] [PATCH] PM: Change code ordering in main.c
> > ed746e3b18f4df18afa3763155972c5835f284c5 - [PATCH] [PATCH] swsusp: Change code ordering in disk.c
> > 259130526c267550bc365d3015917d90667732f1 - [PATCH] [PATCH] swsusp: Change code ordering in user.c
> >
>
> (Yep, it was in my "to analyze" queue).
>
> > I already reported about it, but now i know the reason why suspend breaks.
> >
> > The problem is that both cpu_up/cpu_down were allowed to sleep until now,
> > and it did work because those functions could be called only in process context
> > (the one that writes to /sys/devices/system/cpu/cpu*/online) or idle thread that does smp_init()).
> >
> > But now they are called _after_ all tasks were suspended, so if cpu_down tries for example to take a lock
> > that is taken by different process, it can't since the different proccess is frozen and can't release the lock.
> >
>
> Thanks for detailed explanation.
>
> ...but, on my machine suspend works ok in -rc4. I'm not seeing this.
>
> ...by design, "frozen" tasks must not hold any locks. If frozen task
> holds a lock, that's a bug.
>
> > Or, it is also possible to revert this change.
>
> Are you using xfs?

Well, this is the only case that can trigger it. There are no other freezable
workqueues.

Greetings,
Rafael