--- /dev/null
+From 276bdb82dedb290511467a5a4fdbe9f0b52dce6f Mon Sep 17 00:00:00 2001
+From: Mathias Krause <minipli@googlemail.com>
+Date: Wed, 15 Aug 2012 11:31:54 +0000
+Subject: dccp: check ccid before dereferencing
+
+From: Mathias Krause <minipli@googlemail.com>
+
+commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream.
+
+ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
+a NULL ccid pointer leading to a NULL pointer dereference. This could
+lead to a privilege escalation if the attacker is able to map page 0 and
+prepare it with a fake ccid_ops pointer.
+
+Signed-off-by: Mathias Krause <minipli@googlemail.com>
+Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/dccp/ccid.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/net/dccp/ccid.h
++++ b/net/dccp/ccid.h
+@@ -246,7 +246,7 @@ static inline int ccid_hc_rx_getsockopt(
+ u32 __user *optval, int __user *optlen)
+ {
+ int rc = -ENOPROTOOPT;
+- if (ccid->ccid_ops->ccid_hc_rx_getsockopt != NULL)
++ if (ccid != NULL && ccid->ccid_ops->ccid_hc_rx_getsockopt != NULL)
+ rc = ccid->ccid_ops->ccid_hc_rx_getsockopt(sk, optname, len,
+ optval, optlen);
+ return rc;
+@@ -257,7 +257,7 @@ static inline int ccid_hc_tx_getsockopt(
+ u32 __user *optval, int __user *optlen)
+ {
+ int rc = -ENOPROTOOPT;
+- if (ccid->ccid_ops->ccid_hc_tx_getsockopt != NULL)
++ if (ccid != NULL && ccid->ccid_ops->ccid_hc_tx_getsockopt != NULL)
+ rc = ccid->ccid_ops->ccid_hc_tx_getsockopt(sk, optname, len,
+ optval, optlen);
+ return rc;
--- /dev/null
+From c4903429a92be60e6fe59868924a65eca4cd1a38 Mon Sep 17 00:00:00 2001
+From: Dave Airlie <airlied@redhat.com>
+Date: Tue, 28 Aug 2012 21:40:51 -0400
+Subject: drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
+
+From: Dave Airlie <airlied@redhat.com>
+
+commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.
+
+This will cause udev to load vmwgfx instead of waiting for X
+to do it.
+
+Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+@@ -182,6 +182,7 @@ static struct pci_device_id vmw_pci_id_l
+ {0x15ad, 0x0405, PCI_ANY_ID, PCI_ANY_ID, 0, 0, VMWGFX_CHIP_SVGAII},
+ {0, 0, 0}
+ };
++MODULE_DEVICE_TABLE(pci, vmw_pci_id_list);
+
+ static int enable_fbdev;
+
--- /dev/null
+From d821a4c4d11ad160925dab2bb009b8444beff484 Mon Sep 17 00:00:00 2001
+From: Bruce Allan <bruce.w.allan@intel.com>
+Date: Fri, 24 Aug 2012 20:38:11 +0000
+Subject: e1000e: DoS while TSO enabled caused by link partner with small MSS
+
+From: Bruce Allan <bruce.w.allan@intel.com>
+
+commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.
+
+With a low enough MSS on the link partner and TSO enabled locally, the
+networking stack can periodically send a very large (e.g. 64KB) TCP
+message for which the driver will attempt to use more Tx descriptors than
+are available by default in the Tx ring. This is due to a workaround in
+the code that imposes a limit of only 4 MSS-sized segments per descriptor
+which appears to be a carry-over from the older e1000 driver and may be
+applicable only to some older PCI or PCIx parts which are not supported in
+e1000e. When the driver gets a message that is too large to fit across the
+configured number of Tx descriptors, it stops the upper stack from queueing
+any more and gets stuck in this state. After a timeout, the upper stack
+assumes the adapter is hung and calls the driver to reset it.
+
+Remove the unnecessary limitation of using up to only 4 MSS-sized segments
+per Tx descriptor, and put in a hard failure test to catch when attempting
+to check for message sizes larger than would fit in the whole Tx ring.
+Refactor the remaining logic that limits the size of data per Tx descriptor
+from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
+Tx packet buffer as described in the hardware specification.
+
+Also, fix the logic in the check for space in the Tx ring for the next
+largest possible packet after the current one has been successfully queued
+for transmit, and use the appropriate defines for default ring sizes in
+e1000_probe instead of magic values.
+
+This issue goes back to the introduction of e1000e in 2.6.24 when it was
+split off from e1000.
+
+Reported-by: Ben Hutchings <bhutchings@solarflare.com>
+Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
+Tested-by: Aaron Brown <aaron.f.brown@intel.com>
+Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/ethernet/intel/e1000e/e1000.h | 1
+ drivers/net/ethernet/intel/e1000e/netdev.c | 48 +++++++++++++----------------
+ 2 files changed, 24 insertions(+), 25 deletions(-)
+
+--- a/drivers/net/ethernet/intel/e1000e/e1000.h
++++ b/drivers/net/ethernet/intel/e1000e/e1000.h
+@@ -310,6 +310,7 @@ struct e1000_adapter {
+ */
+ struct e1000_ring *tx_ring /* One per active queue */
+ ____cacheline_aligned_in_smp;
++ u32 tx_fifo_limit;
+
+ struct napi_struct napi;
+
+--- a/drivers/net/ethernet/intel/e1000e/netdev.c
++++ b/drivers/net/ethernet/intel/e1000e/netdev.c
+@@ -3477,6 +3477,15 @@ void e1000e_reset(struct e1000_adapter *
+ }
+
+ /*
++ * Alignment of Tx data is on an arbitrary byte boundary with the
++ * maximum size per Tx descriptor limited only to the transmit
++ * allocation of the packet buffer minus 96 bytes with an upper
++ * limit of 24KB due to receive synchronization limitations.
++ */
++ adapter->tx_fifo_limit = min_t(u32, ((er32(PBA) >> 16) << 10) - 96,
++ 24 << 10);
++
++ /*
+ * Disable Adaptive Interrupt Moderation if 2 full packets cannot
+ * fit in receive buffer.
+ */
+@@ -4745,12 +4754,9 @@ static bool e1000_tx_csum(struct e1000_r
+ return 1;
+ }
+
+-#define E1000_MAX_PER_TXD 8192
+-#define E1000_MAX_TXD_PWR 12
+-
+ static int e1000_tx_map(struct e1000_ring *tx_ring, struct sk_buff *skb,
+ unsigned int first, unsigned int max_per_txd,
+- unsigned int nr_frags, unsigned int mss)
++ unsigned int nr_frags)
+ {
+ struct e1000_adapter *adapter = tx_ring->adapter;
+ struct pci_dev *pdev = adapter->pdev;
+@@ -4983,20 +4989,19 @@ static int __e1000_maybe_stop_tx(struct
+
+ static int e1000_maybe_stop_tx(struct e1000_ring *tx_ring, int size)
+ {
++ BUG_ON(size > tx_ring->count);
++
+ if (e1000_desc_unused(tx_ring) >= size)
+ return 0;
+ return __e1000_maybe_stop_tx(tx_ring, size);
+ }
+
+-#define TXD_USE_COUNT(S, X) (((S) >> (X)) + 1)
+ static netdev_tx_t e1000_xmit_frame(struct sk_buff *skb,
+ struct net_device *netdev)
+ {
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ struct e1000_ring *tx_ring = adapter->tx_ring;
+ unsigned int first;
+- unsigned int max_per_txd = E1000_MAX_PER_TXD;
+- unsigned int max_txd_pwr = E1000_MAX_TXD_PWR;
+ unsigned int tx_flags = 0;
+ unsigned int len = skb_headlen(skb);
+ unsigned int nr_frags;
+@@ -5016,18 +5021,8 @@ static netdev_tx_t e1000_xmit_frame(stru
+ }
+
+ mss = skb_shinfo(skb)->gso_size;
+- /*
+- * The controller does a simple calculation to
+- * make sure there is enough room in the FIFO before
+- * initiating the DMA for each buffer. The calc is:
+- * 4 = ceil(buffer len/mss). To make sure we don't
+- * overrun the FIFO, adjust the max buffer len if mss
+- * drops.
+- */
+ if (mss) {
+ u8 hdr_len;
+- max_per_txd = min(mss << 2, max_per_txd);
+- max_txd_pwr = fls(max_per_txd) - 1;
+
+ /*
+ * TSO Workaround for 82571/2/3 Controllers -- if skb->data
+@@ -5057,12 +5052,12 @@ static netdev_tx_t e1000_xmit_frame(stru
+ count++;
+ count++;
+
+- count += TXD_USE_COUNT(len, max_txd_pwr);
++ count += DIV_ROUND_UP(len, adapter->tx_fifo_limit);
+
+ nr_frags = skb_shinfo(skb)->nr_frags;
+ for (f = 0; f < nr_frags; f++)
+- count += TXD_USE_COUNT(skb_frag_size(&skb_shinfo(skb)->frags[f]),
+- max_txd_pwr);
++ count += DIV_ROUND_UP(skb_frag_size(&skb_shinfo(skb)->frags[f]),
++ adapter->tx_fifo_limit);
+
+ if (adapter->hw.mac.tx_pkt_filtering)
+ e1000_transfer_dhcp_info(adapter, skb);
+@@ -5104,15 +5099,18 @@ static netdev_tx_t e1000_xmit_frame(stru
+ tx_flags |= E1000_TX_FLAGS_NO_FCS;
+
+ /* if count is 0 then mapping error has occurred */
+- count = e1000_tx_map(tx_ring, skb, first, max_per_txd, nr_frags, mss);
++ count = e1000_tx_map(tx_ring, skb, first, adapter->tx_fifo_limit,
++ nr_frags);
+ if (count) {
+ skb_tx_timestamp(skb);
+
+ netdev_sent_queue(netdev, skb->len);
+ e1000_tx_queue(tx_ring, tx_flags, count);
+ /* Make sure there is space in the ring for the next send. */
+- e1000_maybe_stop_tx(tx_ring, MAX_SKB_FRAGS + 2);
+-
++ e1000_maybe_stop_tx(tx_ring,
++ (MAX_SKB_FRAGS *
++ DIV_ROUND_UP(PAGE_SIZE,
++ adapter->tx_fifo_limit) + 2));
+ } else {
+ dev_kfree_skb_any(skb);
+ tx_ring->buffer_info[first].time_stamp = 0;
+@@ -6284,8 +6282,8 @@ static int __devinit e1000_probe(struct
+ adapter->hw.phy.autoneg_advertised = 0x2f;
+
+ /* ring size defaults */
+- adapter->rx_ring->count = 256;
+- adapter->tx_ring->count = 256;
++ adapter->rx_ring->count = E1000_DEFAULT_RXD;
++ adapter->tx_ring->count = E1000_DEFAULT_TXD;
+
+ /*
+ * Initial Wake on LAN setting - If APM wake is enabled in
--- /dev/null
+From 67ddbb3e6568fb1820b2cc45b00c50702b114801 Mon Sep 17 00:00:00 2001
+From: Alan Stern <stern@rowland.harvard.edu>
+Date: Thu, 23 Aug 2012 10:51:55 -0400
+Subject: HID: add NOGET quirk for Eaton Ellipse MAX UPS
+
+From: Alan Stern <stern@rowland.harvard.edu>
+
+commit 67ddbb3e6568fb1820b2cc45b00c50702b114801 upstream.
+
+This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS
+device. (The USB IDs were already present in hid-ids.h, apparently
+under a different name.)
+
+Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
+Reported-by: Laurent Bigonville <l.bigonville@edpnet.be>
+Signed-off-by: Jiri Kosina <jkosina@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hid/usbhid/hid-quirks.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/hid/usbhid/hid-quirks.c
++++ b/drivers/hid/usbhid/hid-quirks.c
+@@ -70,6 +70,7 @@ static const struct hid_blacklist {
+ { USB_VENDOR_ID_CH, USB_DEVICE_ID_CH_AXIS_295, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
++ { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN1, HID_QUIRK_NO_INIT_REPORTS },
+ { USB_VENDOR_ID_PIXART, USB_DEVICE_ID_PIXART_OPTICAL_TOUCH_SCREEN2, HID_QUIRK_NO_INIT_REPORTS },
--- /dev/null
+From 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 Mon Sep 17 00:00:00 2001
+From: Luca Tettamanti <kronos.it@gmail.com>
+Date: Tue, 21 Aug 2012 17:36:28 +0200
+Subject: hwmon: (asus_atk0110) Add quirk for Asus M5A78L
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Luca Tettamanti <kronos.it@gmail.com>
+
+commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream.
+
+The old interface is bugged and reads the wrong sensor when retrieving
+the reading for the chassis fan (it reads the CPU sensor); the new
+interface works fine.
+
+Reported-by: Göran Uddeborg <goeran@uddeborg.se>
+Tested-by: Göran Uddeborg <goeran@uddeborg.se>
+Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/hwmon/asus_atk0110.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/hwmon/asus_atk0110.c
++++ b/drivers/hwmon/asus_atk0110.c
+@@ -34,6 +34,12 @@ static const struct dmi_system_id __init
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "SABERTOOTH X58")
+ }
++ }, {
++ /* Old interface reads the same sensor for fan0 and fan1 */
++ .ident = "Asus M5A78L",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_NAME, "M5A78L")
++ }
+ },
+ { }
+ };
--- /dev/null
+From 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 Mon Sep 17 00:00:00 2001
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Date: Tue, 21 Aug 2012 21:57:15 -0700
+Subject: Input: i8042 - add Gigabyte T1005 series netbooks to noloop table
+
+From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+
+commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream.
+
+They all define their chassis type as "Other" and therefore are not
+categorized as "laptops" by the driver, which tries to perform AUX IRQ
+delivery test which fails and causes touchpad not working.
+
+Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/serio/i8042-x86ia64io.h | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -177,6 +177,20 @@ static const struct dmi_system_id __init
+ },
+ },
+ {
++ /* Gigabyte T1005 - defines wrong chassis type ("Other") */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "T1005"),
++ },
++ },
++ {
++ /* Gigabyte T1005M/P - defines wrong chassis type ("Other") */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "T1005M/P"),
++ },
++ },
++ {
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP Pavilion dv9700"),
--- /dev/null
+From c1c52848cef52e157468b8879fc3cae23b6f3a99 Mon Sep 17 00:00:00 2001
+From: Grazvydas Ignotas <notasas@gmail.com>
+Date: Tue, 21 Aug 2012 09:09:48 +0300
+Subject: OMAPFB: fix framebuffer console colors
+
+From: Grazvydas Ignotas <notasas@gmail.com>
+
+commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.
+
+omapfb does not currently set pseudo palette correctly for color depths
+above 16bpp, making red text invisible, command like
+ echo -e '\e[0;31mRED' > /dev/tty1
+will display nothing on framebuffer console in 24bpp mode.
+This is because temporary variable is declared incorrectly, fix it.
+
+Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Signed-off-by: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/omap2/omapfb/omapfb-main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/video/omap2/omapfb/omapfb-main.c
++++ b/drivers/video/omap2/omapfb/omapfb-main.c
+@@ -1188,7 +1188,7 @@ static int _setcolreg(struct fb_info *fb
+ break;
+
+ if (regno < 16) {
+- u16 pal;
++ u32 pal;
+ pal = ((red >> (16 - var->red.length)) <<
+ var->red.offset) |
+ ((green >> (16 - var->green.length)) <<
--- /dev/null
+From bba3d8c3b3c0f2123be5bc687d1cddc13437c923 Mon Sep 17 00:00:00 2001
+From: Mel Gorman <mgorman@suse.de>
+Date: Mon, 23 Jul 2012 12:16:19 +0100
+Subject: PARISC: Redefine ATOMIC_INIT and ATOMIC64_INIT to drop the casts
+
+From: Mel Gorman <mgorman@suse.de>
+
+commit bba3d8c3b3c0f2123be5bc687d1cddc13437c923 upstream.
+
+The following build error occured during a parisc build with
+swap-over-NFS patches applied.
+
+net/core/sock.c:274:36: error: initializer element is not constant
+net/core/sock.c:274:36: error: (near initialization for 'memalloc_socks')
+net/core/sock.c:274:36: error: initializer element is not constant
+
+Dave Anglin says:
+> Here is the line in sock.i:
+>
+> struct static_key memalloc_socks = ((struct static_key) { .enabled =
+> ((atomic_t) { (0) }) });
+
+The above line contains two compound literals. It also uses a designated
+initializer to initialize the field enabled. A compound literal is not a
+constant expression.
+
+The location of the above statement isn't fully clear, but if a compound
+literal occurs outside the body of a function, the initializer list must
+consist of constant expressions.
+
+Reported-by: Fengguang Wu <fengguang.wu@intel.com>
+Signed-off-by: Mel Gorman <mgorman@suse.de>
+Signed-off-by: James Bottomley <JBottomley@Parallels.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/parisc/include/asm/atomic.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/parisc/include/asm/atomic.h
++++ b/arch/parisc/include/asm/atomic.h
+@@ -141,7 +141,7 @@ static __inline__ int __atomic_add_unles
+
+ #define atomic_sub_and_test(i,v) (atomic_sub_return((i),(v)) == 0)
+
+-#define ATOMIC_INIT(i) ((atomic_t) { (i) })
++#define ATOMIC_INIT(i) { (i) }
+
+ #define smp_mb__before_atomic_dec() smp_mb()
+ #define smp_mb__after_atomic_dec() smp_mb()
+@@ -150,7 +150,7 @@ static __inline__ int __atomic_add_unles
+
+ #ifdef CONFIG_64BIT
+
+-#define ATOMIC64_INIT(i) ((atomic64_t) { (i) })
++#define ATOMIC64_INIT(i) { (i) }
+
+ static __inline__ s64
+ __atomic64_add_return(s64 i, atomic64_t *v)
fuse-fix-retrieve-length.patch
i2c-designware-fix-build-error-if-config_i2c_designware_platform-y-config_i2c_designware_pci-y.patch
i2c-i801-add-device-ids-for-intel-lynx-point-lp-pch.patch
+hid-add-noget-quirk-for-eaton-ellipse-max-ups.patch
+input-i8042-add-gigabyte-t1005-series-netbooks-to-noloop-table.patch
+ubi-fix-a-horrible-memory-deallocation-bug.patch
+drm-vmwgfx-add-module_device_table-so-vmwgfx-loads-at-boot.patch
+omapfb-fix-framebuffer-console-colors.patch
+e1000e-dos-while-tso-enabled-caused-by-link-partner-with-small-mss.patch
+parisc-redefine-atomic_init-and-atomic64_init-to-drop-the-casts.patch
+xen-use-correct-masking-in-xen_swiotlb_alloc_coherent.patch
+xen-p2m-fix-one-off-error-in-checking-the-p2m-tree-directory.patch
+xen-pciback-fix-proper-flr-steps.patch
+uprobes-fix-mmap_region-s-mm-mm_rb-corruption-if-uprobe_mmap-fails.patch
+x86-microcode-amd-fix-broken-ucode-patch-size-check.patch
+dccp-check-ccid-before-dereferencing.patch
+hwmon-asus_atk0110-add-quirk-for-asus-m5a78l.patch
--- /dev/null
+From 78b495c39add820ab66ab897af9bd77a5f2e91f6 Mon Sep 17 00:00:00 2001
+From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
+Date: Mon, 3 Sep 2012 17:12:29 +0300
+Subject: UBI: fix a horrible memory deallocation bug
+
+From: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
+
+commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream.
+
+UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
+freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
+only when we were doing auto-format, so many systems were unaffected. However,
+there are still many users affected.
+
+It is strange, but the system did not crash and nothing bad happened when
+the SLUB memory allocator was used. However, in case of SLOB we observed an
+crash right away.
+
+This problem was introduced in 2.6.39 by commit
+"6c1e875 UBI: add slab cache for ubi_scan_leb objects"
+
+A note for stable trees:
+ Because variable were renamed, this won't cleanly apply to older kernels.
+ Changing names like this should help:
+ 1. ai -> si
+ 2. aeb_slab_cache -> seb_slab_cache
+ 3. new_aeb -> new_seb
+
+Reported-by: Richard Genoud <richard.genoud@gmail.com>
+Tested-by: Richard Genoud <richard.genoud@gmail.com>
+Tested-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
+Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/vtbl.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/ubi/vtbl.c
++++ b/drivers/mtd/ubi/vtbl.c
+@@ -340,7 +340,7 @@ retry:
+ * of this LEB as it will be deleted and freed in 'ubi_add_to_av()'.
+ */
+ err = ubi_add_to_av(ubi, ai, new_aeb->pnum, new_aeb->ec, vid_hdr, 0);
+- kfree(new_aeb);
++ kmem_cache_free(ai->aeb_slab_cache, new_aeb);
+ ubi_free_vid_hdr(ubi, vid_hdr);
+ return err;
+
+@@ -353,7 +353,7 @@ write_error:
+ list_add(&new_aeb->u.list, &ai->erase);
+ goto retry;
+ }
+- kfree(new_aeb);
++ kmem_cache_free(ai->aeb_slab_cache, new_aeb);
+ out_free:
+ ubi_free_vid_hdr(ubi, vid_hdr);
+ return err;
--- /dev/null
+From c7a3a88c938fbe3d70c2278e082b80eb830d1c58 Mon Sep 17 00:00:00 2001
+From: Oleg Nesterov <oleg@redhat.com>
+Date: Sun, 19 Aug 2012 19:10:42 +0200
+Subject: uprobes: Fix mmap_region()'s mm->mm_rb corruption if uprobe_mmap() fails
+
+From: Oleg Nesterov <oleg@redhat.com>
+
+commit c7a3a88c938fbe3d70c2278e082b80eb830d1c58 upstream.
+
+This patch fixes:
+
+ https://bugzilla.redhat.com/show_bug.cgi?id=843640
+
+If mmap_region()->uprobe_mmap() fails, unmap_and_free_vma path
+does unmap_region() but does not remove the soon-to-be-freed vma
+from rb tree. Actually there are more problems but this is how
+William noticed this bug.
+
+Perhaps we could do do_munmap() + return in this case, but in
+fact it is simply wrong to abort if uprobe_mmap() fails. Until
+at least we move the !UPROBE_COPY_INSN code from
+install_breakpoint() to uprobe_register().
+
+For example, uprobe_mmap()->install_breakpoint() can fail if the
+probed insn is not supported (remember, uprobe_register()
+succeeds if nobody mmaps inode/offset), mmap() should not fail
+in this case.
+
+dup_mmap()->uprobe_mmap() is wrong too by the same reason,
+fork() can race with uprobe_register() and fail for no reason if
+it wins the race and does install_breakpoint() first.
+
+And, if nothing else, both mmap_region() and dup_mmap() return
+success if uprobe_mmap() fails. Change them to ignore the error
+code from uprobe_mmap().
+
+Reported-and-tested-by: William Cohen <wcohen@redhat.com>
+Signed-off-by: Oleg Nesterov <oleg@redhat.com>
+Acked-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
+Cc: Anton Arapov <anton@redhat.com>
+Cc: William Cohen <wcohen@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Link: http://lkml.kernel.org/r/20120819171042.GB26957@redhat.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/fork.c | 4 ++--
+ mm/mmap.c | 5 ++---
+ 2 files changed, 4 insertions(+), 5 deletions(-)
+
+--- a/kernel/fork.c
++++ b/kernel/fork.c
+@@ -459,8 +459,8 @@ static int dup_mmap(struct mm_struct *mm
+ if (retval)
+ goto out;
+
+- if (file && uprobe_mmap(tmp))
+- goto out;
++ if (file)
++ uprobe_mmap(tmp);
+ }
+ /* a new mm has just been created */
+ arch_dup_mmap(oldmm, mm);
+--- a/mm/mmap.c
++++ b/mm/mmap.c
+@@ -1355,9 +1355,8 @@ out:
+ } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
+ make_pages_present(addr, addr + len);
+
+- if (file && uprobe_mmap(vma))
+- /* matching probes but cannot insert */
+- goto unmap_and_free_vma;
++ if (file)
++ uprobe_mmap(vma);
+
+ return addr;
+
--- /dev/null
+From 36bf50d7697be18c6bfd0401e037df10bff1e573 Mon Sep 17 00:00:00 2001
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+Date: Tue, 31 Jul 2012 15:41:45 +0200
+Subject: x86, microcode, AMD: Fix broken ucode patch size check
+
+From: Andreas Herrmann <andreas.herrmann3@amd.com>
+
+commit 36bf50d7697be18c6bfd0401e037df10bff1e573 upstream.
+
+This issue was recently observed on an AMD C-50 CPU where a patch of
+maximum size was applied.
+
+Commit be62adb49294 ("x86, microcode, AMD: Simplify ucode verification")
+added current_size in get_matching_microcode(). This is calculated as
+size of the ucode patch + 8 (ie. size of the header). Later this is
+compared against the maximum possible ucode patch size for a CPU family.
+And of course this fails if the patch has already maximum size.
+
+Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
+Signed-off-by: Borislav Petkov <borislav.petkov@amd.com>
+Link: http://lkml.kernel.org/r/1344361461-10076-1-git-send-email-bp@amd64.org
+Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/microcode_amd.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/microcode_amd.c
++++ b/arch/x86/kernel/microcode_amd.c
+@@ -143,11 +143,12 @@ static int get_matching_microcode(int cp
+ unsigned int *current_size)
+ {
+ struct microcode_header_amd *mc_hdr;
+- unsigned int actual_size;
++ unsigned int actual_size, patch_size;
+ u16 equiv_cpu_id;
+
+ /* size of the current patch we're staring at */
+- *current_size = *(u32 *)(ucode_ptr + 4) + SECTION_HDR_SIZE;
++ patch_size = *(u32 *)(ucode_ptr + 4);
++ *current_size = patch_size + SECTION_HDR_SIZE;
+
+ equiv_cpu_id = find_equiv_id();
+ if (!equiv_cpu_id)
+@@ -174,7 +175,7 @@ static int get_matching_microcode(int cp
+ /*
+ * now that the header looks sane, verify its size
+ */
+- actual_size = verify_ucode_size(cpu, *current_size, leftover_size);
++ actual_size = verify_ucode_size(cpu, patch_size, leftover_size);
+ if (!actual_size)
+ return 0;
+
--- /dev/null
+From 50e900417b8096939d12a46848f965e27a905e36 Mon Sep 17 00:00:00 2001
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Date: Tue, 4 Sep 2012 15:45:17 -0400
+Subject: xen/p2m: Fix one-off error in checking the P2M tree directory.
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+
+commit 50e900417b8096939d12a46848f965e27a905e36 upstream.
+
+We would traverse the full P2M top directory (from 0->MAX_DOMAIN_PAGES
+inclusive) when trying to figure out whether we can re-use some of the
+P2M middle leafs.
+
+Which meant that if the kernel was compiled with MAX_DOMAIN_PAGES=512
+we would try to use the 512th entry. Fortunately for us the p2m_top_index
+has a check for this:
+
+ BUG_ON(pfn >= MAX_P2M_PFN);
+
+which we hit and saw this:
+
+(XEN) domain_crash_sync called from entry.S
+(XEN) Domain 0 (vcpu#0) crashed on cpu#0:
+(XEN) ----[ Xen-4.1.2-OVM x86_64 debug=n Tainted: C ]----
+(XEN) CPU: 0
+(XEN) RIP: e033:[<ffffffff819cadeb>]
+(XEN) RFLAGS: 0000000000000212 EM: 1 CONTEXT: pv guest
+(XEN) rax: ffffffff81db5000 rbx: ffffffff81db4000 rcx: 0000000000000000
+(XEN) rdx: 0000000000480211 rsi: 0000000000000000 rdi: ffffffff81db4000
+(XEN) rbp: ffffffff81793db8 rsp: ffffffff81793d38 r8: 0000000008000000
+(XEN) r9: 4000000000000000 r10: 0000000000000000 r11: ffffffff81db7000
+(XEN) r12: 0000000000000ff8 r13: ffffffff81df1ff8 r14: ffffffff81db6000
+(XEN) r15: 0000000000000ff8 cr0: 000000008005003b cr4: 00000000000026f0
+(XEN) cr3: 0000000661795000 cr2: 0000000000000000
+
+Fixes-Oracle-Bug: 14570662
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/xen/p2m.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/xen/p2m.c
++++ b/arch/x86/xen/p2m.c
+@@ -599,7 +599,7 @@ bool __init early_can_reuse_p2m_middle(u
+ if (p2m_index(set_pfn))
+ return false;
+
+- for (pfn = 0; pfn <= MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
++ for (pfn = 0; pfn < MAX_DOMAIN_PAGES; pfn += P2M_PER_PAGE) {
+ topidx = p2m_top_index(pfn);
+
+ if (!p2m_top[topidx])
--- /dev/null
+From 80ba77dfbce85f2d1be54847de3c866de1b18a9a Mon Sep 17 00:00:00 2001
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Date: Wed, 5 Sep 2012 16:35:20 -0400
+Subject: xen/pciback: Fix proper FLR steps.
+
+From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+
+commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a upstream.
+
+When we do FLR and save PCI config we did it in the wrong order.
+The end result was that if a PCI device was unbind from
+its driver, then binded to xen-pciback, and then back to its
+driver we would get:
+
+> lspci -s 04:00.0
+04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
+13:42:12 # 4 :~/
+> echo "0000:04:00.0" > /sys/bus/pci/drivers/pciback/unbind
+> modprobe e1000e
+e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
+e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
+e1000e 0000:04:00.0: Disabling ASPM L0s L1
+e1000e 0000:04:00.0: enabling device (0000 -> 0002)
+xen: registering gsi 48 triggering 0 polarity 1
+Already setup the GSI :48
+e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
+e1000e: probe of 0000:04:00.0 failed with error -2
+
+This fixes it by first saving the PCI configuration space, then
+doing the FLR.
+
+Reported-by: Ren, Yongjie <yongjie.ren@intel.com>
+Reported-and-Tested-by: Tobias Geiger <tobias.geiger@vido.info>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/xen-pciback/pci_stub.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/xen/xen-pciback/pci_stub.c
++++ b/drivers/xen/xen-pciback/pci_stub.c
+@@ -353,16 +353,16 @@ static int __devinit pcistub_init_device
+ if (err)
+ goto config_release;
+
+- dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
+- __pci_reset_function_locked(dev);
+-
+ /* We need the device active to save the state. */
+ dev_dbg(&dev->dev, "save state of device\n");
+ pci_save_state(dev);
+ dev_data->pci_saved_state = pci_store_saved_state(dev);
+ if (!dev_data->pci_saved_state)
+ dev_err(&dev->dev, "Could not store PCI conf saved state!\n");
+-
++ else {
++ dev_dbg(&dev->dev, "reseting (FLR, D3, etc) the device\n");
++ __pci_reset_function_locked(dev);
++ }
+ /* Now disable the device (this also ensures some private device
+ * data is setup before we export)
+ */
--- /dev/null
+From b5031ed1be0aa419250557123633453753181643 Mon Sep 17 00:00:00 2001
+From: Ronny Hegewald <ronny.hegewald@online.de>
+Date: Fri, 31 Aug 2012 09:57:52 +0000
+Subject: xen: Use correct masking in xen_swiotlb_alloc_coherent.
+
+From: Ronny Hegewald <ronny.hegewald@online.de>
+
+commit b5031ed1be0aa419250557123633453753181643 upstream.
+
+When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
+DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.
+
+The underlaying reason is that if the supplied driver passes in a
+DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff)
+our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
+DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
+By using the dma_alloc_coherent_mask function - it does the proper casting
+and we get 0xfffffffff.
+
+This caused not working sound on a system with 4 GB and a 64-bit
+compatible sound-card with sets the DMA-mask to 64bit.
+
+On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
+DMA-memory is always allocated inside the 32-bit address-range by calling
+dma_alloc_coherent_mask.
+
+This patch adds the same functionality to xen swiotlb and is a rebase of the
+original patch from Ronny Hegewald which never got upstream b/c the
+underlaying reason was not understood until now.
+
+The original email with the original patch is in:
+http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
+the original thread from where the discussion started is in:
+http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html
+
+Signed-off-by: Ronny Hegewald <ronny.hegewald@online.de>
+Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
+Acked-By: David Vrabel <david.vrabel@citrix.com>
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/swiotlb-xen.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/xen/swiotlb-xen.c
++++ b/drivers/xen/swiotlb-xen.c
+@@ -232,7 +232,7 @@ xen_swiotlb_alloc_coherent(struct device
+ return ret;
+
+ if (hwdev && hwdev->coherent_dma_mask)
+- dma_mask = hwdev->coherent_dma_mask;
++ dma_mask = dma_alloc_coherent_mask(hwdev, flags);
+
+ phys = virt_to_phys(ret);
+ dev_addr = xen_phys_to_bus(phys);
projects / thirdparty / kernel / stable-queue.git / commitdiff
