linux-kernel - Re: [Xen-devel] Re: linux-next regression: IO errors in with ext4 and xen-blkfront

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] [day] [month] [year] [list]

Message-ID: <20101027102309.GA1618@infradead.org>
Date:	Wed, 27 Oct 2010 06:23:09 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Daniel Stodden <daniel.stodden@...rix.com>
Cc:	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Jens Axboe <axboe@...nel.dk>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	"Xen-devel@...ts.xensource.com" <Xen-devel@...ts.xensource.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] Re: linux-next regression: IO errors in with ext4
 and xen-blkfront

I'm really not interested in getting into this flamewar again.

If you want to make Xen blockdevices work reliably you need to implement
a cache flush primitive in the driver.  If your cache flush primitive
also enforced ordering that's fine for data integrity, but won't help
your performance.

Note that current the _driver_ does not implement the cache flushes
correctly which is what started this thread and the previous flamewar.
If you can fix it using the existing primitive with just driver changes
that's fine - but according to
http://mail-index.netbsd.org/port-xen/2010/09/24/msg006274.html at least
the NetBSD people didn't think so.

For details on the implementation refer to the
Documentation/block/writeback_cache_control.txt file in the kernel tree,
for reasons why we got rid of barriers with their syncronization
semantics refer to various threads on -fsdevel and lkml during the past
couple of month (search your favour archive for barriers).

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