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

perf_event: Adjust frequency and unthrottle for non-group-leader events

2009-12-08T18:22:26+00:00

commit 03541f8b69c058162e4cf9675ec9181e6a204d55 upstream.

The loop in perf_ctx_adjust_freq checks the frequency of sampling
event counters, and adjusts the event interval and unthrottles the
event if required, and resets the interrupt count for the event.
However, at present it only looks at group leaders.

This means that a sampling event that is not a group leader will
eventually get throttled, once its interrupt count reaches
sysctl_perf_event_sample_rate/HZ --- and that is guaranteed to
happen, if the event is active for long enough, since the interrupt
count never gets reset.  Once it is throttled it never gets
unthrottled, so it basically just stops working at that point.

This fixes it by making perf_ctx_adjust_freq use ctx->event_list
rather than ctx->group_list.  The existing spin_lock/spin_unlock
around the loop makes it unnecessary to put rcu_read_lock/
rcu_read_unlock around the list_for_each_entry_rcu().

Reported-by: Mark W. Krentel 
Signed-off-by: Paul Mackerras 
Cc: Corey Ashford 
Cc: Peter Zijlstra 
LKML-Reference: <19157.26731.855609.165622@cargo.ozlabs.ibm.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

modules: don't export section names of empty sections via sysfs

2009-12-08T18:22:23+00:00

commit 35dead4235e2b67da7275b4122fed37099c2f462 upstream.

On the parisc architecture we face for each and every loaded kernel module
this kernel "badness warning":
  sysfs: cannot create duplicate filename '/module/ac97_bus/sections/.text'
  Badness at fs/sysfs/dir.c:487

Reason for that is, that on parisc all kernel modules do have multiple
.text sections due to the usage of the -ffunction-sections compiler flag
which is needed to reach all jump targets on this platform.

An objdump on such a kernel module gives:
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .note.gnu.build-id 00000024  00000000  00000000  00000034  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  1 .text         00000000  00000000  00000000  00000058  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text.ac97_bus_match 0000001c  00000000  00000000  00000058  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .text         00000000  00000000  00000000  000000d4  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
...
Since the .text sections are empty (size of 0 bytes) and won't be
loaded by the kernel module loader anyway, I don't see a reason
why such sections need to be listed under
/sys/module//sections/ either.

The attached patch does solve this issue by not exporting section
names which are empty.

This fixes bugzilla http://bugzilla.kernel.org/show_bug.cgi?id=14703

Signed-off-by: Helge Deller 
CC: rusty@rustcorp.com.au
CC: akpm@linux-foundation.org
CC: James.Bottomley@HansenPartnership.com
CC: roland@redhat.com
CC: dave@hiauly1.hia.nrc.ca
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

sched: Fix isolcpus boot option

2009-12-08T18:22:06+00:00

commit bdddd2963c0264c56f18043f6fa829d3c1d3d1c0 upstream.

Anton Blanchard wrote:

> We allocate and zero cpu_isolated_map after the isolcpus
> __setup option has run. This means cpu_isolated_map always
> ends up empty and if CPUMASK_OFFSTACK is enabled we write to a
> cpumask that hasn't been allocated.

I introduced this regression in 49557e620339cb13 (sched: Fix
boot crash by zalloc()ing most of the cpu masks).

Use the bootmem allocator if they set isolcpus=, otherwise
allocate and zero like normal.

Reported-by: Anton Blanchard 
Signed-off-by: Rusty Russell 
Cc: peterz@infradead.org
Cc: Linus Torvalds 
LKML-Reference: <200912021409.17013.rusty@rustcorp.com.au>
Signed-off-by: Ingo Molnar 
Tested-by: Anton Blanchard 
Signed-off-by: Greg Kroah-Hartman

sched: Fix boot crash by zalloc()ing most of the cpu masks

2009-12-08T18:22:05+00:00

commit 49557e620339cb134127b5bfbcfecc06b77d0232 upstream.

I got a boot crash when forcing cpumasks offstack on 32 bit,
because find_new_ilb() returned 3 on my UP system (nohz.cpu_mask
wasn't zeroed).

AFAICT the others need to be zeroed too: only
nohz.ilb_grp_nohz_mask is initialized before use.

Signed-off-by: Rusty Russell 
Cc: Peter Zijlstra 
LKML-Reference: <200911022037.21282.rusty@rustcorp.com.au>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

uids: Prevent tear down race

2009-12-08T18:21:16+00:00

commit b00bc0b237055b4c45816325ee14f0bd83e6f590 upstream.

Ingo triggered the following warning:

WARNING: at lib/debugobjects.c:255 debug_print_object+0x42/0x50()
Hardware name: System Product Name
ODEBUG: init active object type: timer_list
Modules linked in:
Pid: 2619, comm: dmesg Tainted: G        W  2.6.32-rc5-tip+ #5298
Call Trace:
 [<81035443>] warn_slowpath_common+0x6a/0x81
 [<8120e483>] ? debug_print_object+0x42/0x50
 [<81035498>] warn_slowpath_fmt+0x29/0x2c
 [<8120e483>] debug_print_object+0x42/0x50
 [<8120ec2a>] __debug_object_init+0x279/0x2d7
 [<8120ecb3>] debug_object_init+0x13/0x18
 [<810409d2>] init_timer_key+0x17/0x6f
 [<81041526>] free_uid+0x50/0x6c
 [<8104ed2d>] put_cred_rcu+0x61/0x72
 [<81067fac>] rcu_do_batch+0x70/0x121

debugobjects warns about an enqueued timer being initialized. If
CONFIG_USER_SCHED=y the user management code uses delayed work to
remove the user from the hash table and tear down the sysfs objects.

free_uid is called from RCU and initializes/schedules delayed work if
the usage count of the user_struct is 0. The init/schedule happens
outside of the uidhash_lock protected region which allows a concurrent
caller of find_user() to reference the about to be destroyed
user_struct w/o preventing the work from being scheduled. If the next
free_uid call happens before the work timer expired then the active
timer is initialized and the work scheduled again.

The race was introduced in commit 5cb350ba (sched: group scheduling,
sysfs tunables) and made more prominent by commit 3959214f (sched:
delayed cleanup of user_struct)

Move the init/schedule_delayed_work inside of the uidhash_lock
protected region to prevent the race.

Signed-off-by: Thomas Gleixner 
Acked-by: Dhaval Giani 
Cc: Paul E. McKenney 
Cc: Kay Sievers 
Signed-off-by: Greg Kroah-Hartman

param: fix setting arrays of bool

2009-11-10T00:22:22+00:00

commit 3c7d76e371ac1a3802ae1673f5c63554af59325c upstream.

We create a dummy struct kernel_param on the stack for parsing each
array element, but we didn't initialize the flags word.  This matters
for arrays of type "bool", where the flag indicates if it really is
an array of bools or unsigned int (old-style).

Reported-by: Takashi Iwai 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

param: fix NULL comparison on oom

2009-11-10T00:22:18+00:00

commit d553ad864e3b3dde3f1038d491e207021b2d6293 upstream.

kp->arg is always true: it's the contents of that pointer we care about.

Reported-by: Takashi Iwai 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

param: fix lots of bugs with writing charp params from sysfs, by leaking mem.

2009-11-10T00:22:17+00:00

commit 65afac7d80ab3bc9f81e75eafb71eeb92a3ebdef upstream.

e180a6b7759a "param: fix charp parameters set via sysfs" fixed the case
where charp parameters written via sysfs were freed, leaving drivers
accessing random memory.

Unfortunately, storing a flag in the kparam struct was a bad idea: it's
rodata so setting it causes an oops on some archs.  But that's not all:

1) module_param_array() on charp doesn't work reliably, since we use an
   uninitialized temporary struct kernel_param.
2) there's a fundamental race if a module uses this parameter and then
   it's changed: they will still access the old, freed, memory.

The simplest fix (ie. for 2.6.32) is to never free the memory.  This
prevents all these problems, at cost of a memory leak.  In practice, there
are only 18 places where a charp is writable via sysfs, and all are
root-only writable.

Reported-by: Takashi Iwai 
Cc: Sitsofe Wheeler 
Cc: Frederic Weisbecker 
Cc: Christof Schmitt 
Signed-off-by: Rusty Russell 
Signed-off-by: Greg Kroah-Hartman

futex: Fix spurious wakeup for requeue_pi really

2009-11-10T00:21:54+00:00

commit 11df6dddcbc38affb7473aad3d962baf8414a947 upstream.

The requeue_pi path doesn't use unqueue_me() (and the racy lock_ptr ==
NULL test) nor does it use the wake_list of futex_wake() which where
the reason for commit 41890f2 (futex: Handle spurious wake up)

See debugging discussing on LKML Message-ID: <4AD4080C.20703@us.ibm.com>

The changes in this fix to the wait_requeue_pi path were considered to
be a likely unecessary, but harmless safety net. But it turns out that
due to the fact that for unknown $@#!*( reasons EWOULDBLOCK is defined
as EAGAIN we built an endless loop in the code path which returns
correctly EWOULDBLOCK.

Spurious wakeups in wait_requeue_pi code path are unlikely so we do
the easy solution and return EWOULDBLOCK^WEAGAIN to user space and let
it deal with the spurious wakeup.

Cc: Darren Hart 
Cc: Peter Zijlstra 
Cc: Eric Dumazet 
Cc: John Stultz 
Cc: Dinakar Guniguntala 
LKML-Reference: <4AE23C74.1090502@us.ibm.com>
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

futex: Move drop_futex_key_refs out of spinlock'ed region

2009-11-10T00:21:53+00:00

commit 89061d3d58e1f0742139605dc6a7950aa1ecc019 upstream.

When requeuing tasks from one futex to another, the reference held
by the requeued task to the original futex location needs to be
dropped eventually.

Dropping the reference may ultimately lead to a call to
"iput_final" and subsequently call into filesystem- specific code -
which may be non-atomic.

It is therefore safer to defer this drop operation until after the
futex_hash_bucket spinlock has been dropped.

Originally-From: Helge Bahmann 
Signed-off-by: Darren Hart 
Cc: Peter Zijlstra 
Cc: Eric Dumazet 
Cc: Dinakar Guniguntala 
Cc: John Stultz 
Cc: Sven-Thorsten Dietrich 
Cc: John Kacur 
LKML-Reference: <4AD7A298.5040802@us.ibm.com>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman