linux-toradex.git/include/linux/highmem.h, branch v2.6.38.6

highmem: Use this_cpu_xx_return() operations

2010-12-17T14:18:04+00:00

Use this_cpu operations to optimize access primitives for highmem.

The main effect is the avoidance of address calculations through the
use of a segment prefix.

V3->V4
	- kmap_atomic_idx: Do not return a value.
	- Use __this_cpu_dec without HIGHMEM_DEBUG

Cc: Peter Zijlstra 
Cc: Catalin Marinas 
Acked-by: H. Peter Anvin 
Signed-off-by: Christoph Lameter 
Signed-off-by: Tejun Heo

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