linux-toradex.git, branch v2.6.35.6

Linux 2.6.35.6

2010-09-27T00:19:16+00:00

alpha: Fix printk format errors

2010-09-27T00:18:43+00:00

commit 3e073367a57d41e506f20aebb98e308387ce3090 upstream.

When compiling alpha generic build get errors such as:
arch/alpha/kernel/err_marvel.c: In function ‘marvel_print_err_cyc’:
arch/alpha/kernel/err_marvel.c:119: error: format ‘%ld’ expects type ‘long int’, but argument 6 has type ‘u64’

Replaced a number of %ld format specifiers with %lld since u64
is unsigned long long.

Signed-off-by: Michael Cree 
Signed-off-by: Matt Turner 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Ensure that the crtcinfo is populated during mode_fixup()

2010-09-27T00:18:42+00:00

commit 897493504addc5609f04a2c4f73c37ab972c29b2 upstream.

This should fix the mysterious mode setting failures reported during
boot up and after resume, generally for i8xx class machines.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16478
Reported-and-tested-by: Xavier Chantry 
Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=29413
Tested-by: Daniel Vetter 
Signed-off-by: Chris Wilson 
Signed-off-by: Greg Kroah-Hartman

sctp: Do not reset the packet during sctp_packet_config().

2010-09-27T00:18:42+00:00

commit 4bdab43323b459900578b200a4b8cf9713ac8fab upstream.

sctp_packet_config() is called when getting the packet ready
for appending of chunks.  The function should not touch the
current state, since it's possible to ping-pong between two
transports when sending, and that can result packet corruption
followed by skb overlfow crash.

Reported-by: Thomas Dreibholz 
Signed-off-by: Vlad Yasevich 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

Fix unprotected access to task credentials in waitid()

2010-09-27T00:18:41+00:00

commit f362b73244fb16ea4ae127ced1467dd8adaa7733 upstream.

Using a program like the following:

	#include 
	#include 
	#include 
	#include 

	int main() {
		id_t id;
		siginfo_t infop;
		pid_t res;

		id = fork();
		if (id == 0) { sleep(1); exit(0); }
		kill(id, SIGSTOP);
		alarm(1);
		waitid(P_PID, id, &infop, WCONTINUED);
		return 0;
	}

to call waitid() on a stopped process results in access to the child task's
credentials without the RCU read lock being held - which may be replaced in the
meantime - eliciting the following warning:

	===================================================
	[ INFO: suspicious rcu_dereference_check() usage. ]
	---------------------------------------------------
	kernel/exit.c:1460 invoked rcu_dereference_check() without protection!

	other info that might help us debug this:

	rcu_scheduler_active = 1, debug_locks = 1
	2 locks held by waitid02/22252:
	 #0:  (tasklist_lock){.?.?..}, at: [] do_wait+0xc5/0x310
	 #1:  (&(&sighand->siglock)->rlock){-.-...}, at: []
	wait_consider_task+0x19a/0xbe0

	stack backtrace:
	Pid: 22252, comm: waitid02 Not tainted 2.6.35-323cd+ #3
	Call Trace:
	 [] lockdep_rcu_dereference+0xa4/0xc0
	 [] wait_consider_task+0xaf1/0xbe0
	 [] do_wait+0xf5/0x310
	 [] sys_waitid+0x86/0x1f0
	 [] ? child_wait_callback+0x0/0x70
	 [] system_call_fastpath+0x16/0x1b

This is fixed by holding the RCU read lock in wait_task_continued() to ensure
that the task's current credentials aren't destroyed between us reading the
cred pointer and us reading the UID from those credentials.

Furthermore, protect wait_task_stopped() in the same way.

We don't need to keep holding the RCU read lock once we've read the UID from
the credentials as holding the RCU read lock doesn't stop the target task from
changing its creds under us - so the credentials may be outdated immediately
after we've read the pointer, lock or no lock.

Signed-off-by: Daniel J Blueman 
Signed-off-by: David Howells 
Acked-by: Paul E. McKenney 
Acked-by: Oleg Nesterov 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

guard page for stacks that grow upwards

2010-09-27T00:18:41+00:00

commit 8ca3eb08097f6839b2206e2242db4179aee3cfb3 upstream.

pa-risc and ia64 have stacks that grow upwards. Check that
they do not run into other mappings. By making VM_GROWSUP
0x0 on architectures that do not ever use it, we can avoid
some unpleasant #ifdefs in check_stack_guard_page().

Signed-off-by: Tony Luck 
Signed-off-by: Linus Torvalds 
Cc: dann frazier 
Signed-off-by: Greg Kroah-Hartman

mm: page allocator: update free page counters after pages are placed on the free list

2010-09-27T00:18:41+00:00

commit 72853e2991a2702ae93aaf889ac7db743a415dd3 upstream.

When allocating a page, the system uses NR_FREE_PAGES counters to
determine if watermarks would remain intact after the allocation was made.
This check is made without interrupts disabled or the zone lock held and
so is race-prone by nature.  Unfortunately, when pages are being freed in
batch, the counters are updated before the pages are added on the list.
During this window, the counters are misleading as the pages do not exist
yet.  When under significant pressure on systems with large numbers of
CPUs, it's possible for processes to make progress even though they should
have been stalled.  This is particularly problematic if a number of the
processes are using GFP_ATOMIC as the min watermark can be accidentally
breached and in extreme cases, the system can livelock.

This patch updates the counters after the pages have been added to the
list.  This makes the allocator more cautious with respect to preserving
the watermarks and mitigates livelock possibilities.

[akpm@linux-foundation.org: avoid modifying incoming args]
Signed-off-by: Mel Gorman 
Reviewed-by: Rik van Riel 
Reviewed-by: Minchan Kim 
Reviewed-by: KAMEZAWA Hiroyuki 
Reviewed-by: Christoph Lameter 
Reviewed-by: KOSAKI Motohiro 
Acked-by: Johannes Weiner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: page allocator: calculate a better estimate of NR_FREE_PAGES when memory is low and kswapd is awake

2010-09-27T00:18:40+00:00

commit aa45484031ddee09b06350ab8528bfe5b2c76d1c upstream.

Ordinarily watermark checks are based on the vmstat NR_FREE_PAGES as it is
cheaper than scanning a number of lists.  To avoid synchronization
overhead, counter deltas are maintained on a per-cpu basis and drained
both periodically and when the delta is above a threshold.  On large CPU
systems, the difference between the estimated and real value of
NR_FREE_PAGES can be very high.  If NR_FREE_PAGES is much higher than
number of real free page in buddy, the VM can allocate pages below min
watermark, at worst reducing the real number of pages to zero.  Even if
the OOM killer kills some victim for freeing memory, it may not free
memory if the exit path requires a new page resulting in livelock.

This patch introduces a zone_page_state_snapshot() function (courtesy of
Christoph) that takes a slightly more accurate view of an arbitrary vmstat
counter.  It is used to read NR_FREE_PAGES while kswapd is awake to avoid
the watermark being accidentally broken.  The estimate is not perfect and
may result in cache line bounces but is expected to be lighter than the
IPI calls necessary to continually drain the per-cpu counters while kswapd
is awake.

Signed-off-by: Christoph Lameter 
Signed-off-by: Mel Gorman 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

mm: page allocator: drain per-cpu lists after direct reclaim allocation fails

2010-09-27T00:18:40+00:00

commit 9ee493ce0a60bf42c0f8fd0b0fe91df5704a1cbf upstream.

When under significant memory pressure, a process enters direct reclaim
and immediately afterwards tries to allocate a page.  If it fails and no
further progress is made, it's possible the system will go OOM.  However,
on systems with large amounts of memory, it's possible that a significant
number of pages are on per-cpu lists and inaccessible to the calling
process.  This leads to a process entering direct reclaim more often than
it should increasing the pressure on the system and compounding the
problem.

This patch notes that if direct reclaim is making progress but allocations
are still failing that the system is already under heavy pressure.  In
this case, it drains the per-cpu lists and tries the allocation a second
time before continuing.

Signed-off-by: Mel Gorman 
Reviewed-by: Minchan Kim 
Reviewed-by: KAMEZAWA Hiroyuki 
Reviewed-by: KOSAKI Motohiro 
Reviewed-by: Christoph Lameter 
Cc: Dave Chinner 
Cc: Wu Fengguang 
Cc: David Rientjes 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

dell-wmi: Add support for eject key on Dell Studio 1555

2010-09-27T00:18:39+00:00

commit d5164dbf1f651d1e955b158fb70a9c844cc91cd1 upstream.

Fixes pressing the eject key on Dell Studio 1555 does not work and produces
message :

dell-wmi: Unknown key 0 pressed

Signed-off-by: Islam Amer 
Cc: Kyle McMartin 
Signed-off-by: Greg Kroah-Hartman