linux-toradex.git/kernel, branch v2.6.34.3

futex: futex_find_get_task remove credentails check

2010-08-02T17:30:08+00:00

commit 7a0ea09ad5352efce8fe79ed853150449903b9f5 upstream.

futex_find_get_task is currently used (through lookup_pi_state) from two
contexts, futex_requeue and futex_lock_pi_atomic.  None of the paths
looks it needs the credentials check, though.  Different (e)uids
shouldn't matter at all because the only thing that is important for
shared futex is the accessibility of the shared memory.

The credentail check results in glibc assert failure or process hang (if
glibc is compiled without assert support) for shared robust pthread
mutex with priority inheritance if a process tries to lock already held
lock owned by a process with a different euid:

pthread_mutex_lock.c:312: __pthread_mutex_lock_full: Assertion `(-(e)) != 3 || !robust' failed.

The problem is that futex_lock_pi_atomic which is called when we try to
lock already held lock checks the current holder (tid is stored in the
futex value) to get the PI state.  It uses lookup_pi_state which in turn
gets task struct from futex_find_get_task.  ESRCH is returned either
when the task is not found or if credentials check fails.

futex_lock_pi_atomic simply returns if it gets ESRCH.  glibc code,
however, doesn't expect that robust lock returns with ESRCH because it
should get either success or owner died.

Signed-off-by: Michal Hocko 
Acked-by: Darren Hart 
Cc: Ingo Molnar 
Cc: Thomas Gleixner 
Cc: Nick Piggin 
Cc: Alexey Kuznetsov 
Cc: Peter Zijlstra 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kmemleak: Add support for NO_BOOTMEM configurations

2010-08-02T17:29:50+00:00

commit 9078370c0d2cfe4a905aa34f398bbb0d65921a2b upstream.

With commits 08677214 and 59be5a8e, alloc_bootmem()/free_bootmem() and
friends use the early_res functions for memory management when
NO_BOOTMEM is enabled. This patch adds the kmemleak calls in the
corresponding code paths for bootmem allocations.

Signed-off-by: Catalin Marinas 
Acked-by: Pekka Enberg 
Acked-by: Yinghai Lu 
Cc: H. Peter Anvin 
Signed-off-by: Greg Kroah-Hartman

genirq: Deal with desc->set_type() changing desc->chip

2010-08-02T17:29:46+00:00

commit 4673247562e39a17e09440fa1400819522ccd446 upstream.

The set_type() function can change the chip implementation when the
trigger mode changes. That might result in using an non-initialized
irq chip when called from __setup_irq() or when called via
set_irq_type() on an already enabled irq.

The set_irq_type() function should not be called on an enabled irq,
but because we forgot to put a check into it, we have a bunch of users
which grew the habit of doing that and it never blew up as the
function is serialized via desc->lock against all users of desc->chip
and they never hit the non-initialized irq chip issue.

The easy fix for the __setup_irq() issue would be to move the
irq_chip_set_defaults(desc->chip) call after the trigger setting to
make sure that a chip change is covered.

But as we have already users, which do the type setting after
request_irq(), the safe fix for now is to call irq_chip_set_defaults()
from __irq_set_trigger() when desc->set_type() changed the irq chip.

It needs a deeper analysis whether we should refuse to change the chip
on an already enabled irq, but that'd be a large scale change to fix
all the existing users. So that's neither stable nor 2.6.35 material.

Reported-by: Esben Haabendal 
Signed-off-by: Thomas Gleixner 
Cc: Benjamin Herrenschmidt 
Cc: linuxppc-dev 
Signed-off-by: Greg Kroah-Hartman

sched: Fix over-scheduling bug

2010-08-02T17:29:46+00:00

commit 3c93717cfa51316e4dbb471e7c0f9d243359d5f8 upstream.

Commit e70971591 ("sched: Optimize unused cgroup configuration") introduced
an imbalanced scheduling bug.

If we do not use CGROUP, function update_h_load won't update h_load. When the
system has a large number of tasks far more than logical CPU number, the
incorrect cfs_rq[cpu]->h_load value will cause load_balance() to pull too
many tasks to the local CPU from the busiest CPU. So the busiest CPU keeps
going in a round robin. That will hurt performance.

The issue was found originally by a scientific calculation workload that
developed by Yanmin. With that commit, the workload performance drops
about 40%.

 CPU  before    after

 00   : 2       : 7
 01   : 1       : 7
 02   : 11      : 6
 03   : 12      : 7
 04   : 6       : 6
 05   : 11      : 7
 06   : 10      : 6
 07   : 12      : 7
 08   : 11      : 6
 09   : 12      : 6
 10   : 1       : 6
 11   : 1       : 6
 12   : 6       : 6
 13   : 2       : 6
 14   : 2       : 6
 15   : 1       : 6

Reviewed-by: Yanmin zhang 
Signed-off-by: Alex Shi 
Signed-off-by: Peter Zijlstra 
LKML-Reference: <1276754893.9452.5442.camel@debian>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

sched: Prevent compiler from optimising the sched_avg_update() loop

2010-08-02T17:29:45+00:00

commit 0d98bb2656e9bd2dfda2d089db1fe1dbdab41504 upstream.

GCC 4.4.1 on ARM has been observed to replace the while loop in
sched_avg_update with a call to uldivmod, resulting in the
following build failure at link-time:

kernel/built-in.o: In function `sched_avg_update':
 kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod'
 kernel/sched.c:1261: undefined reference to `__aeabi_uldivmod'
make: *** [.tmp_vmlinux1] Error 1

This patch introduces a fake data hazard to the loop body to
prevent the compiler optimising the loop away.

Signed-off-by: Will Deacon 
Signed-off-by: Andrew Morton 
Acked-by: Peter Zijlstra 
Cc: Catalin Marinas 
Cc: Russell King 
Cc: Linus Torvalds 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

dynamic debug: move ddebug_remove_module() down into free_module()

2010-08-02T17:29:33+00:00

commit b82bab4bbe9efa7bc7177fc20620fff19bd95484 upstream.

The command

	echo "file ec.c +p" >/sys/kernel/debug/dynamic_debug/control

causes an oops.

Move the call to ddebug_remove_module() down into free_module().  In this
way it should be called from all error paths.  Currently, we are missing
the remove if the module init routine fails.

Signed-off-by: Jason Baron 
Reported-by: Thomas Renninger 
Tested-by: Thomas Renninger 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

fix mis-applied upstream commit ac9721f3f54b27a16c7e1afb2481e7ee95a70318

2010-08-02T17:29:20+00:00

For some reason one of the changes to sys_perf_event_open() got
mis-applied, thus breaking (at least) error handling paths (pointed
out by means of a compiler warning).

Signed-off-by: Jan Beulich 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

perf_events: Fix races and clean up perf_event and perf_mmap_data interaction

2010-07-05T18:22:53+00:00

commit ac9721f3f54b27a16c7e1afb2481e7ee95a70318 upstream.

In order to move toward separate buffer objects, rework the whole
perf_mmap_data construct to be a more self-sufficient entity, one
with its own lifetime rules.

This greatly sanitizes the whole output redirection code, which
was riddled with bugs and races.

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

perf: Fix signed comparison in perf_adjust_period()

2010-07-05T18:22:51+00:00

commit f6ab91add6355e231e1c47897027b2a6ee4fa268 upstream.

Frederic reported that frequency driven swevents didn't work properly
and even caused a division-by-zero error.

It turns out there are two bugs, the division-by-zero comes from a
failure to deal with that in perf_calculate_period().

The other was more interesting and turned out to be a wrong comparison
in perf_adjust_period(). The comparison was between an s64 and u64 and
got implicitly converted to an unsigned comparison. The problem is
that period_left is typically < 0, so it ended up being always true.

Cure this by making the local period variables s64.

Reported-by: Frederic Weisbecker 
Tested-by: Frederic Weisbecker 
Signed-off-by: Peter Zijlstra 
LKML-Reference: 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

cgroups: alloc_css_id() increments hierarchy depth

2010-07-05T18:22:46+00:00

commit 94b3dd0f7bb393d93e84a173b1df9b8b64c83ac4 upstream.

Child groups should have a greater depth than their parents.  Prior to
this change, the parent would incorrectly report zero memory usage for
child cgroups when use_hierarchy is enabled.

test script:
  mount -t cgroup none /cgroups -o memory
  cd /cgroups
  mkdir cg1

  echo 1 > cg1/memory.use_hierarchy
  mkdir cg1/cg11

  echo $$ > cg1/cg11/tasks
  dd if=/dev/zero of=/tmp/foo bs=1M count=1

  echo
  echo CHILD
  grep cache cg1/cg11/memory.stat

  echo
  echo PARENT
  grep cache cg1/memory.stat

  echo $$ > tasks
  rmdir cg1/cg11 cg1
  cd /
  umount /cgroups

Using fae9c79, a recent patch that changed alloc_css_id() depth computation,
the parent incorrectly reports zero usage:
  root@ubuntu:~# ./test
  1+0 records in
  1+0 records out
  1048576 bytes (1.0 MB) copied, 0.0151844 s, 69.1 MB/s

  CHILD
  cache 1048576
  total_cache 1048576

  PARENT
  cache 0
  total_cache 0

With this patch, the parent correctly includes child usage:
  root@ubuntu:~# ./test
  1+0 records in
  1+0 records out
  1048576 bytes (1.0 MB) copied, 0.0136827 s, 76.6 MB/s

  CHILD
  cache 1052672
  total_cache 1052672

  PARENT
  cache 0
  total_cache 1052672

Signed-off-by: Greg Thelen 
Acked-by: Paul Menage 
Acked-by: KAMEZAWA Hiroyuki 
Acked-by: Li Zefan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman