]> git.karo-electronics.de Git - karo-tx-linux.git/commit
ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem
authorNicolas Pitre <nico@cam.org>
Thu, 3 Sep 2009 20:45:59 +0000 (21:45 +0100)
committerGreg Kroah-Hartman <gregkh@suse.de>
Thu, 24 Sep 2009 15:44:03 +0000 (08:44 -0700)
commit5a3a29fefad07ca9dd99cf4c3da55c0694084f59
treeba58910796b017bd57ceab4742a2a00f244ef3a1
parentc922ffeef36f4e90d244fbde7b123f44e77e3be2
ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem

commit 7929eb9cf643ae416e5081b2a6fa558d37b9854c upstream.

Let's suppose a highmem page is kmap'd with kmap().  A pkmap entry is
used, the page mapped to it, and the virtual cache is dirtied.  Then
kunmap() is used which does virtually nothing except for decrementing a
usage count.

Then, let's suppose the _same_ page gets mapped using kmap_atomic().
It is therefore mapped onto a fixmap entry instead, which has a
different virtual address unaware of the dirty cache data for that page
sitting in the pkmap mapping.

Fortunately it is easy to know if a pkmap mapping still exists for that
page and use it directly with kmap_atomic(), thanks to kmap_high_get().

And actual testing with a printk in the added code path shows that this
condition is actually met *extremely* frequently.  Seems that we've been
quite lucky that things have worked so well with highmem so far.

Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
arch/arm/mm/highmem.c