linux-stable.git/include/linux/highmem.h, branch linux-2.6.37.y

include/linux/highmem.h needs hardirq.h

2010-11-12T15:55:30+00:00

Commit 3e4d3af501cc ("mm: stack based kmap_atomic()") introduced the
kmap_atomic_idx_push() function which warns on in_irq() with
CONFIG_DEBUG_HIGHMEM enabled.  This patch includes linux/hardirq.h for
the in_irq definition.

Signed-off-by: Catalin Marinas 
Acked-by: Peter Zijlstra 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: fix race in kunmap_atomic()

2010-10-28T01:03:05+00:00

Christoph reported a nice splat which illustrated a race in the new stack
based kmap_atomic implementation.

The problem is that we pop our stack slot before we're completely done
resetting its state -- in particular clearing the PTE (sometimes that's
CONFIG_DEBUG_HIGHMEM).  If an interrupt happens before we actually clear
the PTE used for the last slot, that interrupt can reuse the slot in a
dirty state, which triggers a BUG in kmap_atomic().

Fix this by introducing kmap_atomic_idx() which reports the current slot
index without actually releasing it and use that to find the PTE and delay
the _pop() until after we're completely done.

Signed-off-by: Peter Zijlstra 
Reported-by: Christoph Hellwig 
Acked-by: Rik van Riel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm,x86: fix kmap_atomic_push vs ioremap_32.c

2010-10-28T01:03:05+00:00

It appears i386 uses kmap_atomic infrastructure regardless of
CONFIG_HIGHMEM which results in a compile error when highmem is disabled.

Cure this by providing the needed few bits for both CONFIG_HIGHMEM and
CONFIG_X86_32.

Signed-off-by: Peter Zijlstra 
Reported-by: Chris Wilson 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: stack based kmap_atomic()

2010-10-26T23:52:08+00:00

Keep the current interface but ignore the KM_type and use a stack based
approach.

The advantage is that we get rid of crappy code like:

	#define __KM_PTE			\
		(in_nmi() ? KM_NMI_PTE : 	\
		 in_irq() ? KM_IRQ_PTE :	\
		 KM_PTE0)

and in general can stop worrying about what context we're in and what kmap
slots might be appropriate for that.

The downside is that FRV kmap_atomic() gets more expensive.

For now we use a CPP trick suggested by Andrew:

  #define kmap_atomic(page, args...) __kmap_atomic(page)

to avoid having to touch all kmap_atomic() users in a single patch.

[ not compiled on:
  - mn10300: the arch doesn't actually build with highmem to begin with ]

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: fix up drivers/gpu/drm/i915/intel_overlay.c]
Acked-by: Rik van Riel 
Signed-off-by: Peter Zijlstra 
Acked-by: Chris Metcalf 
Cc: David Howells 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Steven Rostedt 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: David Miller 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Cc: Dave Airlie 
Cc: Li Zefan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: strictly nested kmap_atomic()

2010-10-26T23:52:08+00:00

Ensure kmap_atomic() usage is strictly nested

Signed-off-by: Peter Zijlstra 
Reviewed-by: Rik van Riel 
Acked-by: Chris Metcalf 
Cc: David Howells 
Cc: Hugh Dickins 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Steven Rostedt 
Cc: Russell King 
Cc: Ralf Baechle 
Cc: David Miller 
Cc: Paul Mackerras 
Cc: Benjamin Herrenschmidt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

gcc-4.6: mm: fix unused but set warnings

2010-08-10T03:44:58+00:00

No real bugs, just some dead code and some fixups.

Signed-off-by: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

kmap_atomic: make kunmap_atomic() harder to misuse

2010-08-10T03:44:54+00:00

kunmap_atomic() is currently at level -4 on Rusty's "Hard To Misuse"
list[1] ("Follow common convention and you'll get it wrong"), except in
some architectures when CONFIG_DEBUG_HIGHMEM is set[2][3].

kunmap() takes a pointer to a struct page; kunmap_atomic(), however, takes
takes a pointer to within the page itself.  This seems to once in a while
trip people up (the convention they are following is the one from
kunmap()).

Make it much harder to misuse, by moving it to level 9 on Rusty's list[4]
("The compiler/linker won't let you get it wrong").  This is done by
refusing to build if the type of its first argument is a pointer to a
struct page.

The real kunmap_atomic() is renamed to kunmap_atomic_notypecheck()
(which is what you would call in case for some strange reason calling it
with a pointer to a struct page is not incorrect in your code).

The previous version of this patch was compile tested on x86-64.

[1] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
[2] In these cases, it is at level 5, "Do it right or it will always
    break at runtime."
[3] At least mips and powerpc look very similar, and sparc also seems to
    share a common ancestor with both; there seems to be quite some
    degree of copy-and-paste coding here. The include/asm/highmem.h file
    for these three archs mention x86 CPUs at its top.
[4] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
[5] As an aside, could someone tell me why mn10300 uses unsigned long as
    the first parameter of kunmap_atomic() instead of void *?

Signed-off-by: Cesar Eduardo Barros 
Cc: Russell King  (arch/arm)
Cc: Ralf Baechle  (arch/mips)
Cc: David Howells  (arch/frv, arch/mn10300)
Cc: Koichi Yasutake  (arch/mn10300)
Cc: Kyle McMartin  (arch/parisc)
Cc: Helge Deller  (arch/parisc)
Cc: "James E.J. Bottomley"  (arch/parisc)
Cc: Benjamin Herrenschmidt  (arch/powerpc)
Cc: Paul Mackerras  (arch/powerpc)
Cc: "David S. Miller"  (arch/sparc)
Cc: Thomas Gleixner  (arch/x86)
Cc: Ingo Molnar  (arch/x86)
Cc: "H. Peter Anvin"  (arch/x86)
Cc: Arnd Bergmann  (include/asm-generic)
Cc: Rusty Russell  ("Hard To Misuse" list)
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

highmem: remove unneeded #ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT for debug_kmap_atomic()

2010-05-25T15:07:01+00:00

In f4112de6b679d84bd9b9681c7504be7bdfb7c7d5 ("mm: introduce
debug_kmap_atomic") I said that debug_kmap_atomic() needs
CONFIG_TRACE_IRQFLAGS_SUPPORT.

It was wrong.  (I thought irqs_disabled() is only available when the
architecture has CONFIG_TRACE_IRQFLAGS_SUPPORT)

Remove the #ifdef CONFIG_TRACE_IRQFLAGS_SUPPORT check to enable
kmap_atomic() debugging for the architectures which do not have
CONFIG_TRACE_IRQFLAGS_SUPPORT.

Reported-by: Andrew Morton 
Signed-off-by: Akinobu Mita 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/xfs-vipt

2010-02-27T01:05:10+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/xfs-vipt:
  xfs: fix xfs to work with Virtually Indexed architectures
  sh: add mm API for DMA to vmalloc/vmap areas
  arm: add mm API for DMA to vmalloc/vmap areas
  parisc: add mm API for DMA to vmalloc/vmap areas
  mm: add coherence API for DMA to vmalloc/vmap areas

mm: add coherence API for DMA to vmalloc/vmap areas

2010-01-25T17:42:20+00:00

On Virtually Indexed architectures (which don't do automatic alias
resolution in their caches), we have to flush via the correct
virtual address to prepare pages for DMA.  On some architectures
(like arm) we cannot prevent the CPU from doing data movein along
the alias (and thus giving stale read data), so we not only have to
introduce a flush API to push dirty cache lines out, but also an invalidate
API to kill inconsistent cache lines that may have moved in before
DMA changed the data

Signed-off-by: James Bottomley