linux-toradex.git/kernel, branch tegra-10.11.1.1

Merge branch 'linux-tegra-2.6.36' into android-tegra-2.6.36

2010-12-22T02:38:13+00:00

Conflicts:
	drivers/usb/gadget/composite.c

Change-Id: I1a332ec21da62aea98912df9a01cf0282ed50ee1

cgroup: Remove call to synchronize_rcu in cgroup_attach_task

2010-12-18T01:01:51+00:00

synchronize_rcu can be very expensive, averaging 100 ms in
some cases.  In cgroup_attach_task, it is used to prevent
a task->cgroups pointer dereferenced in an RCU read side
critical section from being invalidated, by delaying the
call to put_css_set until after an RCU grace period.

To avoid the call to synchronize_rcu, make the put_css_set
call rcu-safe by moving the deletion of the css_set links
into free_css_set_work, scheduled by the rcu callback
free_css_set_rcu.

The decrement of the cgroup refcount is no longer
synchronous with the call to put_css_set, which can result
in the cgroup refcount staying positive after the last call
to cgroup_attach_task returns.  To allow the cgroup to be
deleted with cgroup_rmdir synchronously after
cgroup_attach_task, have rmdir check the refcount of all
associated css_sets.  If cgroup_rmdir is called on a cgroup
for which the css_sets all have refcount zero but the
cgroup refcount is nonzero, reuse the rmdir waitqueue to
block the rmdir until free_css_set_work is called.

Signed-off-by: Colin Cross

cgroup: Set CGRP_RELEASABLE when adding to a cgroup

2010-12-18T01:01:49+00:00

Changes the meaning of CGRP_RELEASABLE to be set on any cgroup
that has ever had a task or cgroup in it, or had css_get called
on it.  The bit is set in cgroup_attach_task, cgroup_create,
and __css_get.  It is not necessary to set the bit in
cgroup_fork, as the task is either in the root cgroup, in
which can never be released, or the task it was forked from
already set the bit in croup_attach_task.

Signed-off-by: Colin Cross

genirq: Fix incorrect proc spurious output

2010-12-09T21:33:27+00:00

commit 25c9170ed64a6551beefe9315882f754e14486f4 upstream.

