patch 712a30e63c8066ed84385b12edbfb804f49cbc44 in mainline.

Commit 8811930dc74a503415b35c4a79d14fb0b408a361 ("splice: missing user
pointer access verification") added the proper access_ok() calls to
copy_from_user_mmap_sem() which ensures we can copy the struct iovecs
from userspace to the kernel.

But we also must check whether we can access the actual memory region
pointed to by the struct iovec to fix the access checks properly.

Signed-off-by: Bastian Blank <waldi@debian.org>
Acked-by: Oliver Pinter <oliver.pntr@gmail.com>
Cc: Jens Axboe <jens.axboe@oracle.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

patch 8811930dc74a503415b35c4a79d14fb0b408a361 in mainline.

vmsplice_to_user() must always check the user pointer and length
with access_ok() before copying. Likewise, for the slow path of
copy_from_user_mmap_sem() we need to check that we may read from
the user region.

Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Cc: Wojciech Purczynski <cliph@research.coseinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

(submitted upstream as 19a8f59ab8ceee751ea720085098355d53f727d6)

perhaps bonghits could turn on my bus-mastering because the drm
certainly never bothered doing it before.

Signed-off-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

patch 7d640c4a5b36c4733460065db1554da924044511 in mainline.

This reverts commit 109f0e93b6b728f03c1eb4af02bc25d71b646c59.

The original patch breaks BIOS updates on all Dell machines. The path to
the firmware file for the dell_rbu driver changes, which breaks all of
the userspace tools which rely on it.

Note that this patch re-introduces a problem with i2c name collision
that was previously fixed by this patch.

Signed-off-by: Michael E Brown <michael_e_brown@dell.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

patch 124d3b7041f9a0ca7c43a6293e1cae4576c32fd5 in mainline.

Frederik Himpe reported an unkillable and un-straceable pan process.

Zero length iovecs can go into an infinite loop in writev, because the 
iovec iterator does not always advance over them.

The sequence required to trigger this is not trivial. I think it 
requires that a zero-length iovec be followed by a non-zero-length iovec 
which causes a pagefault in the atomic usercopy. This causes the writev 
code to drop back into single-segment copy mode, which then tries to 
copy the 0 bytes of the zero-length iovec; a zero length copy looks like 
a failure though, so it loops.

Put a test into iov_iter_advance to catch zero-length iovecs. We could 
just put the test in the fallback path, but I feel it is more robust to 
skip over zero-length iovecs throughout the code (iovec iterator may be 
used in filesystems too, so it should be robust).

Signed-off-by: Nick Piggin <npiggin@suse.de>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

patch 296825cbe14d4c95ee9c41ca5824f7487bfb4d9d in mainline.

The reason why we are getting better wakeup latencies for
!FAIR_USER_SCHED is because of this snippet of code in place_entity():

	if (!initial) {
		/* sleeps upto a single latency don't count. */
		if (sched_feat(NEW_FAIR_SLEEPERS) && entity_is_task(se))
						     ^^^^^^^^^^^^^^^^^^
			vruntime -= sysctl_sched_latency;

		/* ensure we never gain time by being placed backwards. */
		vruntime = max_vruntime(se->vruntime, vruntime);
	}

NEW_FAIR_SLEEPERS feature gives credit for sleeping only to tasks and
not group-level entities. With the patch attached, I could see that
wakeup latencies with FAIR_USER_SCHED are restored to the same level as
!FAIR_USER_SCHED.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

patch ef9884e6f29bbe1075204f962a00f7533bf7e8f3 in mainline.

Michel Dänzr has bisected an interactivity problem with
plus-reniced tasks back to this commit:

 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8 is first bad commit
 commit 810e95ccd58d91369191aa4ecc9e6d4a10d8d0c8
 Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
 Date:   Mon Oct 15 17:00:14 2007 +0200

 sched: another wakeup_granularity fix

      unit mis-match: wakeup_gran was used against a vruntime

fix this by assymetrically scaling the vtime of positive reniced
tasks.

Bisected-by: Michel Dänzer <michel@tungstengraphics.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

(not in mainline, as it is not applicable.)

We must reject new incompatible firmware early to avoid
running into strange transmission failures.

The current development tree supports newer firmware revisions.
These revisions cause strange failures on the stable 2.6.24 kernel.
Add a check to avoid confusing users a lot.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>