Re: SMP suspend broken due to "swsusp: Change code ordering in disk.c" et al.

[Johannes Berg <johannes@sipsolutions.net>]

[-- Attachment #1.1: Type: text/plain, Size: 2054 bytes --]

[correcting address for Nigel]

Hi Rafael,

> Hm, the only freezable workqueues I was aware of were those in XFS.

Well, I have an XFS root fs. In fact, the one that was mostly causing it
was the xfs one, but I'm not sure it was all the time. The same bug
happens at resume time (if I manually offline all nonboot CPUs before
suspend), at which point I couldn't tell whether it was XFS or something
else.

> Moreover, the patch has got _a_ _lot_ of testing on SMP on x86_64
> and I believe it works for people on i386 too.  So the workqueues in question
> seem to be architecture-specific.  Is that correct?

There could be some arch-specific workqueues as well, but at least in
one case I saw xfsdatad causing it.

> > (1) would work, but also only punts the problem until someone wants to
> > do multi-threaded suspend (as if...).
> 
> It will also break symmetry with the resume code that has to be like this
> because of ACPI-related issues.

Ok. I don't have any ACPI issues due to the lack of ACPI ;)

> > (2a) would sort-of work, but what if someone unplugs a CPU while the
> > system is suspended [will that even work]? the thread would get really
> > stuck there, bound to a CPU that no longer exists.
> 
> Right now we are working on using the task freezer for CPU hotplugging and if
> that works, this won't be an issue.

Care to elaborate? It doesn't seem to make sense to freeze tasks that
are running on some other CPU if that one is going offline, but I'm
probably misunderstanding you here.
 
> I'd like to first understand why the workqueues in question here are freezable.

I don't think that matters much. We can't have freezable per-CPU
workqueues and then forbid using them.

> Could you please check if the appended patch (on top of the commit you have
> reverted) changes anything?

I can give it a go, but it doesn't look as though it'd help. It still
freezes all threads before disabling CPUs, and my debugging certainly
pinpointed to kthread_stop() in the workqueue.

johannes

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]