linux-kernel - Re: [PATCH 2/7] ext3: call blkdev_issue

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: <49D17C6A.5050603@kernel.org>
Date:	Tue, 31 Mar 2009 11:14:02 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Theodore Tso <tytso@....edu>, Tejun Heo <tj@...nel.org>,
	Chris Mason <chris.mason@...cle.com>,
	Fernando Luis Vázquez Cao 
	<fernando@....ntt.co.jp>, Jeff Garzik <jeff@...zik.org>,
	Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Nick Piggin <npiggin@...e.de>, David Rees <drees76@...il.com>,
	Jesper Krogh <jesper@...gh.cc>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	david@...morbit.com
Subject: Re: [PATCH 2/7] ext3: call blkdev_issue_flush() on fsync()

Hello,

Theodore Tso wrote:
> On Tue, Mar 31, 2009 at 10:26:58AM +0900, Tejun Heo wrote:
>> How about having something like blk_ensure_cache_flushed() which
>> issues flush iff there hasn't been any write since the last flush?
>> It'll be easy to implement and will filter out duplicate flushes in
>> most cases.
> 
> I thought about such a thing, but my concern is that while this might
> suppress most unnecessary double flushes, some intervening write from
> another process might slip in which doesn't need to be flushed out.
> In other words "in most cases" means that "in some cases" we will take
> a performance hit thanks to the duplicate flushes.  So this isn't
> something we should depend upon, although if we do detect back-to-back
> flushes, obviously we should filter them out.

Yeah, well, it all comes down to how most the "most" is.  If all
that's between the first flush and the second one are some code the
cpu has to eat through, I don't think there's high chance of an IO
going inbetween unless the IO was already there and gets scheduled
inbetween (which can be avoided).

The thing is that detecting dup is possible but missing is not.  If
flush is missing in certain corner paths, nobody would know till
somebody reviews the code.  Even when the problem triggers, it would
be rare and obscure enough to avoid proper diagnosis, so I think if
the "most" is most enough, it could be the better way to do it.  But,
then again, I'm not a FS guy, so if such thing can be guaranteed in
FSes without too much problem, no need to pull such a stunt at the
block layer.

> So if we did something like this, it would be good if we had a
> debugging option which would detect double flushes, and printk a
> warning identifying where the call sites first and second flushes (by
> function name and line number), so that filesystem developers could
> detect the double flushes, and work to eliminate them.
> 
> Does that make sense?

Yeap, that definitely sounds like a good idea.  I'll put it on my todo
list.

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/