Cc: Andi Kleen <andi@...>, Jeremy Fitzhardinge <jeremy@...>, dean gaudet <dean@...>, Nick Piggin <nickpiggin@...>, Xen-devel <xen-devel@...>, <Morten@...>, Linux Kernel Mailing List <linux-kernel@...>, Bøgeskov <xen-users@...>, <xfs@...>, <xfs-masters@...>, Mark Williamson <mark.williamson@...>
On Tue, Oct 23, 2007 at 08:32:25AM +1000, David Chinner wrote:
We had a fairly nasty bug a couple of years ago with such
a mapping that took months to track down. Luckily we had
help from a hardware debug lab, without that it would have
been very near impossible. But just stabilizing the problem was
a nightmare.
You will only see problems if the memory you're still mapping
will be allocated by someone who turns it into an uncached
mapping. And even then it doesn't happen always because
the CPU does not always do the necessary prefetches.
Also the corruption will not be on the XFS side,
but on the uncached mapping so typically some data sent
to some device gets a few corrupted cache line sized blocks.
Depending on the device this might also not be fatal -- e.g.
if it is texture data some corrupted pixels occasionally are
not that visible. But there can be still cases where
it can cause real failures when it hits something critical
(the failures were it was tracked down was usually it hitting
some command ring and the hardware erroring out)
Also every time I broke change_page_attr() flushing (which
handles exactly this problem and is tricky so it got broken
a few times) I eventually got complaints/reports from some users who ran
into such data inconsistencies. Given it was mostly from closed
3d driver users who seem to be most aggressive in using
uncached mappings. But with more systems running more aggressive
3d drivers it'll likely get worse.
That doesn't mean it is correct.
Basically you're saying: I don't care if I corrupt device driver
data. That's not a very nice thing to say.
Critical perhaps, but also broken.
And if it's that big a problem would it be really that difficult
to change only the time critical paths using it to not? I assume
it's only the directory code where it is a problem? That would
be likely even faster in general.
You could always just keep around an array of the pages and
then drop the reference count after unmap. Or walk the vmalloc mapping
and generate such an array before freeing, then unmap and then
drop the reference counts.
Or the other alternative would be change the time critical code
that uses it to not.
-Andi
-
