suspend2 with smp

From: Pavel Machek
Date: Thu Aug 12 2004 - 17:06:34 EST


Hi!

At some point I claimed that SMP support in suspend2 is "probably
broken". I guess I should post more data:

It is broken in theory.

+/*
+ * Save and restore processor state for secondary processors.
+ * IRQs (and therefore preemption) are already disabled
+ * when we enter here (IPI).
+ */
+
+void smp_suspend2_lowlevel(void * info)
+{
+ smp_mb();
+ barrier();
+ if (now_resuming) {
+ __asm__( "movl %%ecx,%%cr3\n" ::"c"(__pa(swsusp_pg_dir)));
+
+ kernel_fpu_begin();
+ atomic_inc(&suspend_cpu_counter);
+ smp_mb();
+ barrier();
#+ while ((software_suspend_state & SOFTWARE_SUSPEND_FREEZE_SMP) ||
#+ (atomic_read(&suspend_cpu_counter) != smp_processor_id())) {
#+ cpu_relax();
#+ smp_mb();
+ }
+ my_saved_context = (unsigned char *) (suspend2_saved_contexts + smp_processor_id());
+ for (loop = sizeof(struct suspend2_saved_context); loop--; loop)
+ *(((unsigned char *) &suspend2_saved_context) + loop - 1) = *(my_saved_context + loop - 1);
+ restore_processor_context();
+ FLUSH_LOCAL_TLB();
+ atomic_dec(&suspend_cpu_counter);

CPU is basically looping in loop marked by #, while its memory is
being overwriten. Now, the code probably works in practice, but it
should be really written in assembly so that compiler can not do
something stupid.

Compilers are not designed to deal with their stack (etc) randomly
overwritten, so compiler may do anything it wants here. I see that -O0
may help a lot here, but it simply is not the right thing to do.

At least /* FIXME: should be rewritten to assembly */ should be added there.

Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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/