2.6.17-mm3: swsusp fails when process is debugged by ptrace

If I try to suspend the machine while a process debug-stopped by ptrace, suspend fails:

PM: Preparing system for mem sleep
Freezing cpus ...
Breaking affinity for irq 0
Breaking affinity for irq 1
Breaking affinity for irq 12
Breaking affinity for irq 23
CPU 1 is now offline
SMP alternatives: switching to UP code
CPU1 is down
Stopping tasks:
==========================================================================================================================================================
stopping tasks timed out after 20 seconds (13 tasks remaining):
khubd
kseriod
pdflush
pdflush
kswapd0
kprefetchd
pccardd
kirqd
kjournald
kauditd
knodemgrd_0
kjournald
test-vsnprintf
Restarting tasks...<6> Strange, khubd not stopped Strange, kseriod not stopped
Strange, pdflush not stopped
Strange, pdflush not stopped
Strange, kswapd0 not stopped
Strange, kprefetchd not stopped
Strange, pccardd not stopped
Strange, kirqd not stopped
Strange, kjournald not stopped
Strange, kauditd not stopped
Strange, knodemgrd_0 not stopped
Strange, kjournald not stopped
Strange, test-vsnprintf not stopped
done
Thawing cpus ...

In this case, test-vsnprintf is stopped in a breakpoint in gdb. If I quit it, then suspend works as expected.

Does it also happen when you do strace? ...I remember trying to solve that, but 2.6.17-mm3 is very recent...?

Quoted 2 lines

Does it also happen when you do strace? ...I remember trying to solve that, but 2.6.17-mm3 is very recent...?

I could suspend while running "strace sleep 100" without any problem.

I think the issue is when the process is blocked in T state, freeze_process() tries to kick the process with signal_wake_up(p, /* resume=0 */ 0), but with resume=0 it will only wake processes in TASK_INTERRUPTIBLE state. With resume=1, it will also kick STOPPED and TRACED processes. I also tried suspending while I had a process in T state caused by kill -STOP, and that worked, so some part of the puzzle is still missing.

I noticed that when I ran sleep 100 under strace over the suspend/resume cycle, its nanosleep() syscall was interrupted and not restarted.

So... does signal_wake_up(p, 1) fix it?

I'm afraid there may be more problems lurking in the refrigerator.

(If this is going to take more than few mail iterations... perhaps you should start bug at bugzilla.kernel.org?)