From: Greg Kroah-Hartman Date: Sun, 7 Dec 2014 06:22:58 +0000 (-0800) Subject: 3.14-stable patches X-Git-Tag: v3.10.63~15 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4eaae28f8c26db47dfc98e7d3ab42b6e987faaef;p=thirdparty%2Fkernel%2Fstable-queue.git 3.14-stable patches added patches: drm-i915-more-cautious-with-pch-fifo-underruns.patch drm-i915-unlock-panel-even-when-lvds-is-disabled.patch drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch i2c-davinci-generate-stp-always-when-nack-is-received.patch i2c-omap-fix-i207-errata-handling.patch i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch media-smiapp-only-some-selection-targets-are-settable.patch mm-fix-anon_vma_clone-error-treatment.patch mm-fix-swapoff-hang-after-page-migration-and-fork.patch mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch usb-xhci-reset-a-halted-endpoint-immediately-when-we-encounter-a-stall.patch x86-use-objdump-instead-of-plain-objdump.patch xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch --- diff --git a/queue-3.14/drm-i915-more-cautious-with-pch-fifo-underruns.patch b/queue-3.14/drm-i915-more-cautious-with-pch-fifo-underruns.patch new file mode 100644 index 00000000000..7a90e775b4f --- /dev/null +++ b/queue-3.14/drm-i915-more-cautious-with-pch-fifo-underruns.patch @@ -0,0 +1,57 @@ +From b68362278af94e1171f5be9d4e44988601fb0439 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Mon, 24 Nov 2014 17:02:45 +0100 +Subject: drm/i915: More cautious with pch fifo underruns + +From: Daniel Vetter + +commit b68362278af94e1171f5be9d4e44988601fb0439 upstream. + +Apparently PCH fifo underruns are tricky, we have plenty reports that +we see the occasional underrun (especially at boot-up). + +So for a change let's see what happens when we don't re-enable pch +fifo underrun reporting when the pipe is disabled. This means that the +kernel can't catch pch fifo underruns when they happen (except when +all pipes are on on the pch). But we'll still catch underruns when +disabling the pipe again. So not a terrible reduction in test +coverage. + +Since the DRM_ERROR is new and hence a regression plan B would be to +revert it back to a debug output. Which would be a lot worse than this +hack for underrun test coverage in the wild. See the referenced +discussions for more. + +References: http://mid.gmane.org/CA+gsUGRfGe3t4NcjdeA=qXysrhLY3r4CEu7z4bjTwxi1uOfy+g@mail.gmail.com +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85898 +References: https://bugs.freedesktop.org/show_bug.cgi?id=85898 +References: https://bugs.freedesktop.org/show_bug.cgi?id=86233 +References: https://bugs.freedesktop.org/show_bug.cgi?id=86478 +Signed-off-by: Daniel Vetter +Tested-by: lu hua +Reviewed-by: Paulo Zanoni +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_display.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -3817,7 +3817,6 @@ static void ironlake_crtc_disable(struct + ironlake_fdi_disable(crtc); + + ironlake_disable_pch_transcoder(dev_priv, pipe); +- intel_set_pch_fifo_underrun_reporting(dev, pipe, true); + + if (HAS_PCH_CPT(dev)) { + /* disable TRANS_DP_CTL */ +@@ -3883,7 +3882,6 @@ static void haswell_crtc_disable(struct + + if (intel_crtc->config.has_pch_encoder) { + lpt_disable_pch_transcoder(dev_priv); +- intel_set_pch_fifo_underrun_reporting(dev, TRANSCODER_A, true); + intel_ddi_fdi_disable(crtc); + } + diff --git a/queue-3.14/drm-i915-unlock-panel-even-when-lvds-is-disabled.patch b/queue-3.14/drm-i915-unlock-panel-even-when-lvds-is-disabled.patch new file mode 100644 index 00000000000..4da6e26efb6 --- /dev/null +++ b/queue-3.14/drm-i915-unlock-panel-even-when-lvds-is-disabled.patch @@ -0,0 +1,70 @@ +From b0616c5306b342ceca07044dbc4f917d95c4f825 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Mon, 1 Dec 2014 17:56:54 +0100 +Subject: drm/i915: Unlock panel even when LVDS is disabled + +From: Daniel Vetter + +commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream. + +Otherwise we'll have backtraces in assert_panel_unlocked because the +BIOS locks the register. In the reporter's case this regression was +introduced in + +commit c31407a3672aaebb4acddf90944a114fa5c8af7b +Author: Chris Wilson +Date: Thu Oct 18 21:07:01 2012 +0100 + + drm/i915: Add no-lvds quirk for Supermicro X7SPA-H + +Reported-by: Alexey Orishko +Cc: Alexey Orishko +Cc: Chris Wilson +Cc: Francois Tigeot +Signed-off-by: Daniel Vetter +Tested-by: Alexey Orishko +Signed-off-by: Jani Nikula +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_lvds.c | 22 +++++++++++----------- + 1 file changed, 11 insertions(+), 11 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_lvds.c ++++ b/drivers/gpu/drm/i915/intel_lvds.c +@@ -905,6 +905,17 @@ void intel_lvds_init(struct drm_device * + int pipe; + u8 pin; + ++ /* ++ * Unlock registers and just leave them unlocked. Do this before ++ * checking quirk lists to avoid bogus WARNINGs. ++ */ ++ if (HAS_PCH_SPLIT(dev)) { ++ I915_WRITE(PCH_PP_CONTROL, ++ I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS); ++ } else { ++ I915_WRITE(PP_CONTROL, ++ I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS); ++ } + if (!intel_lvds_supported(dev)) + return; + +@@ -1099,17 +1110,6 @@ out: + DRM_DEBUG_KMS("detected %s-link lvds configuration\n", + lvds_encoder->is_dual_link ? "dual" : "single"); + +- /* +- * Unlock registers and just +- * leave them unlocked +- */ +- if (HAS_PCH_SPLIT(dev)) { +- I915_WRITE(PCH_PP_CONTROL, +- I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS); +- } else { +- I915_WRITE(PP_CONTROL, +- I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS); +- } + lvds_connector->lid_notifier.notifier_call = intel_lid_notify; + if (acpi_lid_notifier_register(&lvds_connector->lid_notifier)) { + DRM_DEBUG_KMS("lid notifier registration failed\n"); diff --git a/queue-3.14/drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch b/queue-3.14/drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch new file mode 100644 index 00000000000..583225dccfc --- /dev/null +++ b/queue-3.14/drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch @@ -0,0 +1,133 @@ +From f5475cc43c899e33098d4db44b7c5e710f16589d Mon Sep 17 00:00:00 2001 +From: Petr Mladek +Date: Thu, 27 Nov 2014 16:57:21 +0100 +Subject: drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 + +From: Petr Mladek + +commit f5475cc43c899e33098d4db44b7c5e710f16589d upstream. + +I was unable too boot 3.18.0-rc6 because of the following kernel +panic in drm_calc_vbltimestamp_from_scanoutpos(): + + [drm] Initialized drm 1.1.0 20060810 + [drm] radeon kernel modesetting enabled. + [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080). + [drm] register mmio base: 0xC8400000 + [drm] register mmio size: 65536 + radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used) + radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF + [drm] Detected VRAM RAM=128M, BAR=128M + [drm] RAM width 16bits DDR + [TTM] Zone kernel: Available graphics memory: 3829346 kiB + [TTM] Zone dma32: Available graphics memory: 2097152 kiB + [TTM] Initializing pool allocator + [TTM] Initializing DMA pool allocator + [drm] radeon: 16M of VRAM memory ready + [drm] radeon: 512M of GTT memory ready. + [drm] GART: num cpu pages 131072, num gpu pages 131072 + [drm] PCI GART of 512M enabled (table at 0x0000000037880000). + radeon 0000:0b:01.0: WB disabled + radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000 + [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). + [drm] Driver supports precise vblank timestamp query. + [drm] radeon: irq initialized. + [drm] Loading R100 Microcode + radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2 + radeon_cp: Failed to load firmware "radeon/R100_cp.bin" + [drm:r100_cp_init] *ERROR* Failed to load firmware! + radeon 0000:0b:01.0: failed initializing CP (-2). + radeon 0000:0b:01.0: Disabling GPU acceleration + [drm] radeon: cp finalized + BUG: unable to handle kernel NULL pointer dereference at 000000000000025c + IP: [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 + PGD 0 + Oops: 0000 [#1] SMP + Modules linked in: + CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649 + Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006 + task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000 + RIP: 0010:[] [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 + RSP: 0000:ffff880234da7918 EFLAGS: 00010086 + RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48 + RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000 + RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000 + R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0 + R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000 + FS: 0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b + CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0 + Stack: + ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480 + ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d + ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58 + Call Trace: + [] ? drm_vma_offset_remove+0x1d/0x110 + [] radeon_get_vblank_timestamp_kms+0x38/0x60 + [] ? ttm_bo_release_list+0xba/0x180 + [] drm_get_last_vbltimestamp+0x41/0x70 + [] vblank_disable_and_save+0x73/0x1d0 + [] ? try_to_del_timer_sync+0x4f/0x70 + [] drm_vblank_cleanup+0x65/0xa0 + [] radeon_irq_kms_fini+0x1a/0x70 + [] r100_init+0x26e/0x410 + [] radeon_device_init+0x7ae/0xb50 + [] radeon_driver_load_kms+0x8f/0x210 + [] drm_dev_register+0xb5/0x110 + [] drm_get_pci_dev+0x8f/0x200 + [] radeon_pci_probe+0xad/0xe0 + [] local_pci_probe+0x45/0xa0 + [] pci_device_probe+0xd1/0x130 + [] driver_probe_device+0x12d/0x3e0 + [] __driver_attach+0x9b/0xa0 + [] ? __device_attach+0x40/0x40 + [] bus_for_each_dev+0x63/0xa0 + [] driver_attach+0x1e/0x20 + [] bus_add_driver+0x180/0x240 + [] driver_register+0x64/0xf0 + [] __pci_register_driver+0x4c/0x50 + [] drm_pci_init+0xf5/0x120 + [] ? ttm_init+0x6a/0x6a + [] radeon_init+0x97/0xb5 + [] do_one_initcall+0xbc/0x1f0 + [] ? __wake_up+0x48/0x60 + [] kernel_init_freeable+0x18a/0x215 + [] ? initcall_blacklist+0xc0/0xc0 + [] ? rest_init+0x80/0x80 + [] kernel_init+0xe/0xf0 + [] ret_from_fork+0x7c/0xb0 + [] ? rest_init+0x80/0x80 + Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60 + RIP [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320 + RSP + CR2: 000000000000025c + ---[ end trace ad2c0aadf48e2032 ]--- + Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 + +It has helped me to add a NULL pointer check that was suggested at +http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html + +I am not familiar with the code. But the change looks sane +and we need something fast at this stage of 3.18 development. + +Suggested-by: Helge Deller +Signed-off-by: Petr Mladek +Tested-by: Petr Mladek +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/radeon_kms.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/gpu/drm/radeon/radeon_kms.c ++++ b/drivers/gpu/drm/radeon/radeon_kms.c +@@ -740,6 +740,8 @@ int radeon_get_vblank_timestamp_kms(stru + + /* Get associated drm_crtc: */ + drmcrtc = &rdev->mode_info.crtcs[crtc]->base; ++ if (!drmcrtc) ++ return -EINVAL; + + /* Helper routine in DRM core does all the work: */ + return drm_calc_vbltimestamp_from_scanoutpos(dev, crtc, max_error, diff --git a/queue-3.14/i2c-davinci-generate-stp-always-when-nack-is-received.patch b/queue-3.14/i2c-davinci-generate-stp-always-when-nack-is-received.patch new file mode 100644 index 00000000000..ea8f65e0441 --- /dev/null +++ b/queue-3.14/i2c-davinci-generate-stp-always-when-nack-is-received.patch @@ -0,0 +1,65 @@ +From 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 Mon Sep 17 00:00:00 2001 +From: Grygorii Strashko +Date: Mon, 1 Dec 2014 17:34:04 +0200 +Subject: i2c: davinci: generate STP always when NACK is received +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Grygorii Strashko + +commit 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 upstream. + +According to I2C specification the NACK should be handled as follows: +"When SDA remains HIGH during this ninth clock pulse, this is defined as the Not +Acknowledge signal. The master can then generate either a STOP condition to +abort the transfer, or a repeated START condition to start a new transfer." +[I2C spec Rev. 6, 3.1.6: http://www.nxp.com/documents/user_manual/UM10204.pdf] + +Currently the Davinci i2c driver interrupts the transfer on receipt of a +NACK but fails to send a STOP in some situations and so makes the bus +stuck until next I2C IP reset (idle/enable). + +For example, the issue will happen during SMBus read transfer which +consists from two i2c messages write command/address and read data: + +S Slave Address Wr A Command Code A Sr Slave Address Rd A D1..Dn A P +<--- write -----------------------> <--- read ---------------------> + +The I2C client device will send NACK if it can't recognize "Command Code" +and it's expected from I2C master to generate STP in this case. +But now, Davinci i2C driver will just exit with -EREMOTEIO and STP will +not be generated. + +Hence, fix it by generating Stop condition (STP) always when NACK is received. + +This patch fixes Davinci I2C in the same way it was done for OMAP I2C +commit cda2109a26eb ("i2c: omap: query STP always when NACK is received"). + +Reviewed-by: Uwe Kleine-König +Reported-by: Hein Tibosch +Signed-off-by: Grygorii Strashko +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-davinci.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/drivers/i2c/busses/i2c-davinci.c ++++ b/drivers/i2c/busses/i2c-davinci.c +@@ -411,11 +411,9 @@ i2c_davinci_xfer_msg(struct i2c_adapter + if (dev->cmd_err & DAVINCI_I2C_STR_NACK) { + if (msg->flags & I2C_M_IGNORE_NAK) + return msg->len; +- if (stop) { +- w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); +- w |= DAVINCI_I2C_MDR_STP; +- davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); +- } ++ w = davinci_i2c_read_reg(dev, DAVINCI_I2C_MDR_REG); ++ w |= DAVINCI_I2C_MDR_STP; ++ davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, w); + return -EREMOTEIO; + } + return -EIO; diff --git a/queue-3.14/i2c-omap-fix-i207-errata-handling.patch b/queue-3.14/i2c-omap-fix-i207-errata-handling.patch new file mode 100644 index 00000000000..fb529571065 --- /dev/null +++ b/queue-3.14/i2c-omap-fix-i207-errata-handling.patch @@ -0,0 +1,53 @@ +From ccfc866356674cb3a61829d239c685af6e85f197 Mon Sep 17 00:00:00 2001 +From: Alexander Kochetkov +Date: Fri, 21 Nov 2014 04:16:51 +0400 +Subject: i2c: omap: fix i207 errata handling + +From: Alexander Kochetkov + +commit ccfc866356674cb3a61829d239c685af6e85f197 upstream. + +commit 6d9939f651419a63e091105663821f9c7d3fec37 (i2c: omap: split out [XR]DR +and [XR]RDY) changed the way how errata i207 (I2C: RDR Flag May Be Incorrectly +Set) get handled. 6d9939f6514 code doesn't correspond to workaround provided by +errata. + +According to errata ISR must filter out spurious RDR before data read not after. +ISR must read RXSTAT to get number of bytes available to read. Because RDR +could be set while there could no data in the receive FIFO. + +Restored pre 6d9939f6514 way of handling errata. + +Found by code review. Real impact haven't seen. +Tested on Beagleboard XM C. + +Signed-off-by: Alexander Kochetkov +Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY +Tested-by: Felipe Balbi +Reviewed-by: Felipe Balbi +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-omap.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/drivers/i2c/busses/i2c-omap.c ++++ b/drivers/i2c/busses/i2c-omap.c +@@ -956,11 +956,13 @@ omap_i2c_isr_thread(int this_irq, void * + if (dev->fifo_size) + num_bytes = dev->buf_len; + +- omap_i2c_receive_data(dev, num_bytes, true); +- +- if (dev->errata & I2C_OMAP_ERRATA_I207) ++ if (dev->errata & I2C_OMAP_ERRATA_I207) { + i2c_omap_errata_i207(dev, stat); ++ num_bytes = (omap_i2c_read_reg(dev, ++ OMAP_I2C_BUFSTAT_REG) >> 8) & 0x3F; ++ } + ++ omap_i2c_receive_data(dev, num_bytes, true); + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR); + continue; + } diff --git a/queue-3.14/i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch b/queue-3.14/i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch new file mode 100644 index 00000000000..81ff9fd4568 --- /dev/null +++ b/queue-3.14/i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch @@ -0,0 +1,70 @@ +From 27caca9d2e01c92b26d0690f065aad093fea01c7 Mon Sep 17 00:00:00 2001 +From: Alexander Kochetkov +Date: Tue, 18 Nov 2014 21:00:58 +0400 +Subject: i2c: omap: fix NACK and Arbitration Lost irq handling + +From: Alexander Kochetkov + +commit 27caca9d2e01c92b26d0690f065aad093fea01c7 upstream. + +commit 1d7afc95946487945cc7f5019b41255b72224b70 (i2c: omap: ack IRQ in parts) +changed the interrupt handler to complete transfers without clearing +XRDY (AL case) and ARDY (NACK case) flags. XRDY or ARDY interrupts will be +fired again. As a result, ISR keep processing transfer after it was already +complete (from the driver code point of view). + +A didn't see real impacts of the 1d7afc9, but it is really bad idea to +have ISR running on user data after transfer was complete. + +It looks, what 1d7afc9 violate TI specs in what how AL and NACK should be +handled (see Note 1, sprugn4r, Figure 17-31 and Figure 17-32). + +According to specs (if I understood correctly), in case of NACK and AL driver +must reset NACK, AL, ARDY, RDR, and RRDY (Master Receive Mode), and +NACK, AL, ARDY, and XDR (Master Transmitter Mode). + +All that is done down the code under the if condition: +if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) ... + +The patch restore pre 1d7afc9 logic of handling NACK and AL interrupts, so +no interrupts is fired after ISR informs the rest of driver what transfer +complete. + +Note: instead of removing break under NACK case, we could just replace 'break' +with 'continue' and allow NACK transfer to finish using ARDY event. I found +that NACK and ARDY bits usually set together. That case confirm TI wiki: +http://processors.wiki.ti.com/index.php/I2C_Tips#Detecting_and_handling_NACK + +In order if someone interested in the event traces for NACK and AL cases, +I sent them to mailing list. + +Tested on Beagleboard XM C. + +Signed-off-by: Alexander Kochetkov +Fixes: 1d7afc9 i2c: omap: ack IRQ in parts +Acked-by: Felipe Balbi +Tested-by: Aaro Koskinen +Signed-off-by: Wolfram Sang +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/i2c/busses/i2c-omap.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/drivers/i2c/busses/i2c-omap.c ++++ b/drivers/i2c/busses/i2c-omap.c +@@ -926,14 +926,12 @@ omap_i2c_isr_thread(int this_irq, void * + if (stat & OMAP_I2C_STAT_NACK) { + err |= OMAP_I2C_STAT_NACK; + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK); +- break; + } + + if (stat & OMAP_I2C_STAT_AL) { + dev_err(dev->dev, "Arbitration lost\n"); + err |= OMAP_I2C_STAT_AL; + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_AL); +- break; + } + + /* diff --git a/queue-3.14/media-smiapp-only-some-selection-targets-are-settable.patch b/queue-3.14/media-smiapp-only-some-selection-targets-are-settable.patch new file mode 100644 index 00000000000..4e89410c086 --- /dev/null +++ b/queue-3.14/media-smiapp-only-some-selection-targets-are-settable.patch @@ -0,0 +1,33 @@ +From b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 Mon Sep 17 00:00:00 2001 +From: Sakari Ailus +Date: Thu, 6 Nov 2014 17:49:45 -0300 +Subject: media: smiapp: Only some selection targets are settable + +From: Sakari Ailus + +commit b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 upstream. + +Setting a non-settable selection target caused BUG() to be called. The check +for valid selections only takes the selection target into account, but does +not tell whether it may be set, or only get. Fix the issue by simply +returning an error to the user. + +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/media/i2c/smiapp/smiapp-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/media/i2c/smiapp/smiapp-core.c ++++ b/drivers/media/i2c/smiapp/smiapp-core.c +@@ -2138,7 +2138,7 @@ static int smiapp_set_selection(struct v + ret = smiapp_set_compose(subdev, fh, sel); + break; + default: +- BUG(); ++ ret = -EINVAL; + } + + mutex_unlock(&sensor->mutex); diff --git a/queue-3.14/mm-fix-anon_vma_clone-error-treatment.patch b/queue-3.14/mm-fix-anon_vma_clone-error-treatment.patch new file mode 100644 index 00000000000..74b4ac2612e --- /dev/null +++ b/queue-3.14/mm-fix-anon_vma_clone-error-treatment.patch @@ -0,0 +1,90 @@ +From c4ea95d7cd08d9ffd7fa75e6c5e0332d596dd11e Mon Sep 17 00:00:00 2001 +From: Daniel Forrest +Date: Tue, 2 Dec 2014 15:59:42 -0800 +Subject: mm: fix anon_vma_clone() error treatment + +From: Daniel Forrest + +commit c4ea95d7cd08d9ffd7fa75e6c5e0332d596dd11e upstream. + +Andrew Morton noticed that the error return from anon_vma_clone() was +being dropped and replaced with -ENOMEM (which is not itself a bug +because the only error return value from anon_vma_clone() is -ENOMEM). + +I did an audit of callers of anon_vma_clone() and discovered an actual +bug where the error return was being lost. In __split_vma(), between +Linux 3.11 and 3.12 the code was changed so the err variable is used +before the call to anon_vma_clone() and the default initial value of +-ENOMEM is overwritten. So a failure of anon_vma_clone() will return +success since err at this point is now zero. + +Below is a patch which fixes this bug and also propagates the error +return value from anon_vma_clone() in all cases. + +Fixes: ef0855d334e1 ("mm: mempolicy: turn vma_set_policy() into vma_dup_policy()") +Signed-off-by: Daniel Forrest +Reviewed-by: Michal Hocko +Cc: Konstantin Khlebnikov +Cc: Andrea Arcangeli +Cc: Rik van Riel +Cc: Tim Hartrick +Cc: Hugh Dickins +Cc: Michel Lespinasse +Cc: Vlastimil Babka +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/mmap.c | 10 +++++++--- + mm/rmap.c | 6 ++++-- + 2 files changed, 11 insertions(+), 5 deletions(-) + +--- a/mm/mmap.c ++++ b/mm/mmap.c +@@ -745,8 +745,11 @@ again: remove_next = 1 + (end > next-> + * shrinking vma had, to cover any anon pages imported. + */ + if (exporter && exporter->anon_vma && !importer->anon_vma) { +- if (anon_vma_clone(importer, exporter)) +- return -ENOMEM; ++ int error; ++ ++ error = anon_vma_clone(importer, exporter); ++ if (error) ++ return error; + importer->anon_vma = exporter->anon_vma; + } + } +@@ -2428,7 +2431,8 @@ static int __split_vma(struct mm_struct + if (err) + goto out_free_vma; + +- if (anon_vma_clone(new, vma)) ++ err = anon_vma_clone(new, vma); ++ if (err) + goto out_free_mpol; + + if (new->vm_file) +--- a/mm/rmap.c ++++ b/mm/rmap.c +@@ -274,6 +274,7 @@ int anon_vma_fork(struct vm_area_struct + { + struct anon_vma_chain *avc; + struct anon_vma *anon_vma; ++ int error; + + /* Don't bother if the parent process has no anon_vma here. */ + if (!pvma->anon_vma) +@@ -283,8 +284,9 @@ int anon_vma_fork(struct vm_area_struct + * First, attach the new VMA to the parent VMA's anon_vmas, + * so rmap can find non-COWed pages in child processes. + */ +- if (anon_vma_clone(vma, pvma)) +- return -ENOMEM; ++ error = anon_vma_clone(vma, pvma); ++ if (error) ++ return error; + + /* Then add our own anon_vma. */ + anon_vma = anon_vma_alloc(); diff --git a/queue-3.14/mm-fix-swapoff-hang-after-page-migration-and-fork.patch b/queue-3.14/mm-fix-swapoff-hang-after-page-migration-and-fork.patch new file mode 100644 index 00000000000..70e53547aa3 --- /dev/null +++ b/queue-3.14/mm-fix-swapoff-hang-after-page-migration-and-fork.patch @@ -0,0 +1,70 @@ +From 2022b4d18a491a578218ce7a4eca8666db895a73 Mon Sep 17 00:00:00 2001 +From: Hugh Dickins +Date: Tue, 2 Dec 2014 15:59:39 -0800 +Subject: mm: fix swapoff hang after page migration and fork + +From: Hugh Dickins + +commit 2022b4d18a491a578218ce7a4eca8666db895a73 upstream. + +I've been seeing swapoff hangs in recent testing: it's cycling around +trying unsuccessfully to find an mm for some remaining pages of swap. + +I have been exercising swap and page migration more heavily recently, +and now notice a long-standing error in copy_one_pte(): it's trying to +add dst_mm to swapoff's mmlist when it finds a swap entry, but is doing +so even when it's a migration entry or an hwpoison entry. + +Which wouldn't matter much, except it adds dst_mm next to src_mm, +assuming src_mm is already on the mmlist: which may not be so. Then if +pages are later swapped out from dst_mm, swapoff won't be able to find +where to replace them. + +There's already a !non_swap_entry() test for stats: move that up before +the swap_duplicate() and the addition to mmlist. + +Signed-off-by: Hugh Dickins +Cc: Kelley Nielsen +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/memory.c | 24 ++++++++++++------------ + 1 file changed, 12 insertions(+), 12 deletions(-) + +--- a/mm/memory.c ++++ b/mm/memory.c +@@ -808,20 +808,20 @@ copy_one_pte(struct mm_struct *dst_mm, s + if (!pte_file(pte)) { + swp_entry_t entry = pte_to_swp_entry(pte); + +- if (swap_duplicate(entry) < 0) +- return entry.val; ++ if (likely(!non_swap_entry(entry))) { ++ if (swap_duplicate(entry) < 0) ++ return entry.val; + +- /* make sure dst_mm is on swapoff's mmlist. */ +- if (unlikely(list_empty(&dst_mm->mmlist))) { +- spin_lock(&mmlist_lock); +- if (list_empty(&dst_mm->mmlist)) +- list_add(&dst_mm->mmlist, +- &src_mm->mmlist); +- spin_unlock(&mmlist_lock); +- } +- if (likely(!non_swap_entry(entry))) ++ /* make sure dst_mm is on swapoff's mmlist. */ ++ if (unlikely(list_empty(&dst_mm->mmlist))) { ++ spin_lock(&mmlist_lock); ++ if (list_empty(&dst_mm->mmlist)) ++ list_add(&dst_mm->mmlist, ++ &src_mm->mmlist); ++ spin_unlock(&mmlist_lock); ++ } + rss[MM_SWAPENTS]++; +- else if (is_migration_entry(entry)) { ++ } else if (is_migration_entry(entry)) { + page = migration_entry_to_page(entry); + + if (PageAnon(page)) diff --git a/queue-3.14/mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch b/queue-3.14/mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch new file mode 100644 index 00000000000..f6f4bff794e --- /dev/null +++ b/queue-3.14/mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch @@ -0,0 +1,50 @@ +From fb993fa1a2f669215fa03a09eed7848f2663e336 Mon Sep 17 00:00:00 2001 +From: Weijie Yang +Date: Tue, 2 Dec 2014 15:59:25 -0800 +Subject: mm: frontswap: invalidate expired data on a dup-store failure + +From: Weijie Yang + +commit fb993fa1a2f669215fa03a09eed7848f2663e336 upstream. + +If a frontswap dup-store failed, it should invalidate the expired page +in the backend, or it could trigger some data corruption issue. +Such as: + 1. use zswap as the frontswap backend with writeback feature + 2. store a swap page(version_1) to entry A, success + 3. dup-store a newer page(version_2) to the same entry A, fail + 4. use __swap_writepage() write version_2 page to swapfile, success + 5. zswap do shrink, writeback version_1 page to swapfile + 6. version_2 page is overwrited by version_1, data corrupt. + +This patch fixes this issue by invalidating expired data immediately +when meet a dup-store failure. + +Signed-off-by: Weijie Yang +Cc: Konrad Rzeszutek Wilk +Cc: Seth Jennings +Cc: Dan Streetman +Cc: Minchan Kim +Cc: Bob Liu +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/frontswap.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/mm/frontswap.c ++++ b/mm/frontswap.c +@@ -244,8 +244,10 @@ int __frontswap_store(struct page *page) + the (older) page from frontswap + */ + inc_frontswap_failed_stores(); +- if (dup) ++ if (dup) { + __frontswap_clear(sis, offset); ++ frontswap_ops->invalidate_page(type, offset); ++ } + } + if (frontswap_writethrough_enabled) + /* report failure so swap also writes to swap device */ diff --git a/queue-3.14/mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch b/queue-3.14/mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch new file mode 100644 index 00000000000..6cb88d78a3c --- /dev/null +++ b/queue-3.14/mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch @@ -0,0 +1,51 @@ +From 91b57191cfd152c02ded0745250167d0263084f8 Mon Sep 17 00:00:00 2001 +From: Andrew Morton +Date: Tue, 2 Dec 2014 15:59:28 -0800 +Subject: mm/vmpressure.c: fix race in vmpressure_work_fn() + +From: Andrew Morton + +commit 91b57191cfd152c02ded0745250167d0263084f8 upstream. + +In some android devices, there will be a "divide by zero" exception. +vmpr->scanned could be zero before spin_lock(&vmpr->sr_lock). + +Addresses https://bugzilla.kernel.org/show_bug.cgi?id=88051 + +[akpm@linux-foundation.org: neaten] +Reported-by: ji_ang +Cc: Anton Vorontsov +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmpressure.c | 8 +++++--- + 1 file changed, 5 insertions(+), 3 deletions(-) + +--- a/mm/vmpressure.c ++++ b/mm/vmpressure.c +@@ -165,6 +165,7 @@ static void vmpressure_work_fn(struct wo + unsigned long scanned; + unsigned long reclaimed; + ++ spin_lock(&vmpr->sr_lock); + /* + * Several contexts might be calling vmpressure(), so it is + * possible that the work was rescheduled again before the old +@@ -173,11 +174,12 @@ static void vmpressure_work_fn(struct wo + * here. No need for any locks here since we don't care if + * vmpr->reclaimed is in sync. + */ +- if (!vmpr->scanned) ++ scanned = vmpr->scanned; ++ if (!scanned) { ++ spin_unlock(&vmpr->sr_lock); + return; ++ } + +- spin_lock(&vmpr->sr_lock); +- scanned = vmpr->scanned; + reclaimed = vmpr->reclaimed; + vmpr->scanned = 0; + vmpr->reclaimed = 0; diff --git a/queue-3.14/series b/queue-3.14/series index 7f6bc4f0479..9b790987870 100644 --- a/queue-3.14/series +++ b/queue-3.14/series @@ -9,3 +9,6 @@ i2c-davinci-generate-stp-always-when-nack-is-received.patch drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch drm-i915-more-cautious-with-pch-fifo-underruns.patch drm-i915-unlock-panel-even-when-lvds-is-disabled.patch +x86-use-objdump-instead-of-plain-objdump.patch +media-smiapp-only-some-selection-targets-are-settable.patch +usb-xhci-reset-a-halted-endpoint-immediately-when-we-encounter-a-stall.patch diff --git a/queue-3.14/usb-xhci-reset-a-halted-endpoint-immediately-when-we-encounter-a-stall.patch b/queue-3.14/usb-xhci-reset-a-halted-endpoint-immediately-when-we-encounter-a-stall.patch new file mode 100644 index 00000000000..bfa2541a512 --- /dev/null +++ b/queue-3.14/usb-xhci-reset-a-halted-endpoint-immediately-when-we-encounter-a-stall.patch @@ -0,0 +1,176 @@ +From 8e71a322fdb127814bcba423a512914ca5bc6cf5 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Tue, 18 Nov 2014 11:27:12 +0200 +Subject: USB: xhci: Reset a halted endpoint immediately when we encounter a stall. + +From: Mathias Nyman + +commit 8e71a322fdb127814bcba423a512914ca5bc6cf5 upstream. + +If a device is halted and reuturns a STALL, then the halted endpoint +needs to be cleared both on the host and device side. The host +side halt is cleared by issueing a xhci reset endpoint command. The device side +is cleared with a ClearFeature(ENDPOINT_HALT) request, which should +be issued by the device driver if a URB reruen -EPIPE. + +Previously we cleared the host side halt after the device side was cleared. +To make sure the host side halt is cleared in time we want to issue the +reset endpoint command immedialtely when a STALL status is encountered. + +Otherwise we end up not following the specs and not returning -EPIPE +several times in a row when trying to transfer data to a halted endpoint. + +Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.) +Tested-by: Felipe Balbi +Signed-off-by: Mathias Nyman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci-ring.c | 40 +++++++--------------------- + drivers/usb/host/xhci.c | 60 ++++++++++--------------------------------- + 2 files changed, 25 insertions(+), 75 deletions(-) + +--- a/drivers/usb/host/xhci-ring.c ++++ b/drivers/usb/host/xhci-ring.c +@@ -1998,22 +1998,13 @@ static int finish_td(struct xhci_hcd *xh + ep->stopped_td = td; + return 0; + } else { +- if (trb_comp_code == COMP_STALL) { +- /* The transfer is completed from the driver's +- * perspective, but we need to issue a set dequeue +- * command for this stalled endpoint to move the dequeue +- * pointer past the TD. We can't do that here because +- * the halt condition must be cleared first. Let the +- * USB class driver clear the stall later. +- */ +- ep->stopped_td = td; +- ep->stopped_stream = ep_ring->stream_id; +- } else if (xhci_requires_manual_halt_cleanup(xhci, +- ep_ctx, trb_comp_code)) { +- /* Other types of errors halt the endpoint, but the +- * class driver doesn't call usb_reset_endpoint() unless +- * the error is -EPIPE. Clear the halted status in the +- * xHCI hardware manually. ++ if (trb_comp_code == COMP_STALL || ++ xhci_requires_manual_halt_cleanup(xhci, ep_ctx, ++ trb_comp_code)) { ++ /* Issue a reset endpoint command to clear the host side ++ * halt, followed by a set dequeue command to move the ++ * dequeue pointer past the TD. ++ * The class driver clears the device side halt later. + */ + xhci_cleanup_halted_endpoint(xhci, + slot_id, ep_index, ep_ring->stream_id, +@@ -2133,9 +2124,7 @@ static int process_ctrl_td(struct xhci_h + else + td->urb->actual_length = 0; + +- xhci_cleanup_halted_endpoint(xhci, +- slot_id, ep_index, 0, td, event_trb); +- return finish_td(xhci, td, event_trb, event, ep, status, true); ++ return finish_td(xhci, td, event_trb, event, ep, status, false); + } + /* + * Did we transfer any data, despite the errors that might have +@@ -2689,17 +2678,8 @@ cleanup: + if (ret) { + urb = td->urb; + urb_priv = urb->hcpriv; +- /* Leave the TD around for the reset endpoint function +- * to use(but only if it's not a control endpoint, +- * since we already queued the Set TR dequeue pointer +- * command for stalled control endpoints). +- */ +- if (usb_endpoint_xfer_control(&urb->ep->desc) || +- (trb_comp_code != COMP_STALL && +- trb_comp_code != COMP_BABBLE)) +- xhci_urb_free_priv(xhci, urb_priv); +- else +- kfree(urb_priv); ++ ++ xhci_urb_free_priv(xhci, urb_priv); + + usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb->dev->bus), urb); + if ((urb->actual_length != urb->transfer_buffer_length && +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -2925,63 +2925,33 @@ void xhci_cleanup_stalled_ring(struct xh + } + } + +-/* Deal with stalled endpoints. The core should have sent the control message +- * to clear the halt condition. However, we need to make the xHCI hardware +- * reset its sequence number, since a device will expect a sequence number of +- * zero after the halt condition is cleared. ++/* Called when clearing halted device. The core should have sent the control ++ * message to clear the device halt condition. The host side of the halt should ++ * already be cleared with a reset endpoint command issued when the STALL tx ++ * event was received. ++ * + * Context: in_interrupt + */ ++ + void xhci_endpoint_reset(struct usb_hcd *hcd, + struct usb_host_endpoint *ep) + { + struct xhci_hcd *xhci; +- struct usb_device *udev; +- unsigned int ep_index; +- unsigned long flags; +- int ret; +- struct xhci_virt_ep *virt_ep; + + xhci = hcd_to_xhci(hcd); +- udev = (struct usb_device *) ep->hcpriv; +- /* Called with a root hub endpoint (or an endpoint that wasn't added +- * with xhci_add_endpoint() +- */ +- if (!ep->hcpriv) +- return; +- ep_index = xhci_get_endpoint_index(&ep->desc); +- virt_ep = &xhci->devs[udev->slot_id]->eps[ep_index]; +- if (!virt_ep->stopped_td) { +- xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep, +- "Endpoint 0x%x not halted, refusing to reset.", +- ep->desc.bEndpointAddress); +- return; +- } +- if (usb_endpoint_xfer_control(&ep->desc)) { +- xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep, +- "Control endpoint stall already handled."); +- return; +- } + +- xhci_dbg_trace(xhci, trace_xhci_dbg_reset_ep, +- "Queueing reset endpoint command"); +- spin_lock_irqsave(&xhci->lock, flags); +- ret = xhci_queue_reset_ep(xhci, udev->slot_id, ep_index); + /* +- * Can't change the ring dequeue pointer until it's transitioned to the +- * stopped state, which is only upon a successful reset endpoint +- * command. Better hope that last command worked! ++ * We might need to implement the config ep cmd in xhci 4.8.1 note: ++ * The Reset Endpoint Command may only be issued to endpoints in the ++ * Halted state. If software wishes reset the Data Toggle or Sequence ++ * Number of an endpoint that isn't in the Halted state, then software ++ * may issue a Configure Endpoint Command with the Drop and Add bits set ++ * for the target endpoint. that is in the Stopped state. + */ +- if (!ret) { +- xhci_cleanup_stalled_ring(xhci, udev, ep_index); +- kfree(virt_ep->stopped_td); +- xhci_ring_cmd_db(xhci); +- } +- virt_ep->stopped_td = NULL; +- virt_ep->stopped_stream = 0; +- spin_unlock_irqrestore(&xhci->lock, flags); + +- if (ret) +- xhci_warn(xhci, "FIXME allocate a new ring segment\n"); ++ /* For now just print debug to follow the situation */ ++ xhci_dbg(xhci, "Endpoint 0x%x ep reset callback called\n", ++ ep->desc.bEndpointAddress); + } + + static int xhci_check_streams_endpoint(struct xhci_hcd *xhci, diff --git a/queue-3.14/x86-use-objdump-instead-of-plain-objdump.patch b/queue-3.14/x86-use-objdump-instead-of-plain-objdump.patch new file mode 100644 index 00000000000..22fa1952828 --- /dev/null +++ b/queue-3.14/x86-use-objdump-instead-of-plain-objdump.patch @@ -0,0 +1,45 @@ +From e2e68ae688b0a3766cd75aedf4ed4e39be402009 Mon Sep 17 00:00:00 2001 +From: Chris Clayton +Date: Sat, 22 Nov 2014 09:51:10 +0000 +Subject: x86: Use $(OBJDUMP) instead of plain objdump + +From: Chris Clayton + +commit e2e68ae688b0a3766cd75aedf4ed4e39be402009 upstream. + +commit e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd' +broke the cross compile of x86. It added a objdump invocation, which +invokes the host native objdump and ignores an active cross tool +chain. + +Use $(OBJDUMP) instead which takes the CROSS_COMPILE prefix into +account. + +[ tglx: Massage changelog and use $(OBJDUMP) ] + +Fixes: e6023367d779 'x86, kaslr: Prevent .bss from overlaping initrd' +Signed-off-by: Chris Clayton +Acked-by: Kees Cook +Acked-by: Borislav Petkov +Cc: Junjie Mao +Cc: Ingo Molnar +Cc: H. Peter Anvin +Link: http://lkml.kernel.org/r/54705C8E.1080400@googlemail.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/boot/compressed/Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/boot/compressed/Makefile ++++ b/arch/x86/boot/compressed/Makefile +@@ -75,7 +75,7 @@ suffix-$(CONFIG_KERNEL_XZ) := xz + suffix-$(CONFIG_KERNEL_LZO) := lzo + suffix-$(CONFIG_KERNEL_LZ4) := lz4 + +-RUN_SIZE = $(shell objdump -h vmlinux | \ ++RUN_SIZE = $(shell $(OBJDUMP) -h vmlinux | \ + perl $(srctree)/arch/x86/tools/calc_run_size.pl) + quiet_cmd_mkpiggy = MKPIGGY $@ + cmd_mkpiggy = $(obj)/mkpiggy $< $(RUN_SIZE) > $@ || ( rm -f $@ ; false ) diff --git a/queue-3.14/xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch b/queue-3.14/xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch new file mode 100644 index 00000000000..57c24bf707a --- /dev/null +++ b/queue-3.14/xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch @@ -0,0 +1,48 @@ +From 8d609725d4357f499e2103e46011308b32f53513 Mon Sep 17 00:00:00 2001 +From: Seth Forshee +Date: Tue, 25 Nov 2014 20:28:24 -0600 +Subject: xen-netfront: Remove BUGs on paged skb data which crosses a page boundary + +From: Seth Forshee + +commit 8d609725d4357f499e2103e46011308b32f53513 upstream. + +These BUGs can be erroneously triggered by frags which refer to +tail pages within a compound page. The data in these pages may +overrun the hardware page while still being contained within the +compound page, but since compound_order() evaluates to 0 for tail +pages the assertion fails. The code already iterates through +subsequent pages correctly in this scenario, so the BUGs are +unnecessary and can be removed. + +Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit") +Signed-off-by: Seth Forshee +Reviewed-by: David Vrabel +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/xen-netfront.c | 5 ----- + 1 file changed, 5 deletions(-) + +--- a/drivers/net/xen-netfront.c ++++ b/drivers/net/xen-netfront.c +@@ -469,9 +469,6 @@ static void xennet_make_frags(struct sk_ + len = skb_frag_size(frag); + offset = frag->page_offset; + +- /* Data must not cross a page boundary. */ +- BUG_ON(len + offset > PAGE_SIZE<> PAGE_SHIFT; + offset &= ~PAGE_MASK; +@@ -479,8 +476,6 @@ static void xennet_make_frags(struct sk_ + while (len > 0) { + unsigned long bytes; + +- BUG_ON(offset >= PAGE_SIZE); +- + bytes = PAGE_SIZE - offset; + if (bytes > len) + bytes = len;