+signal-define-__arch_has_sa_restorer-so-we-know-whether-to-clear-3.0-3.2-3.4.patch
+kernel-signal.c-use-__arch_has_sa_restorer-instead-of-sa_restorer.patch
sunrpc-add-barriers-to-ensure-read-ordering-in-rpc_wake_up_task_queue_locked.patch
bluetooth-fix-not-closing-sco-sockets-in-the-bt_connect2-state.patch
bluetooth-add-support-for-dell.patch
vt-synchronize_rcu-under-spinlock-is-not-nice.patch
mwifiex-cancel-cmd-timer-and-free-curr_cmd-in-shutdown-process.patch
net-irda-add-missing-error-path-release_sock-call.patch
-usb-ehci-fix-bug-in-itd-sitd-dma-pool-allocation.patch
usb-xhci-fix-trb-transfer-length-macro-used-for-event-trb.patch
btrfs-limit-the-global-reserve-to-512mb.patch
kvm-clean-up-error-handling-during-vcpu-creation.patch
kvm-fix-buffer-overflow-in-kvm_set_irq.patch
mm-hotplug-correctly-add-new-zone-to-all-other-nodes-zone-lists.patch
kvm-x86-invalid-opcode-oops-on-set_sregs-with-osxsave-bit-set-cve-2012-4461.patch
-signal-define-__arch_has_sa_restorer-so-we-know-whether-to-clear-3.0-3.2-3.4.patch
-kernel-signal.c-use-__arch_has_sa_restorer-instead-of-sa_restorer.patch
loop-prevent-bdev-freeing-while-device-in-use.patch
+++ /dev/null
-From 85ecd0322b9a1a9f451d9150e9460ab42fd17219 Mon Sep 17 00:00:00 2001
-From: Soeren Moch <smoch@web.de>
-Date: Fri, 22 Mar 2013 12:16:52 -0400
-Subject: USB: EHCI: fix bug in iTD/siTD DMA pool allocation
-
-From: Soeren Moch <smoch@web.de>
-
-commit 85ecd0322b9a1a9f451d9150e9460ab42fd17219 upstream.
-
-[Description written by Alan Stern]
-
-Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
-management of iTD and siTD structures. Some background: ehci-hcd
-gives each isochronous endpoint its own set of active and free itd's
-(or sitd's for full-speed devices). When a new itd is needed, it is
-taken from the head of the free list, if possible. However, itd's
-must not be used twice in a single frame because the hardware
-continues to access the data structure for the entire duration of a
-frame. Therefore if the itd at the head of the free list has its
-"frame" member equal to the current value of ehci->now_frame, it
-cannot be reused and instead a new itd is allocated from the DMA pool.
-The entries on the free list are not released back to the pool until
-the endpoint is no longer in use.
-
-The bug arises from the fact that sometimes an itd can be moved back
-onto the free list before itd->frame has been set properly. In
-Soeren's case, this happened because ehci-hcd can allocate one more
-itd than it actually needs for an URB; the extra itd may or may not be
-required depending on how the transfer aligns with a frame boundary.
-For example, an URB with 8 isochronous packets will cause two itd's to
-be allocated. If the URB is scheduled to start in microframe 3 of
-frame N then it will require both itds: one for microframes 3 - 7 of
-frame N and one for microframes 0 - 2 of frame N+1. But if the URB
-had been scheduled to start in microframe 0 then it would require only
-the first itd, which could cover microframes 0 - 7 of frame N. The
-second itd would be returned to the end of the free list.
-
-The itd allocation routine initializes the entire structure to 0, so
-the extra itd ends up on the free list with itd->frame set to 0
-instead of a meaningful value. After a while the itd reaches the head
-of the list, and occasionally this happens when ehci->now_frame is
-equal to 0. Then, even though it would be okay to reuse this itd, the
-driver thinks it must get another itd from the DMA pool.
-
-For as long as the isochronous endpoint remains in use, this flaw in
-the mechanism causes more and more itd's to be taken slowly from the
-DMA pool. Since none are released back, the pool eventually becomes
-exhausted.
-
-This reuslts in memory allocation failures, which typically show up
-during a long-running audio stream. Video might suffer the same
-effect.
-
-The fix is very simple. To prevent allocations from the pool when
-they aren't needed, make sure that itd's sent back to the free list
-prematurely have itd->frame set to an invalid value which can never be
-equal to ehci->now_frame.
-
-This should be applied to -stable kernels going back to 3.6.
-
-Signed-off-by: Soeren Moch <smoch@web.de>
-Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- drivers/usb/host/ehci-sched.c | 2 ++
- 1 file changed, 2 insertions(+)
-
---- a/drivers/usb/host/ehci-sched.c
-+++ b/drivers/usb/host/ehci-sched.c
-@@ -1284,6 +1284,7 @@ itd_urb_transaction (
-
- memset (itd, 0, sizeof *itd);
- itd->itd_dma = itd_dma;
-+ itd->frame = 9999; /* an invalid value */
- list_add (&itd->itd_list, &sched->td_list);
- }
- spin_unlock_irqrestore (&ehci->lock, flags);
-@@ -1983,6 +1984,7 @@ sitd_urb_transaction (
-
- memset (sitd, 0, sizeof *sitd);
- sitd->sitd_dma = sitd_dma;
-+ sitd->frame = 9999; /* an invalid value */
- list_add (&sitd->sitd_list, &iso_sched->td_list);
- }
-
+signal-define-__arch_has_sa_restorer-so-we-know-whether-to-clear-3.0-3.2-3.4.patch
+kernel-signal.c-use-__arch_has_sa_restorer-instead-of-sa_restorer.patch
sunrpc-add-barriers-to-ensure-read-ordering-in-rpc_wake_up_task_queue_locked.patch
tile-expect-new-initramfs-name-from-hypervisor-file-system.patch
bluetooth-fix-not-closing-sco-sockets-in-the-bt_connect2-state.patch
mwifiex-cancel-cmd-timer-and-free-curr_cmd-in-shutdown-process.patch
pnfs-block-removing-dm-device-maybe-cause-oops-when-call-dev_remove.patch
net-irda-add-missing-error-path-release_sock-call.patch
-usb-ehci-fix-bug-in-itd-sitd-dma-pool-allocation.patch
usb-xhci-fix-trb-transfer-length-macro-used-for-event-trb.patch
btrfs-fix-race-between-mmap-writes-and-compression.patch
btrfs-limit-the-global-reserve-to-512mb.patch
btrfs-don-t-drop-path-when-printing-out-tree-errors-in-scrub.patch
usb-gadget-udc-core-fix-a-regression-during-gadget-driver-unbinding.patch
-signal-define-__arch_has_sa_restorer-so-we-know-whether-to-clear-3.0-3.2-3.4.patch
-kernel-signal.c-use-__arch_has_sa_restorer-instead-of-sa_restorer.patch
loop-prevent-bdev-freeing-while-device-in-use.patch
+++ /dev/null
-From 85ecd0322b9a1a9f451d9150e9460ab42fd17219 Mon Sep 17 00:00:00 2001
-From: Soeren Moch <smoch@web.de>
-Date: Fri, 22 Mar 2013 12:16:52 -0400
-Subject: USB: EHCI: fix bug in iTD/siTD DMA pool allocation
-
-From: Soeren Moch <smoch@web.de>
-
-commit 85ecd0322b9a1a9f451d9150e9460ab42fd17219 upstream.
-
-[Description written by Alan Stern]
-
-Soeren tracked down a very difficult bug in ehci-hcd's DMA pool
-management of iTD and siTD structures. Some background: ehci-hcd
-gives each isochronous endpoint its own set of active and free itd's
-(or sitd's for full-speed devices). When a new itd is needed, it is
-taken from the head of the free list, if possible. However, itd's
-must not be used twice in a single frame because the hardware
-continues to access the data structure for the entire duration of a
-frame. Therefore if the itd at the head of the free list has its
-"frame" member equal to the current value of ehci->now_frame, it
-cannot be reused and instead a new itd is allocated from the DMA pool.
-The entries on the free list are not released back to the pool until
-the endpoint is no longer in use.
-
-The bug arises from the fact that sometimes an itd can be moved back
-onto the free list before itd->frame has been set properly. In
-Soeren's case, this happened because ehci-hcd can allocate one more
-itd than it actually needs for an URB; the extra itd may or may not be
-required depending on how the transfer aligns with a frame boundary.
-For example, an URB with 8 isochronous packets will cause two itd's to
-be allocated. If the URB is scheduled to start in microframe 3 of
-frame N then it will require both itds: one for microframes 3 - 7 of
-frame N and one for microframes 0 - 2 of frame N+1. But if the URB
-had been scheduled to start in microframe 0 then it would require only
-the first itd, which could cover microframes 0 - 7 of frame N. The
-second itd would be returned to the end of the free list.
-
-The itd allocation routine initializes the entire structure to 0, so
-the extra itd ends up on the free list with itd->frame set to 0
-instead of a meaningful value. After a while the itd reaches the head
-of the list, and occasionally this happens when ehci->now_frame is
-equal to 0. Then, even though it would be okay to reuse this itd, the
-driver thinks it must get another itd from the DMA pool.
-
-For as long as the isochronous endpoint remains in use, this flaw in
-the mechanism causes more and more itd's to be taken slowly from the
-DMA pool. Since none are released back, the pool eventually becomes
-exhausted.
-
-This reuslts in memory allocation failures, which typically show up
-during a long-running audio stream. Video might suffer the same
-effect.
-
-The fix is very simple. To prevent allocations from the pool when
-they aren't needed, make sure that itd's sent back to the free list
-prematurely have itd->frame set to an invalid value which can never be
-equal to ehci->now_frame.
-
-This should be applied to -stable kernels going back to 3.6.
-
-Signed-off-by: Soeren Moch <smoch@web.de>
-Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- drivers/usb/host/ehci-sched.c | 2 ++
- 1 file changed, 2 insertions(+)
-
---- a/drivers/usb/host/ehci-sched.c
-+++ b/drivers/usb/host/ehci-sched.c
-@@ -1280,6 +1280,7 @@ itd_urb_transaction (
-
- memset (itd, 0, sizeof *itd);
- itd->itd_dma = itd_dma;
-+ itd->frame = 9999; /* an invalid value */
- list_add (&itd->itd_list, &sched->td_list);
- }
- spin_unlock_irqrestore (&ehci->lock, flags);
-@@ -1979,6 +1980,7 @@ sitd_urb_transaction (
-
- memset (sitd, 0, sizeof *sitd);
- sitd->sitd_dma = sitd_dma;
-+ sitd->frame = 9999; /* an invalid value */
- list_add (&sitd->sitd_list, &iso_sched->td_list);
- }
-
projects / thirdparty / kernel / stable-queue.git / commitdiff
