Re: [PATCH] libata, freezer: avoid block device removal while systemis frozen

[Tejun Heo]

Hello, Ming.

On Mon, Dec 16, 2013 at 09:24:40PM +0800, Ming Lei wrote:
> You mean there are still some write I/O scheduled after processes are
> frozen? by unfreezable kernel threads?

By unfreezable kernel threads, timer, bh, freezable kernel threads,
whatever really.  Please note that freezer doesn't enforce any order
in how the target tasks are frozen.  There's no mechanism to guarantee
that flusher is frozen after all other freezable tasks are frozen.
There isn't even a meachnism which guarantees flusher flushes all its
queues before getting frozen.  There's no interlocking whatsoever.
The only thing which happens is that we flush all filesystems before
freezing the kernel threads, so the queues are *likely* to be empty.

I think trying to control all IO sources using the freezer is a
fundamentally flawed idea.  There are N sources which are difficult to
track down reliably while there is *single* queue all those have to go
through, which needs to be quiesced anyway.  The only thing which
makes sense is controlling the queue.

Maybe it really is necessary for hibernation.  If so, let's please
make it something tailored for that purpose - quiesce only the ones
which are actually relevant and in the places where it's necessary.
Not this "we stopped most of the system, whatever that means, and it
feels good" thing which doesn't really solve anything while
introducing this fuzzy wishful idea of mostly stopped system and giant
lock semantics all over the place.

Thanks.

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