summaryrefslogtreecommitdiff
path: root/sound
diff options
context:
space:
mode:
authorNicolas Pitre <nico@cam.org>2009-09-01 22:01:27 +0100
committerAlejandro Gonzalez <alex.gonzalez@digi.com>2010-05-25 11:01:41 +0200
commit45a01d35e998583185b5652313dc754e3f1dcd7a (patch)
tree6dc6d0fe3a2685224b97d84f0b9d8373b6a2667c /sound
parent961d0936463a313bdbce677b750f2cba61a3fd99 (diff)
ARM: 5687/1: fix an oops with highmem
In xdr_partial_copy_from_skb() there is that sequence: kaddr = kmap_atomic(*ppage, KM_SKB_SUNRPC_DATA); [...] flush_dcache_page(*ppage); kunmap_atomic(kaddr, KM_SKB_SUNRPC_DATA); Mixing flush_dcache_page() and kmap_atomic() is a bit odd, especially since kunmap_atomic() must deal with cache issues already. OTOH the non-highmem case must use flush_dcache_page() as kunmap_atomic() becomes a no op with no cache maintenance. Problem is that with highmem the implementation of kmap_atomic() doesn't set page->virtual, and page_address(page) returns 0 in that case. Here flush_dcache_page() calls __flush_dcache_page() which calls __cpuc_flush_dcache_page(page_address(page)) resulting in a kernel oops. None of the kmap_atomic() implementations uses set_page_address(). Hence we can assume page_address() is always expected to return 0 in that case. Let's conditionally call __cpuc_flush_dcache_page() only when the page address is non zero, and perform that test only when highmem is configured. Signed-off-by: Nicolas Pitre <nico@marvell.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Alejandro Gonzalez <alex.gonzalez@digi.com>
Diffstat (limited to 'sound')
0 files changed, 0 insertions, 0 deletions