aboutsummaryrefslogtreecommitdiffstats
path: root/arch/arm/configs/jornada720_defconfig
diff options
context:
space:
mode:
authorNicolas Pitre <nico@cam.org>2009-09-03 21:45:59 +0100
committerRussell King <rmk+kernel@arm.linux.org.uk>2009-09-04 19:20:07 +0100
commit7929eb9cf643ae416e5081b2a6fa558d37b9854c (patch)
treec4cbaa5ccdd1c929eba802374d80191b6f90e16c /arch/arm/configs/jornada720_defconfig
parentc47a830c08a26a7c210ae16a0ffe3f56ba86ea69 (diff)
downloadkernel_samsung_smdk4412-7929eb9cf643ae416e5081b2a6fa558d37b9854c.zip
kernel_samsung_smdk4412-7929eb9cf643ae416e5081b2a6fa558d37b9854c.tar.gz
kernel_samsung_smdk4412-7929eb9cf643ae416e5081b2a6fa558d37b9854c.tar.bz2
ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem
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. Cc: stable@kernel.org Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Diffstat (limited to 'arch/arm/configs/jornada720_defconfig')
0 files changed, 0 insertions, 0 deletions