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

sched: Fix string comparison in /proc/sched_features

2010-11-22T18:43:09+00:00

commit 7740191cd909b75d75685fb08a5d1f54b8a9d28b upstream.

Fix incorrect handling of the following case:

 INTERACTIVE
 INTERACTIVE_SOMETHING_ELSE

The comparison only checks up to each element's length.

Changelog since v1:
 - Embellish using some Rostedtisms.
  [ mingo:                 ^^ == smaller and cleaner ]

Signed-off-by: Mathieu Desnoyers 
Reviewed-by: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Tony Lindgren 
LKML-Reference: <20100913214700.GB16118@Krystal>
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

compat: Make compat_alloc_user_space() incorporate the access_ok()

2010-09-20T20:03:21+00:00

commit c41d68a513c71e35a14f66d71782d27a79a81ea6 upstream.

compat_alloc_user_space() expects the caller to independently call
access_ok() to verify the returned area.  A missing call could
introduce problems on some architectures.

This patch incorporates the access_ok() check into
compat_alloc_user_space() and also adds a sanity check on the length.
The existing compat_alloc_user_space() implementations are renamed
arch_compat_alloc_user_space() and are used as part of the
implementation of the new global function.

This patch assumes NULL will cause __get_user()/__put_user() to either
fail or access userspace on all architectures.  This should be
followed by checking the return value of compat_access_user_space()
for NULL in the callers, at which time the access_ok() in the callers
can also be removed.

Reported-by: Ben Hawkes 
Signed-off-by: H. Peter Anvin 
Acked-by: Benjamin Herrenschmidt 
Acked-by: Chris Metcalf 
Acked-by: David S. Miller 
Acked-by: Ingo Molnar 
Acked-by: Thomas Gleixner 
Acked-by: Tony Luck 
Cc: Andrew Morton 
Cc: Arnd Bergmann 
Cc: Fenghua Yu 
Cc: H. Peter Anvin 
Cc: Heiko Carstens 
Cc: Helge Deller 
Cc: James Bottomley 
Cc: Kyle McMartin 
Cc: Martin Schwidefsky 
Cc: Paul Mackerras 
Cc: Ralf Baechle 
Signed-off-by: Greg Kroah-Hartman

tracing: Do not allow llseek to set_ftrace_filter

2010-09-20T20:03:20+00:00

commit 9c55cb12c1c172e2d51e85fbb5a4796ca86b77e7 upstream.

Reading the file set_ftrace_filter does three things.

1) shows whether or not filters are set for the function tracer
2) shows what functions are set for the function tracer
3) shows what triggers are set on any functions

3 is independent from 1 and 2.

The way this file currently works is that it is a state machine,
and as you read it, it may change state. But this assumption breaks
when you use lseek() on the file. The state machine gets out of sync
and the t_show() may use the wrong pointer and cause a kernel oops.

Luckily, this will only kill the app that does the lseek, but the app
dies while holding a mutex. This prevents anyone else from using the
set_ftrace_filter file (or any other function tracing file for that matter).

A real fix for this is to rewrite the code, but that is too much for
a -rc release or stable. This patch simply disables llseek on the
set_ftrace_filter() file for now, and we can do the proper fix for the
next major release.

Reported-by: Robert Swiecki 
Cc: Chris Wright 
Cc: Tavis Ormandy 
Cc: Eugene Teo 
Cc: vendor-sec@lst.de
Signed-off-by: Steven Rostedt 
Signed-off-by: Greg Kroah-Hartman

clockevent: Prevent dead lock on clockevents_lock

2010-05-26T21:27:07+00:00

This is a merge of two mainline commits, intended
for stable@kernel.org submission for 2.6.27 kernel.

commit f833bab87fca5c3ce13778421b1365845843b976
and

