Skip to content

L
linux-davinci
Switch branch/tag
  1. 04 Sep, 2009 1 commit
    • Nicolas Pitre's avatar
      ARM: 5691/1: fix cache aliasing issues between kmap() and kmap_atomic() with highmem · 7929eb9c
      Nicolas Pitre authored 
      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: default avatarNicolas Pitre <nico@marvell.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      7929eb9c
  3. 02 Sep, 2009 2 commits
    • Dick Hollenbeck's avatar
      ARM: 5688/1: ks8695_serial: disable_irq() lockup · c47a830c
      Dick Hollenbeck authored 
      disable_irq() cannot be called from interrupt context without self imposed deadlock. This was happening in ks8695uart_stop_tx().
Signed-off-by: default avatarDick Hollenbeck <dick@softplc.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      c47a830c
    • Nicolas Pitre's avatar
      ARM: 5687/1: fix an oops with highmem · 13f96d8f
      Nicolas Pitre authored 
      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: default avatarNicolas Pitre <nico@marvell.com>
Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      13f96d8f
  5. 01 Sep, 2009 6 commits
  7. 31 Aug, 2009 10 commits
  9. 30 Aug, 2009 2 commits
  11. 29 Aug, 2009 6 commits
  13. 28 Aug, 2009 7 commits
  15. 27 Aug, 2009 6 commits