Re: [linux-pm] Is it supposed to be ok to call del_gendisk whileuserspace is frozen?

From: Nigel Cunningham
Date: Mon May 17 2010 - 03:45:23 EST


Hi.

On 17/05/10 12:22, Alan Stern wrote:
On Mon, 17 May 2010, Nigel Cunningham wrote:

I object to the patch.

Tell the patch it ought to exit once thawed, by all means.

I'm not sure what you mean. Care to explain?

I mean "Set up some sort of flag that it can look at once thawed at
resume time, and use that to tell it to exit at that point."

Doesn't the patch do exactly that? The "flag" is set by virtue of the
fact that this is part of del_gendisk -- which means the disk is being
unregistered and hence the writeback thread will exit shortly.

Make the patch unfreezeable to begin with, by all means.

That wouldn't work.

Why not?

It would be nice to know exactly why. Perhaps the underlying problem
can be fixed.

If you know a disk is going to be unregistered during resume,

How do we check that, exactly?

Well, if you can figure out that you need to go down this path at this
point in the process, you must be able to apply the same logic to come
to the same conclusion earlier in the process.

That's not true. You don't know that a device is going to be unplugged
until it actually _is_ unplugged.

Sorry - I got unregistered during suspend (instead of resume) in my head. That said, I'd argue that we should be...

1) Syncing all the data at the start of the suspend/hibernate, so there's nothing for the workthread to do if we do del_gendisk.
2) Telling things to exit if we do find the device is gone away at resume time, but not relying on the going-away happening until post process thaw, for a couple of reasons:
- Potential for races/confusion/mess etc in having $random process thawing other processes. Only the thread doing the suspend/hibernate should be freezing/thawing.
- We're dealing with the symptom, not the cause. Almost always a bad idea.

Regards,

Nigel
--
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/