Since commit a1afb637(switch /proc/irq/*/spurious to seq_file) all
/proc/irq/XX/spurious files show the information of irq 0.

Current irq_spurious_proc_open() passes on NULL as the 3rd argument,
which is used as an IRQ number in irq_spurious_proc_show(), to the
single_open(). Because of this, all the /proc/irq/XX/spurious file
shows IRQ 0 information regardless of the IRQ number.

To fix the problem, irq_spurious_proc_open() must pass on the
appropreate data (IRQ number) to single_open().

Signed-off-by: Kenji Kaneshige 
Reviewed-by: Yong Zhang 
LKML-Reference: <4CF4B778.90604@jp.fujitsu.com>
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

PM / Hibernate: Fix memory corruption related to swap

2010-12-09T21:33:26+00:00

commit c9e664f1fdf34aa8cede047b206deaa8f1945af0 upstream.

There is a problem that swap pages allocated before the creation of
a hibernation image can be released and used for storing the contents
of different memory pages while the image is being saved.  Since the
kernel stored in the image doesn't know of that, it causes memory
corruption to occur after resume from hibernation, especially on
systems with relatively small RAM that need to swap often.

This issue can be addressed by keeping the GFP_IOFS bits clear
in gfp_allowed_mask during the entire hibernation, including the
saving of the image, until the system is finally turned off or
the hibernation is aborted.  Unfortunately, for this purpose
it's necessary to rework the way in which the hibernate and
suspend code manipulates gfp_allowed_mask.

This change is based on an earlier patch from Hugh Dickins.

Signed-off-by: Rafael J. Wysocki 
Reported-by: Ondrej Zary 
Acked-by: Hugh Dickins 
Reviewed-by: KAMEZAWA Hiroyuki 
Signed-off-by: Greg Kroah-Hartman

perf: Fix inherit vs. context rotation bug

2010-12-09T21:33:25+00:00

commit dddd3379a619a4cb8247bfd3c94ca9ae3797aa2e upstream.

It was found that sometimes children of tasks with inherited events had
one extra event. Eventually it turned out to be due to the list rotation
no being exclusive with the list iteration in the inheritance code.

Cure this by temporarily disabling the rotation while we inherit the events.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

PM / PM QoS: Fix reversed min and max

2010-12-09T21:33:18+00:00

commit 00fafcda1773245a5292f953321ec3f0668c8c28 upstream.

pm_qos_get_value had min and max reversed, causing all pm_qos
requests to have no effect.

Signed-off-by: Colin Cross 
Acked-by: mark 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

do_exit(): make sure that we run with get_fs() == USER_DS

2010-12-09T21:33:14+00:00

commit 33dd94ae1ccbfb7bf0fb6c692bc3d1c4269e6177 upstream.

If a user manages to trigger an oops with fs set to KERNEL_DS, fs is not
otherwise reset before do_exit().  do_exit may later (via mm_release in
fork.c) do a put_user to a user-controlled address, potentially allowing
a user to leverage an oops into a controlled write into kernel memory.

This is only triggerable in the presence of another bug, but this
potentially turns a lot of DoS bugs into privilege escalations, so it's
worth fixing.  I have proof-of-concept code which uses this bug along
with CVE-2010-3849 to write a zero to an arbitrary kernel address, so
I've tested that this is not theoretical.

A more logical place to put this fix might be when we know an oops has
occurred, before we call do_exit(), but that would involve changing
every architecture, in multiple places.

Let's just stick it in do_exit instead.

[akpm@linux-foundation.org: update code comment]
Signed-off-by: Nelson Elhage 
Cc: KOSAKI Motohiro 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

sched: fix RCU lockdep splat from task_group()

2010-12-09T21:32:59+00:00

commit 6506cf6ce68d78a5470a8360c965dafe8e4b78e3 upstream.

This addresses the following RCU lockdep splat:

[0.051203] CPU0: AMD QEMU Virtual CPU version 0.12.4 stepping 03
[0.052999] lockdep: fixing up alternatives.
[0.054105]
[0.054106] ===================================================
[0.054999] [ INFO: suspicious rcu_dereference_check() usage. ]
[0.054999] ---------------------------------------------------
[0.054999] kernel/sched.c:616 invoked rcu_dereference_check() without protection!
[0.054999]
[0.054999] other info that might help us debug this:
[0.054999]
[0.054999]
[0.054999] rcu_scheduler_active = 1, debug_locks = 1
[0.054999] 3 locks held by swapper/1:
[0.054999]  #0:  (cpu_add_remove_lock){+.+.+.}, at: [] cpu_up+0x42/0x6a
[0.054999]  #1:  (cpu_hotplug.lock){+.+.+.}, at: [] cpu_hotplug_begin+0x2a/0x51
[0.054999]  #2:  (&rq->lock){-.-...}, at: [] init_idle+0x2f/0x113
[0.054999]
[0.054999] stack backtrace:
[0.054999] Pid: 1, comm: swapper Not tainted 2.6.35 #1
[0.054999] Call Trace:
[0.054999]  [] lockdep_rcu_dereference+0x9b/0xa3
[0.054999]  [] task_group+0x7b/0x8a
[0.054999]  [] set_task_rq+0x13/0x40
[0.054999]  [] init_idle+0xd2/0x113
[0.054999]  [] fork_idle+0xb8/0xc7
[0.054999]  [] ? mark_held_locks+0x4d/0x6b
[0.054999]  [] do_fork_idle+0x17/0x2b
[0.054999]  [] native_cpu_up+0x1c1/0x724
[0.054999]  [] ? do_fork_idle+0x0/0x2b
[0.054999]  [] _cpu_up+0xac/0x127
[0.054999]  [] cpu_up+0x55/0x6a
[0.054999]  [] kernel_init+0xe1/0x1ff
[0.054999]  [] kernel_thread_helper+0x4/0x10
[0.054999]  [] ? restore_args+0x0/0x30
[0.054999]  [] ? kernel_init+0x0/0x1ff
[0.054999]  [] ? kernel_thread_helper+0x0/0x10
[0.056074] Booting Node   0, Processors  #1lockdep: fixing up alternatives.
[0.130045]  #2lockdep: fixing up alternatives.
[0.203089]  #3 Ok.
[0.275286] Brought up 4 CPUs
[0.276005] Total of 4 processors activated (16017.17 BogoMIPS).

The cgroup_subsys_state structures referenced by idle tasks are never
freed, because the idle tasks should be part of the root cgroup,
which is not removable.

The problem is that while we do in-fact hold rq->lock, the newly spawned
idle thread's cpu is not yet set to the correct cpu so the lockdep check
in task_group():

  lockdep_is_held(&task_rq(p)->lock)

will fail.

But this is a chicken and egg problem.  Setting the CPU's runqueue requires
that the CPU's runqueue already be set.  ;-)

So insert an RCU read-side critical section to avoid the complaint.

Signed-off-by: Peter Zijlstra 
Signed-off-by: Paul E. McKenney 
Signed-off-by: Greg Kroah-Hartman

latencytop: fix per task accumulator

2010-12-09T21:32:53+00:00

commit 38715258aa2e8cd94bd4aafadc544e5104efd551 upstream.

Per task latencytop accumulator prematurely terminates due to erroneous
placement of latency_record_count.  It should be incremented whenever a
new record is allocated instead of increment on every latencytop event.

Also fix search iterator to only search known record events instead of
blindly searching all pre-allocated space.

Signed-off-by: Ken Chen 
Reviewed-by: Arjan van de Ven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman