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

sched: Add a generic notifier when a task struct is about to be freed

2010-05-23T21:43:11+00:00

This patch adds a notifier which can be used by subsystems that may
be interested in when a task has completely died and is about to
have it's last resource freed.

  The Android lowmemory killer uses this to determine when a task
it has killed has finally given up its goods.

Signed-off-by: San Mehat

nohz: Allow 32-bit machines to sleep for more than 2.15 seconds

2010-05-18T02:41:40+00:00

In the dynamic tick code, "max_delta_ns" (member of the
"clock_event_device" structure) represents the maximum sleep time
that can occur between timer events in nanoseconds.

The variable, "max_delta_ns", is defined as an unsigned long
which is a 32-bit integer for 32-bit machines and a 64-bit
integer for 64-bit machines (if -m64 option is used for gcc).
The value of max_delta_ns is set by calling the function
"clockevent_delta2ns()" which returns a maximum value of LONG_MAX.
For a 32-bit machine LONG_MAX is equal to 0x7fffffff and in
nanoseconds this equates to ~2.15 seconds. Hence, the maximum
sleep time for a 32-bit machine is ~2.15 seconds, where as for
a 64-bit machine it will be many years.

This patch changes the type of max_delta_ns to be "u64" instead of
"unsigned long" so that this variable is a 64-bit type for both 32-bit
and 64-bit machines. It also changes the maximum value returned by
clockevent_delta2ns() to KTIME_MAX.  Hence this allows a 32-bit
machine to sleep for longer than ~2.15 seconds. Please note that this
patch also changes "min_delta_ns" to be "u64" too and although this is
unnecessary, it makes the patch simpler as it avoids to fixup all
callers of clockevent_delta2ns().

[ tglx: changed "unsigned long long" to u64 as we use this data type
  	through out the time code ]

Signed-off-by: Jon Hunter 
Cc: John Stultz 
LKML-Reference: <1250617512-23567-3-git-send-email-jon-hunter@ti.com>
Signed-off-by: Thomas Gleixner

clockevents: Use u32 for mult and shift factors

2010-05-18T02:41:39+00:00

The mult and shift factors of clock events differ in their data type
from those of clock sources for no reason. u32 is sufficient for
both. shift is always <= 32 and mult is limited to 2^32-1 to avoid
64bit multiplication overflows in the conversion.

Preparatory patch for a generic mult/shift factor calculation
function.

Signed-off-by: Thomas Gleixner 
Tested-by: Mikael Pettersson 
Acked-by: Ralf Baechle 
Acked-by: Linus Walleij 
Cc: John Stultz 
LKML-Reference: <20091111134229.725664788@linutronix.de>

kernel: Mapped irq chip default_disable to chip->mask.

2010-04-09T03:07:35+00:00

Despite the claim in struct irq_chip header: "disable: disable the
interrupt (defaults to chip->mask if NULL)", it is not happening as
default_disable is empty. Fixed it. Should also fix bug 667376.

Change-Id: If0c39e3b4344701bbf235201c180d9c8ce56c489
Reviewed-on: http://git-master/r/947
Tested-by: Aleksandr Frid 
Reviewed-by: Gary King 
Tested-by: Gary King

sched: Fix set_cpu_active() in cpu_down()

2010-04-09T03:07:14+00:00

Sachin found cpu hotplug test failures on powerpc, which made
the kernel hang on his POWER box.

The problem is that we fail to re-activate a cpu when a
hot-unplug fails. Fix this by moving the de-activation into
_cpu_down after doing the initial checks.

Remove the synchronize_sched() calls and rely on those implied
by rebuilding the sched domains using the new mask.

Reported-by: Sachin Sant 
Signed-off-by: Xiaotian Feng 
Tested-by: Sachin Sant 
Signed-off-by: Peter Zijlstra 
Cc: Mike Galbraith 
LKML-Reference: <20091216170517.500272612@chello.nl>
Signed-off-by: Ingo Molnar

Merge commit 'v2.6.32.9' into android-2.6.32

2010-03-11T00:38:33+00:00

Export the symbol of getboottime and mmonotonic_to_bootbased

2010-02-23T15:37:52+00:00

commit c93d89f3dbf0202bf19c07960ca8602b48c2f9a0 upstream.

Export getboottime and monotonic_to_bootbased in order to let them
could be used by following patch.

Signed-off-by: Jason Wang 
Signed-off-by: Marcelo Tosatti 
Signed-off-by: Greg Kroah-Hartman

futex: Handle futex value corruption gracefully

2010-02-23T15:37:43+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

futex: Handle user space corruption gracefully

2010-02-23T15:37:43+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_lock_pi() key refcnt fix

2010-02-23T15:37:43+00:00

commit 5ecb01cfdf96c5f465192bdb2a4fd4a61a24c6cc upstream.

This fixes a futex key reference count bug in futex_lock_pi(),
where a key's reference count is incremented twice but decremented
only once, causing the backing object to not be released.

If the futex is created in a temporary file in an ext3 file system,
this bug causes the file's inode to become an "undead" orphan,
which causes an oops from a BUG_ON() in ext3_put_super() when the
file system is unmounted. glibc's test suite is known to trigger this,
see .

The bug is a regression from 2.6.28-git3, namely Peter Zijlstra's
38d47c1b7075bd7ec3881141bb3629da58f88dab "[PATCH] futex: rely on
get_user_pages() for shared futexes". That commit made get_futex_key()
also increment the reference count of the futex key, and updated its
callers to decrement the key's reference count before returning.
Unfortunately the normal exit path in futex_lock_pi() wasn't corrected:
the reference count is incremented by get_futex_key() and queue_lock(),
but the normal exit path only decrements once, via unqueue_me_pi().
The fix is to put_futex_key() after unqueue_me_pi(), since 2.6.31
this is easily done by 'goto out_put_key' rather than 'goto out'.

Signed-off-by: Mikael Pettersson 
Acked-by: Peter Zijlstra 
Acked-by: Darren Hart 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman