linux-toradex.git/kernel, branch 3.0-pcm052-ts2.6

futex: Fix uninterruptible loop due to gate_area

2012-02-28T11:14:45+00:00

It was found (by Sasha) that if you use a futex located in the gate
area we get stuck in an uninterruptible infinite loop, much like the
ZERO_PAGE issue.

While looking at this problem, PeterZ realized you'll get into similar
trouble when hitting any install_special_pages() mapping.  And are there
still drivers setting up their own special mmaps without page->mapping,
and without special VM or pte flags to make get_user_pages fail?

In most cases, if page->mapping is NULL, we do not need to retry at all:
Linus points out that even /proc/sys/vm/drop_caches poses no problem,
because it ends up using remove_mapping(), which takes care not to
interfere when the page reference count is raised.

But there is still one case which does need a retry: if memory pressure
called shmem_writepage in between get_user_pages_fast dropping page
table lock and our acquiring page lock, then the page gets switched from
filecache to swapcache (and ->mapping set to NULL) whatever the refcount.
Fault it back in to get the page->mapping needed for key->shared.inode.

Reported-by: Sasha Levin 
Signed-off-by: Hugh Dickins 
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds

futex: Fix spelling in a source code comment

2012-02-28T11:10:35+00:00

Change a single occurrence of "unlcoked" into "unlocked".

Signed-off-by: Bart Van Assche 
Cc: Darren Hart 
Cc: Thomas Gleixner 
Signed-off-by: Jiri Kosina

futex: uninitialized warning corrections

2012-02-28T11:10:10+00:00

The variables here are really not used uninitialized.

kernel/futex.c: In function 'fixup_pi_state_owner.clone.17':
kernel/futex.c:1582:6: warning: 'curval' may be used uninitialized in this function
kernel/futex.c: In function 'handle_futex_death':
kernel/futex.c:2486:6: warning: 'nval' may be used uninitialized in this function
kernel/futex.c: In function 'do_futex':
kernel/futex.c:863:11: warning: 'curval' may be used uninitialized in this function
kernel/futex.c:828:6: note: 'curval' was declared here
kernel/futex.c:898:5: warning: 'oldval' may be used uninitialized in this function
kernel/futex.c:890:6: note: 'oldval' was declared here

Signed-off-by: Vitaliy Ivanov 
Acked-by: Darren Hart 
Signed-off-by: Jiri Kosina

plist: Remove the need to supply locks to plist heads

2012-02-28T11:03:27+00:00

This was legacy code brought over from the RT tree and
is no longer necessary.

Signed-off-by: Dima Zavin 
Acked-by: Thomas Gleixner 
Cc: Daniel Walker 
Cc: Steven Rostedt 
Cc: Peter Zijlstra 
Cc: Andi Kleen 
Cc: Lai Jiangshan 
Link: http://lkml.kernel.org/r/1310084879-10351-2-git-send-email-dima@android.com
Signed-off-by: Ingo Molnar

ENGR00156637 [MX6]Reboot take long time on SMP

2012-01-09T12:23:51+00:00

Add work around to the reboot issue of SMP, with
SMP, all the CPUs need to do _rcu_barrier, if we
enqueue an rcu callback, we need to make sure CPU
tick to stay alive until we take care of those by
completing the appropriate grace period.

This work around only work when the reboot command
issue, so it didn't impact normal kernel feature.

Signed-off-by: Anson Huang

ENGR00133978 PM: add time sensitive debug function to suspend & resume

2012-01-09T11:53:47+00:00

There was some driver is slow on suspend/resume,
but some embeded system like eReader,Cellphone
are time sensitive,this commit will report the slow
driver on suspend/resume, the default value is 500us(0.5ms)

Also, the threshold can be change by modify
'/sys/power/device_suspend_time_threshold' to change the threshold,
it is in microsecond.

The output is like:

PM: device platform:soc-audio.2 suspend too slow, takes          606.696 msecs
PM: device platform:mxc_sdc_fb.1 suspend too slow, takes         7.708 msecs

the default state of suspend driver is default off,
if you want to debug the suspend time, echo time in
microsecond(u Second) to /sys/powe/device_suspend_time_threshold

eg: I want to know which driver suspend & resume takes
more that 0.5 ms (500 us), you can just :

ehco 500 > /sys/power/device_suspend_time_threshold

Signed-off-by: Zhang Jiejing

Revert "clockevents: Set noop handler in clockevents_exchange_device()"

2012-01-03T18:42:00+00:00

commit 3b87487ac5008072f138953b07505a7e3493327f upstream.

This reverts commit de28f25e8244c7353abed8de0c7792f5f883588c.

It results in resume problems for various people. See for example

  http://thread.gmane.org/gmane.linux.kernel/1233033
  http://thread.gmane.org/gmane.linux.kernel/1233389
  http://thread.gmane.org/gmane.linux.kernel/1233159
  http://thread.gmane.org/gmane.linux.kernel/1227868/focus=1230877

and the fedora and ubuntu bug reports

  https://bugzilla.redhat.com/show_bug.cgi?id=767248
  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/904569

which got bisected down to the stable version of this commit.

Reported-by: Jonathan Nieder 
Reported-by: Phil Miller 
Reported-by: Philip Langdale 
Reported-by: Tim Gardner 
Cc: Thomas Gleixner 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

Make TASKSTATS require root access

2011-12-21T20:57:40+00:00

commit 1a51410abe7d0ee4b1d112780f46df87d3621043 upstream.

Ok, this isn't optimal, since it means that 'iotop' needs admin
capabilities, and we may have to work on this some more.  But at the
same time it is very much not acceptable to let anybody just read
anybody elses IO statistics quite at this level.

Use of the GENL_ADMIN_PERM suggested by Johannes Berg as an alternative
to checking the capabilities by hand.

Reported-by: Vasiliy Kulikov 
Cc: Johannes Berg 
Acked-by: Balbir Singh 
Signed-off-by: Linus Torvalds 
Cc: Moritz Mühlenhoff 
Signed-off-by: Greg Kroah-Hartman

alarmtimers: Fix time comparison

2011-12-21T20:57:34+00:00

commit c9c024b3f3e07d087974db4c0dc46217fff3a6c0 upstream.

The expiry function compares the timer against current time and does
not expire the timer when the expiry time is >= now. That's wrong. If
the timer is set for now, then it must expire.

Make the condition expiry > now for breaking out the loop.

Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Signed-off-by: Greg Kroah-Hartman

clockevents: Set noop handler in clockevents_exchange_device()

2011-12-09T16:52:53+00:00

commit de28f25e8244c7353abed8de0c7792f5f883588c upstream.

If a device is shutdown, then there might be a pending interrupt,
which will be processed after we reenable interrupts, which causes the
original handler to be run. If the old handler is the (broadcast)
periodic handler the shutdown state might hang the kernel completely.

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