commit 918aae42aa9b611a3663b16ae849fdedc67c2292
Changelog of both:

    Currently clockevents_notify() is called with interrupts enabled at
    some places and interrupts disabled at some other places.

    This results in a deadlock in this scenario.

    cpu A holds clockevents_lock in clockevents_notify() with irqs enabled
    cpu B waits for clockevents_lock in clockevents_notify() with irqs disabled
    cpu C doing set_mtrr() which will try to rendezvous of all the cpus.

    This will result in C and A come to the rendezvous point and waiting
    for B. B is stuck forever waiting for the spinlock and thus not
    reaching the rendezvous point.

    Fix the clockevents code so that clockevents_lock is taken with
    interrupts disabled and thus avoid the above deadlock.

    Also call lapic_timer_propagate_broadcast() on the destination cpu so
    that we avoid calling smp_call_function() in the clockevents notifier
    chain.

    This issue left us wondering if we need to change the MTRR rendezvous
    logic to use stop machine logic (instead of smp_call_function) or add
    a check in spinlock debug code to see if there are other spinlocks
    which gets taken under both interrupts enabled/disabled conditions.

    Signed-off-by: Suresh Siddha 
    Cc: "Brown Len" 
    Cc: stable@kernel.org
    LKML-Reference: <1250544899.2709.210.camel@sbs-t61.sc.intel.com>
    Signed-off-by: Thomas Gleixner 

    I got following warning on ia64 box:
      In function 'acpi_processor_power_verify':
      642: warning: passing argument 2 of 'smp_call_function_single' from
      incompatible pointer type

    This smp_call_function_single() was introduced by a commit
    f833bab87fca5c3ce13778421b1365845843b976:

    The problem is that the lapic_timer_propagate_broadcast() has 2 versions:
    One is real code that modified in the above commit, and the other is NOP
    code that used when !ARCH_APICTIMER_STOPS_ON_C3:

      static void lapic_timer_propagate_broadcast(struct acpi_processor *pr) { }

    So I got warning because of !ARCH_APICTIMER_STOPS_ON_C3.

    We really want to do nothing here on !ARCH_APICTIMER_STOPS_ON_C3, so
    modify lapic_timer_propagate_broadcast() of real version to use
    smp_call_function_single() in it.

    Signed-off-by: Hidetoshi Seto 
    Acked-by: Suresh Siddha 
    Signed-off-by: Len Brown 

Signed-off-by: Thomas Renninger 
Signed-off-by: Greg Kroah-Hartman

trace: Fix inappropriate substraction on tracing_pages_allocated in trace_free_page()

2010-05-26T21:27:07+00:00

[No matching upstream git commit id as it was fixed differently due to a
rewrite of the tracing code there.]

For normal case, the code in trace_free_page() do once more substraction
on tracing_pages_allocated, but for CONFIG_TRACER_MAX_TRACE  it doesn't
take the freed page into account. That's not consistent with
trace_alloc_page().  Well, for there are no message related with this,
so we cannot observe its incorrect state when the kernel doesn't define
"CONFIG_TRACER_MAX_TRACE". If you add some pr_info() as
trace_alloc_page(), you may notice it.

Cc: Steven Rostedt 
Cc: Frederic Weisbecker 
Cc: Ingo Molnar 
Cc: Li Zefan 
Signed-off-by: Wang Sheng-Hui 
Signed-off-by: Greg Kroah-Hartman

sched: wakeup preempt when small overlap

2010-04-01T22:52:21+00:00

commit 15afe09bf496ae10c989e1a375a6b5da7bd3e16e upstream.

Lin Ming reported a 10% OLTP regression against 2.6.27-rc4.

The difference seems to come from different preemption agressiveness,
which affects the cache footprint of the workload and its effective
cache trashing.

Aggresively preempt a task if its avg overlap is very small, this should
avoid the task going to sleep and find it still running when we schedule
back to it - saving a wakeup.

Reported-by: Lin Ming 
Signed-off-by: Peter Zijlstra 
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman

printk: robustify printk, fix #2

2010-04-01T22:52:17+00:00

commit fa33507a22623b3bd543b15a21c362cf364b6cff upstream.

Dmitry Adamushko reported:

