linux-toradex.git/fs/proc/task_mmu.c, branch v2.6.19.2

[PATCH] NOMMU: move the fallback arch_vma_name() to a sensible place

2006-09-27T15:26:15+00:00

Move the fallback arch_vma_name() to a sensible place (kernel/signal.c).

Currently it's in fs/proc/task_mmu.c, a file that is dependent on both
CONFIG_PROC_FS and CONFIG_MMU being enabled, but it's used from
kernel/signal.c from where it is called unconditionally.

[akpm@osdl.org: build fix]
Signed-off-by: David Howells 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] vdso: randomize the i386 vDSO by moving it into a vma

2006-06-28T00:32:38+00:00

Move the i386 VDSO down into a vma and thus randomize it.

Besides the security implications, this feature also helps debuggers, which
can COW a vma-backed VDSO just like a normal DSO and can thus do
single-stepping and other debugging features.

It's good for hypervisors (Xen, VMWare) too, which typically live in the same
high-mapped address space as the VDSO, hence whenever the VDSO is used, they
get lots of guest pagefaults and have to fix such guest accesses up - which
slows things down instead of speeding things up (the primary purpose of the
VDSO).

There's a new CONFIG_COMPAT_VDSO (default=y) option, which provides support
for older glibcs that still rely on a prelinked high-mapped VDSO.  Newer
distributions (using glibc 2.3.3 or later) can turn this option off.  Turning
it off is also recommended for security reasons: attackers cannot use the
predictable high-mapped VDSO page as syscall trampoline anymore.

There is a new vdso=[0|1] boot option as well, and a runtime
/proc/sys/vm/vdso_enabled sysctl switch, that allows the VDSO to be turned
on/off.

(This version of the VDSO-randomization patch also has working ELF
coredumping, the previous patch crashed in the coredumping code.)

This code is a combined work of the exec-shield VDSO randomization
code and Gerd Hoffmann's hypervisor-centric VDSO patch. Rusty Russell
started this patch and i completed it.

[akpm@osdl.org: cleanups]
[akpm@osdl.org: compile fix]
[akpm@osdl.org: compile fix 2]
[akpm@osdl.org: compile fix 3]
[akpm@osdl.org: revernt MAXMEM change]
Signed-off-by: Ingo Molnar 
Signed-off-by: Arjan van de Ven 
Cc: Gerd Hoffmann 
Cc: Rusty Russell 
Cc: Zachary Amsden 
Cc: Andi Kleen 
Cc: Jan Beulich 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] proc: Use struct pid not struct task_ref

2006-06-26T16:58:26+00:00

Incrementally update my proc-dont-lock-task_structs-indefinitely patches so
that they work with struct pid instead of struct task_ref.

Mostly this is a straight 1-1 substitution.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] proc: don't lock task_structs indefinitely

2006-06-26T16:58:25+00:00

Every inode in /proc holds a reference to a struct task_struct.  If a
directory or file is opened and remains open after the the task exits this
pinning continues.  With 8K stacks on a 32bit machine the amount pinned per
file descriptor is about 10K.

Normally I would figure a reasonable per user process limit is about 100
processes.  With 80 processes, with a 1000 file descriptors each I can trigger
the 00M killer on a 32bit kernel, because I have pinned about 800MB of useless
data.

This patch replaces the struct task_struct pointer with a pointer to a struct
task_ref which has a struct task_struct pointer.  The so the pinning of dead
tasks does not happen.

The code now has to contend with the fact that the task may now exit at any
time.  Which is a little but not muh more complicated.

With this change it takes about 1000 processes each opening up 1000 file
descriptors before I can trigger the OOM killer.  Much better.

[mlp@google.com: task_mmu small fixes]
Signed-off-by: Eric W. Biederman 
Cc: Trond Myklebust 
Cc: Paul Jackson 
Cc: Oleg Nesterov 
Cc: Albert Cahalan 
Signed-off-by: Prasanna Meda 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] proc: Move proc_maps_operations into task_mmu.c

2006-06-26T16:58:24+00:00

All of the functions for proc_maps_operations are already defined in
task_mmu.c so move the operations structure to keep the functionality
together.

Since task_nommu.c implements a dummy version of /proc//maps give it a
simplified version of proc_maps_operations that it can modify to best suit its
needs.

Signed-off-by: Eric W. Biederman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] smaps: shared fix

2006-03-07T02:40:45+00:00

The point of the smaps "shared" is to count the number of pages that are
mapped by more than one process, according to Mauricio Lin.  However, smaps
uses page_count for this, so it will return a false positive for every page
that is mapped by just that one process, which is also in pagecache or
swapcache.  There are false positive situations for anonymous pages not in
swapcache as well: - page reclaim, migration - get_user_pages (eg.
direct-io, ptrace)

Use page_mapcount instead, to count the number of mappings to the page.

Use vm_normal_page so that weird things like /dev/mem aren't counted either.

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] smaps: hugepages fix

2006-03-07T02:40:45+00:00

smaps doesn't have a hugepage pagetable walker. Skip walking hugepage
vmas.

Signed-off-by: Nick Piggin 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] Fold numa_maps into mempolicies.c

2006-01-09T04:12:44+00:00

First discussed at http://marc.theaimsgroup.com/?t=113149255100001&r=1&w=2

- Use the check_range() in mempolicy.c to gather statistics.

- Improve the numa_maps code in general and fix some comments.

Signed-off-by: Christoph Lameter 
Cc: Andi Kleen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

mm: re-architect the VM_UNPAGED logic

2005-11-28T22:34:23+00:00

This replaces the (in my opinion horrible) VM_UNMAPPED logic with very
explicit support for a "remapped page range" aka VM_PFNMAP.  It allows a
VM area to contain an arbitrary range of page table entries that the VM
never touches, and never considers to be normal pages.

Any user of "remap_pfn_range()" automatically gets this new
functionality, and doesn't even have to mark the pages reserved or
indeed mark them any other way.  It just works.  As a side effect, doing
mmap() on /dev/mem works for arbitrary ranges.

Sparc update from David in the next commit.

Signed-off-by: Linus Torvalds

[PATCH] Fix sparse warning in proc/task_mmu.c

2005-11-14T02:14:15+00:00

fs/proc/task_mmu.c:198:33: warning: Using plain integer as NULL pointer

Signed-off-by: Luiz Capitulino 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds