linux-kernel - Re: [PATCH] libata, freezer: avoid block device removal while system is frozen

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131216160542.GG32509@htj.dyndns.org>
Date:	Mon, 16 Dec 2013 11:05:42 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Ming Lei <tom.leiming@...il.com>
Cc:	Nigel Cunningham <nigel@...elcunningham.com.au>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Jens Axboe <axboe@...nel.dk>, tomaz.solc@...lix.org,
	aaron.lu@...el.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [PATCH] libata, freezer: avoid block device removal while system
 is frozen

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/