> [*] btw., with DEBUG being enabled, pr_debug() generates [1] when
> debug_smp_processor_id() is used (CONFIG_DEBUG_PREEMPT).
>
> the problem seems to be caused by the following commit:
> commit b845b517b5e3706a3729f6ea83b88ab85f0725b0
> Author: Peter Zijlstra 
> Date:   Fri Aug 8 21:47:09 2008 +0200
>
>     printk: robustify printk
>
>
> wake_up_klogd() -> __get_cpu_var() -> smp_processor_id()
>
> and that's being called from release_console_sem() which is, in turn,
> said to be "may be called from any context" [2]
>
> and in this case, it seems to be called from some non-preemptible
> context (although, it can't be printk()...
> although, I haven't looked carefully yet).
>
> Provided [2], __get_cpu_var() is perhaps not the right solution there.
>
>
> [1]
>
> [ 7697.942005] BUG: using smp_processor_id() in preemptible [00000000] code: syslogd/3542
> [ 7697.942005] caller is wake_up_klogd+0x1b/0x50
> [ 7697.942005] Pid: 3542, comm: syslogd Not tainted 2.6.27-rc3-tip-git #2
> [ 7697.942005] Call Trace:
> [ 7697.942005]  [] debug_smp_processor_id+0xe8/0xf0
> [ 7697.942005]  [] wake_up_klogd+0x1b/0x50
> [ 7697.942005]  [] release_console_sem+0x1e7/0x200
> [ 7697.942005]  [] do_con_write+0xb7/0x1f30
> [ 7697.942005]  [] ? show_trace+0x10/0x20
> [ 7697.942005]  [] ? dump_stack+0x72/0x80
> [ 7697.942005]  [] ? __ratelimit+0xbd/0xe0
> [ 7697.942005]  [] ? debug_smp_processor_id+0xe8/0xf0
> [ 7697.942005]  [] ? wake_up_klogd+0x1b/0x50
> [ 7697.942005]  [] ? release_console_sem+0x1e7/0x200
> [ 7697.942005]  [] con_write+0x19/0x30
> [ 7697.942005]  [] write_chan+0x276/0x3c0
> [ 7697.942005]  [] ? default_wake_function+0x0/0x10
> [ 7697.942005]  [] ? _spin_lock_irqsave+0x22/0x50
> [ 7697.942005]  [] tty_write+0x194/0x260
> [ 7697.942005]  [] ? write_chan+0x0/0x3c0
> [ 7697.942005]  [] redirected_tty_write+0xa4/0xb0
> [ 7697.942005]  [] ? redirected_tty_write+0x0/0xb0
> [ 7697.942005]  [] do_loop_readv_writev+0x52/0x80
> [ 7697.942005]  [] do_readv_writev+0x1bd/0x1d0
> [ 7697.942005]  [] vfs_writev+0x39/0x60
> [ 7697.942005]  [] sys_writev+0x50/0x90
> [ 7697.942005]  [] system_call_fastpath+0x16/0x1b

Signed-off-by: Peter Zijlstra 
Reported-by: Dmitry Adamushko 
Signed-off-by: Ingo Molnar 
Cc: Paul Gortmaker 
Signed-off-by: Greg Kroah-Hartman

futex: Handle user space corruption gracefully

2010-04-01T22:52:16+00:00

commit 51246bfd189064079c54421507236fd2723b18f3 upstream.

If the owner of a PI futex dies we fix up the pi_state and set
pi_state->owner to NULL. When a malicious or just sloppy programmed
user space application sets the futex value to 0 e.g. by calling
pthread_mutex_init(), then the futex can be acquired again. A new
waiter manages to enqueue itself on the pi_state w/o damage, but on
unlock the kernel dereferences pi_state->owner and oopses.

Prevent this by checking pi_state->owner in the unlock path. If
pi_state->owner is not current we know that user space manipulated the
futex value. Ignore the mess and return -EINVAL.

This catches the above case and also the case where a task hijacks the
futex by setting the tid value and then tries to unlock it.

Reported-by: Jermome Marchand 
Signed-off-by: Thomas Gleixner 
Acked-by: Darren Hart 
Acked-by: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman

futex: Handle futex value corruption gracefully

2010-04-01T22:52:16+00:00

commit 59647b6ac3050dd964bc556fe6ef22f4db5b935c upstream.

The WARN_ON in lookup_pi_state which complains about a mismatch
between pi_state->owner->pid and the pid which we retrieved from the
user space futex is completely bogus.

The code just emits the warning and then continues despite the fact
that it detected an inconsistent state of the futex. A conveniant way
for user space to spam the syslog.

Replace the WARN_ON by a consistency check. If the values do not match
return -EINVAL and let user space deal with the mess it created.

This also fixes the missing task_pid_vnr() when we compare the
pi_state->owner pid with the futex value.

Reported-by: Jermome Marchand 
Signed-off-by: Thomas Gleixner 
Acked-by: Darren Hart 
Acked-by: Peter Zijlstra 
Signed-off-by: Greg Kroah-Hartman

fix more leaks in audit_tree.c tag_chunk()

2010-01-18T18:33:58+00:00

commit b4c30aad39805902cf5b855aa8a8b22d728ad057 upstream.

Several leaks in audit_tree didn't get caught by commit
318b6d3d7ddbcad3d6867e630711b8a705d873d7, including the leak on normal
exit in case of multiple rules refering to the same chunk.

Signed-off-by: Al Viro 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman