BugLink: http://bugs.launchpad.net/bugs/802383



commit ad5d5292f16c6c1d7d3e257c4c7407594286b97e upstream.

Commit 0837e3242c73566fc1c0196b4ec61779c25ffc93 fixes a situation on POWER7
where events can roll back if a specualtive event doesn't actually complete.
This can raise a performance monitor exception.  We need to catch this to ensure
that we reset the PMC.  In all cases the PMC will be less than 256 cycles from
overflow.

This patch lifts Anton's fix for the problem in perf and applies it to oprofile
as well.

Signed-off-by: Eric B Munson <emunson@mgebm.net>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/802383



commit 3d2cea732d68aa270c360f55d8669820ebce188a upstream.

Commit 1fc711f7 (powerpc/kexec: Fix race
in kexec shutdown) moved the write to signal the cpu had exited the kernel
from before the transition to real mode in kexec_smp_wait to kexec_wait.

Unfornately it missed that kexec_wait is used both by cpus leaving the
kernel and by secondary slave cpus that were not allocated a paca for
what ever reason -- they could be beyond nr_cpus or not described in
the current device tree for whatever reason (for example, kexec-load
was not refreshed after a cpu hotplug operation).  Cpus coming through
that path they will write to paca[NR_CPUS] which is beyond the space
allocated for the paca data and overwrite memory not allocated to pacas
but very likely still real mode accessable).

Move the write back to kexec_smp_wait, which is used only by cpus that
found their paca, but after the transition to real mode.

Signed-off-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/802383



commit 98586ed8b8878e10691203687e89a42fa3355300 upstream.

When a CPU is taken offline in an SMP system, cpufreq_remove_dev()
nulls out the per-cpu policy before cpufreq_stats_free_table() can
make use of it.  cpufreq_stats_free_table() then skips the
call to sysfs_remove_group(), leaving about 100 bytes of sysfs-related
memory unclaimed each time a CPU-removal occurs. Break up
cpu_stats_free_table into sysfs and table portions, and
call the sysfs portion early.

Signed-off-by: Steven Finney <steven.finney@palm.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/802383



commit 27ecddc2a9f99ce4ac9a59a0acd77f7100b6d034 upstream.

When we discover CPUs that are affected by each other's
frequency/voltage transitions, the first CPU gets a sysfs directory
created, and rest of the siblings get symlinks. Currently, when we
hotplug off only the first CPU, all of the symlinks and the sysfs
directory gets removed. Even though rest of the siblings are still
online and functional, they are orphaned, and no longer governed by
cpufreq.

This patch, given the above scenario, creates a sysfs directory for
the first sibling and symlinks for the rest of the siblings.

Please note the recursive call, it was rather too ugly to roll it
out. And the removal of redundant NULL setting (it is already taken
care of near the top of the function).

Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Acked-by: Mark Langsdorf <mark.langsdorf@amd.com>
Reviewed-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/802383



commit 52c3ce4ec5601ee383a14f1485f6bac7b278896e upstream.

The kmemleak_seq_next() function tries to get an object (and increment
its use count) before returning it. If it could not get the last object
during list traversal (because it may have been freed), the function
should return NULL rather than a pointer to such object that it did not
get.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Acked-by: Phil Carmody <ext-phil.2.carmody@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/802383



commit 058e297d34a404caaa5ed277de15698d8dc43000 upstream.

If function tracing is enabled, a read of the filter files will
cause the call to stop_machine to update the function trace sites.
It should only call stop_machine on write.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating GUID partitions (in fs/partitions/efi.c) contains
a bug that causes a kernel oops on certain corrupted GUID partition
tables.

This bug has security impacts, because it allows, for example, to
prepare a storage device that crashes a kernel subsystem upon connecting
the device (e.g., a "USB Stick of (Partial) Death").

	crc = efi_crc32((const unsigned char *) (*gpt), le32_to_cpu((*gpt)->header_size));

computes a CRC32 checksum over gpt covering (*gpt)->header_size bytes.
There is no validation of (*gpt)->header_size before the efi_crc32 call.

A corrupted partition table may have large values for (*gpt)->header_size.
 In this case, the CRC32 computation access memory beyond the memory
allocated for gpt, which may cause a kernel heap overflow.

Validate value of GUID partition table header size.

[akpm@linux-foundation.org: fix layout and indenting]
Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: Matt Domsch <Matt_Domsch@dell.com>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Cc: Dave Jones <davej@codemonkey.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

(backported from commit 3eb8e74ec72736b9b9d728bad30484ec89c91dde)
CVE-2011-1577
BugLink: http://bugs.launchpad.net/bugs/795418


Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Seth Forshee <seth.forshee@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>

Again basically cut and paste

Convert the main driver set to use the hooks for GICOUNT

Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

(backported from commit 0587102cf9f427c185bfdeb2cef41e13ee0264b1)
Conflicts:
	drivers/char/synclink_gt.c
	drivers/char/synclinkmp.c
	drivers/char/nozomi.c
CVE-2010-4076
CVE-2010-4077
BugLink: http://bugs.launchpad.net/bugs/720189


Signed-off-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>

Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

This reverts commit b9143b40.

This revert is being tracked in bug 802986

BugLink: http://bugs.launchpad.net/bugs/811745


Signed-off-by: Steve Conklin <sconklin@canonical.com>

This reverts commit 69155e27.

This revert is being tracked in bug 802986

Buglink: http://bugs.launchpad.net/bugs/811745


Signed-off-by: Steve Conklin <sconklin@canonical.com>

Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>

Signed-off-by: Andy Whitcroft <apw@canonical.com>

direct_splice_actor() shouldn't use sd->pos, as sd->pos is for file reading,
file->f_pos should be used instead.

Signed-off-by: Changli Gao <xiaosuo@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
----
 fs/splice.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>

(cherry picked from commit 2cb4b05e)
BugLink: http://bugs.launchpad.net/bugs/588861


Signed-off-by: Andy Whitcroft <apw@canonical.com>

Ignore: yes
Signed-off-by: Andy Whitcroft <apw@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

This reverts commit cdaa050b.

BugLink: http://bugs.launchpad.net/bugs/805209

A regression has been determined to be due to this patch, and
it is being reverted. This revert is being tracked in bug 807172

Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

This reverts commit d34e1667.

This revert is being tracked in bug 802461

Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

This patch came with an upstream lonterm patch set but
should only have been applied to 2.6.35 and later.

This reverts commit 19449afc.

Ignore: yes
Signed-off-by: Steve Conklin <sconklin@canonical.com>

Signed-off-by: Brad Figg <brad.figg@canonical.com>

This reverts commit 026b0f57.

Reverted due to regressions reported. Upon investigation, the
upstream developer gave guidance that this commit should be
reverted.

Signed-off-by: Brad Figg <brad.figg@canonical.com>

This reverts commit 3167ac0b.

Reverted due to regressions reported. Upon investigation, the
upstream developer gave guidance that this commit should be
reverted.

Signed-off-by: Brad Figg <brad.figg@canonical.com>

This reverts commit 581d1216.

Reverted due to regressions reported. Upon investigation, the
upstream developer gave guidance that this commit should be
reverted.

Signed-off-by: Brad Figg <brad.figg@canonical.com>

Ignore: yes
Signed-off-by: Brad Figg <brad.figg@canonical.com>

Signed-off-by: Steve Conklin <sconklin@canonical.com>

BugLink: http://bugs.launchpad.net/bugs/792959



commit b513d44751bfb609a3c20463f764c8ce822d63e9 upstream.

Dmitry's patch

dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()

introduced a bug.  The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)).  Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.

Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding.  The isochronous endpoint encoding was the same.

This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:

[  100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[  100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[  100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[  100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000

When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Steve Conklin <sconklin@canonical.com>

Ignore: yes

Signed-off-by: Steve Conklin <sconklin@canonical.com>

This reverts commit 5490ee42.

Reverted because it was discovered during testing that this patch causes problems in some situations.

BugLink: http://bugs.launchpad.net/bugs/788602



Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>