UBUNTU: Start new release

Ignore: yes
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: SAUCE: fix i915 regression after commit 9594e7e

commit 9594e7e, A backport for stable from commit
e7d841ca03b7ab668620045cd7b428eda9f41601 upstream ("drm/i915: Close race
between processing unpin task and queueing the flip"), and which came
through 3.2.36 stable update, has two issues: duplicated
intel_mark_page_flip_active calls on intel_gen4_queue_flip, and one
intel_mark_page_flip_active call missing on intel_gen6_queue_flip.

The second issue is what should be causing issues, and the problems
being reported on bug 1119809. I was able to reproduce the issue,
and bisected to the described commit on stable. This fix solved the
problem.

BugLink: http://bugs.launchpad.net/bugs/1119809
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
[ luis: fixed bug # in description ]
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: Ubuntu-3.2.0-38.60

Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: Start new release

Ignore: yes
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
ptrace: introduce signal_wake_up_state() and ptrace_signal_wake_up()

CVE-2013-0871

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

Cleanup and preparation for the next change.

signal_wake_up(resume => true) is overused. None of ptrace/jctl callers
actually want to wakeup a TASK_WAKEKILL task, but they can't specify the
necessary mask.

Turn signal_wake_up() into signal_wake_up_state(state), reintroduce
signal_wake_up() as a trivial helper, and add ptrace_signal_wake_up()
which adds __TASK_TRACED.

This way ptrace_signal_wake_up() can work "inside" ptrace_request()
even if the tracee doesn't have the TASK_WAKEKILL bit set.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 910ffdb18a6408e14febbb6e4b6840fd2c928c82)

Signed-off-by: Brad Figgs <brad.figg@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL

CVE-2013-0871

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

putreg() assumes that the tracee is not running and pt_regs_access() can
safely play with its stack.  However a killed tracee can return from
ptrace_stop() to the low-level asm code and do RESTORE_REST, this means
that debugger can actually read/modify the kernel stack until the tracee
does SAVE_REST again.

set_task_blockstep() can race with SIGKILL too and in some sense this
race is even worse, the very fact the tracee can be woken up breaks the
logic.

As Linus suggested we can clear TASK_WAKEKILL around the arch_ptrace()
call, this ensures that nobody can ever wakeup the tracee while the
debugger looks at it.  Not only this fixes the mentioned problems, we
can do some cleanups/simplifications in arch_ptrace() paths.

Probably ptrace_unfreeze_traced() needs more callers, for example it
makes sense to make the tracee killable for oom-killer before
access_process_vm().

While at it, add the comment into may_ptrace_stop() to explain why
ptrace_stop() still can't rely on SIGKILL and signal_pending_state().

Reported-by: Salman Qazi <sqazi@google.com>
Reported-by: Suleiman Souhlal <suleiman@google.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(backported from commit 9899d11f654474d2d54ea52ceaa2a1f4db3abd68)

Conflicts:
	arch/x86/kernel/step.c

Signed-off-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>

Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
wake_up_process() should be never used to wakeup a TASK_STOPPED/TRACED task

CVE-2013-0871

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

wake_up_process() should never wakeup a TASK_STOPPED/TRACED task.
Change it to use TASK_NORMAL and add the WARN_ON().

TASK_ALL has no other users, probably can be killed.

Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(backported from commit 9067ac85d533651b98c2ff903182a20cbb361fcb)

Conflicts:
	kernel/sched/core.c

Signed-off-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: Ubuntu-3.2.0-38.61

Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
UBUNTU: Start new release

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

Ignore: yes
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
UBUNTU: [debian] Remove dangling symlink from headers package

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

Signed-off-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Herton Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
[PATCH] UBUNTU: SAUCE: xen/pv-spinlock: Never enable interrupts in xen_spin_lock_slow()

The pv-ops spinlock code for Xen will call xen_spin_lock_slow()
if a lock cannot be obtained quickly by normal spinning. The
slow variant will put the VCPU onto a waiters list, then
enable interrupts (which are event channel messages in this
case) and calls a hypervisor function that is supposed to return
when the lock is released.

Using a test case which has a lot of threads running that cause
a high utilization of this spinlock code, it is observed that
the VCPU which is the first one on the waiters list seems to be
doing other things (no trace of the hv call on the stack) while
the waiters list still has it as the head. So other VCPUs which
try to acquire the lock are stuck in the hv call forever. And
that sooner than later end up in some circular locking.

By testing I can see this gets avoided when the interrupts remain
disabled for the duration of the poll_irq hypercall.

Xen PVM is the only affected setup because that is the only
one using the special spinlock api call which passes on the
flags as they were before (which is used to decide whether
interrupts get re-enabled in the Xen code).
KVM maps that call to the variant which will not look at the
previous state of interrupts and thus never re-enables them.

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

[v2: limited changes and reworded commit message]
Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: d-i: Add mellanox ethernet drivers to nic-modules

BugLink: http://bugs.launchpad.net/bugs/1015339
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
usb: gadget: dummy: fix enumeration with g_multi

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

commit 1d16638e3b9cc195bac18a8fcbca748f33c1bc24 upstream.

If we do have endpoints named like "ep-a" then bEndpointAddress is
counted internally by the gadget framework.

If we do have endpoints named like "ep-1" then bEndpointAddress is
assigned from the digit after "ep-".

If we do have both, then it is likely that after we used up the
"generic" endpoints we will use the digits and thus assign one
bEndpointAddress to multiple endpoints.

This theory can be proofed by using the completely enabled g_multi.
Without this patch, the mass storage won't enumerate and times out
because it shares endpoints with RNDIS.

This patch also adds fills up the endpoints list so we have in total
endpoints 1 to 15 in + out available while some of them are restricted
to certain types like BULK or ISO. Without this change the nokia gadget
won't load because the system does not provide enough (BULK) endpoints
but it did before ep-a - ep-f were removed.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
usb: musb: core: print new line in the driver banner again

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

commit 2ac788f705e5118dd45204e7a5bc8d5bb6873835 upstream.

Commit 5c8a86e10a7c164f44537fabdc169fd8b4e7a440 (usb: musb: drop unneeded
musb_debug trickery) erroneously removed '\n' from the driver's banner.
Concatenate all the banner substrings while adding it back...

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
virtio-blk: Don't free ida when disk is in use

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

commit f4953fe6c4aeada2d5cafd78aa97587a46d2d8f9 upstream.

When a file system is mounted on a virtio-blk disk, we then remove it
and then reattach it, the reattached disk gets the same disk name and
ids as the hot removed one.

This leads to very nasty effects - mostly rendering the newly attached
device completely unusable.

Trying what happens when I do the same thing with a USB device, I saw
that the sd node simply doesn't get free'd when a device gets forcefully
removed.

Imitate the same behavior for vd devices. This way broken vd devices
simply are never free'd and newly attached ones keep working just fine.

Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
mac80211: use del_timer_sync for final sta cleanup timer deletion

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

commit a56f992cdabc63f56b4b142885deebebf936ff76 upstream.

This is a very old bug, but there's nothing that prevents the
timer from running while the module is being removed when we
only do del_timer() instead of del_timer_sync().

The timer should normally not be running at this point, but
it's not clearly impossible (or we could just remove this.)

Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
xhci: Handle HS bulk/ctrl endpoints that don't NAK.

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

commit 55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream.

A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK.  If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).

The xHCI code to compute the NAK interval does not handle the special
case of zero properly.  The current code unconditionally subtracts one
from bInterval and uses it as an exponent.  This causes a very large
bInterval to be used, and warning messages like these will be printed:

usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes

This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.

This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".

Reported-by: Vincent Pelletier <plr.vincent@gmail.com>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Handle auto-transition from hot to warm reset.

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

commit 1c7439c61fa6516419c32a9824976334ea969d47 upstream.

USB 3.0 hubs and roothubs will automatically transition a failed hot
reset to a warm (BH) reset.  In that case, the warm reset change bit
will be set, and the link state change bit may also be set.  Change
hub_port_finish_reset to unconditionally clear those change bits for USB
3.0 hubs.  If these bits are not cleared, we may lose port change events
from the roothub.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
USB: Ignore xHCI Reset Device status.

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

commit 8b8132bc3d1cc3d4c0687e4d638a482fa920d98a upstream.

When the USB core finishes reseting a USB device, the xHCI driver sends
a Reset Device command to the host.  The xHC then updates its internal
representation of the USB device to the 'Default' device state.  If the
device was already in the Default state, the xHC will complete the
command with an error status.

If a device needs to be reset several times during enumeration, the
second reset will always fail because of the xHCI Reset Device command.
This can cause issues during enumeration.

For example, usb_reset_and_verify_device calls into hub_port_init in a
loop.  Say that on the first call into hub_port_init, the device is
successfully reset, but doesn't respond to several set address control
transfers.  Then the port will be disabled, but the udev will remain in
tact.  usb_reset_and_verify_device will call into hub_port_init again.

On the second call into hub_port_init, the device will be reset, and the
xHCI driver will issue a Reset Device command.  This command will fail
(because the device is already in the Default state), and
usb_reset_and_verify_device will fail.  The port will be disabled, and
the device won't be able to enumerate.

Fix this by ignoring the return value of the HCD reset_device callback.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>