--- /dev/null
+From b68362278af94e1171f5be9d4e44988601fb0439 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon, 24 Nov 2014 17:02:45 +0100
+Subject: drm/i915: More cautious with pch fifo underruns
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+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 <daniel.vetter@intel.com>
+Tested-by: lu hua <huax.lu@intel.com>
+Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
+
--- /dev/null
+From b0616c5306b342ceca07044dbc4f917d95c4f825 Mon Sep 17 00:00:00 2001
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+Date: Mon, 1 Dec 2014 17:56:54 +0100
+Subject: drm/i915: Unlock panel even when LVDS is disabled
+
+From: Daniel Vetter <daniel.vetter@ffwll.ch>
+
+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 <chris@chris-wilson.co.uk>
+Date: Thu Oct 18 21:07:01 2012 +0100
+
+ drm/i915: Add no-lvds quirk for Supermicro X7SPA-H
+
+Reported-by: Alexey Orishko <alexey.orishko@gmail.com>
+Cc: Alexey Orishko <alexey.orishko@gmail.com>
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Francois Tigeot <ftigeot@wolfpond.org>
+Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
+Tested-by: Alexey Orishko <alexey.orishko@gmail.com>
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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");
--- /dev/null
+From f5475cc43c899e33098d4db44b7c5e710f16589d Mon Sep 17 00:00:00 2001
+From: Petr Mladek <pmladek@suse.cz>
+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 <pmladek@suse.cz>
+
+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: [<ffffffff8150423b>] 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:[<ffffffff8150423b>] [<ffffffff8150423b>] 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:
+ [<ffffffff8151b51d>] ? drm_vma_offset_remove+0x1d/0x110
+ [<ffffffff8152dc98>] radeon_get_vblank_timestamp_kms+0x38/0x60
+ [<ffffffff8152076a>] ? ttm_bo_release_list+0xba/0x180
+ [<ffffffff81503751>] drm_get_last_vbltimestamp+0x41/0x70
+ [<ffffffff81503933>] vblank_disable_and_save+0x73/0x1d0
+ [<ffffffff81106b2f>] ? try_to_del_timer_sync+0x4f/0x70
+ [<ffffffff81505245>] drm_vblank_cleanup+0x65/0xa0
+ [<ffffffff815604fa>] radeon_irq_kms_fini+0x1a/0x70
+ [<ffffffff8156c07e>] r100_init+0x26e/0x410
+ [<ffffffff8152ae3e>] radeon_device_init+0x7ae/0xb50
+ [<ffffffff8152d57f>] radeon_driver_load_kms+0x8f/0x210
+ [<ffffffff81506965>] drm_dev_register+0xb5/0x110
+ [<ffffffff8150998f>] drm_get_pci_dev+0x8f/0x200
+ [<ffffffff815291cd>] radeon_pci_probe+0xad/0xe0
+ [<ffffffff8141a365>] local_pci_probe+0x45/0xa0
+ [<ffffffff8141b741>] pci_device_probe+0xd1/0x130
+ [<ffffffff81633dad>] driver_probe_device+0x12d/0x3e0
+ [<ffffffff8163413b>] __driver_attach+0x9b/0xa0
+ [<ffffffff816340a0>] ? __device_attach+0x40/0x40
+ [<ffffffff81631cd3>] bus_for_each_dev+0x63/0xa0
+ [<ffffffff8163378e>] driver_attach+0x1e/0x20
+ [<ffffffff81633390>] bus_add_driver+0x180/0x240
+ [<ffffffff81634914>] driver_register+0x64/0xf0
+ [<ffffffff81419cac>] __pci_register_driver+0x4c/0x50
+ [<ffffffff81509bf5>] drm_pci_init+0xf5/0x120
+ [<ffffffff821dc871>] ? ttm_init+0x6a/0x6a
+ [<ffffffff821dc908>] radeon_init+0x97/0xb5
+ [<ffffffff810002fc>] do_one_initcall+0xbc/0x1f0
+ [<ffffffff810e3278>] ? __wake_up+0x48/0x60
+ [<ffffffff8218e256>] kernel_init_freeable+0x18a/0x215
+ [<ffffffff8218d983>] ? initcall_blacklist+0xc0/0xc0
+ [<ffffffff818a78f0>] ? rest_init+0x80/0x80
+ [<ffffffff818a78fe>] kernel_init+0xe/0xf0
+ [<ffffffff818c0c3c>] ret_from_fork+0x7c/0xb0
+ [<ffffffff818a78f0>] ? 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 [<ffffffff8150423b>] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
+ RSP <ffff880234da7918>
+ 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 <deller@gmx.de>
+Signed-off-by: Petr Mladek <pmladek@suse.cz>
+Tested-by: Petr Mladek <pmladek@suse.cz>
+Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From 9ea359f7314132cbcb5a502d2d8ef095be1f45e4 Mon Sep 17 00:00:00 2001
+From: Grygorii Strashko <grygorii.strashko@ti.com>
+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 <grygorii.strashko@ti.com>
+
+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 <u.kleine-koenig@pengutronix.de>
+Reported-by: Hein Tibosch <hein_tibosch@yahoo.es>
+Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From ccfc866356674cb3a61829d239c685af6e85f197 Mon Sep 17 00:00:00 2001
+From: Alexander Kochetkov <al.kochet@gmail.com>
+Date: Fri, 21 Nov 2014 04:16:51 +0400
+Subject: i2c: omap: fix i207 errata handling
+
+From: Alexander Kochetkov <al.kochet@gmail.com>
+
+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 <al.kochet@gmail.com>
+Fixes: 6d9939f651419a63e09110 i2c: omap: split out [XR]DR and [XR]RDY
+Tested-by: Felipe Balbi <balbi@ti.com>
+Reviewed-by: Felipe Balbi <balbi@ti.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From 27caca9d2e01c92b26d0690f065aad093fea01c7 Mon Sep 17 00:00:00 2001
+From: Alexander Kochetkov <al.kochet@gmail.com>
+Date: Tue, 18 Nov 2014 21:00:58 +0400
+Subject: i2c: omap: fix NACK and Arbitration Lost irq handling
+
+From: Alexander Kochetkov <al.kochet@gmail.com>
+
+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 <al.kochet@gmail.com>
+Fixes: 1d7afc9 i2c: omap: ack IRQ in parts
+Acked-by: Felipe Balbi <balbi@ti.com>
+Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
+
+ /*
--- /dev/null
+From b31eb901c4e5eeef4c83c43dfbc7fe0d4348cb21 Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@iki.fi>
+Date: Thu, 6 Nov 2014 17:49:45 -0300
+Subject: media: smiapp: Only some selection targets are settable
+
+From: Sakari Ailus <sakari.ailus@iki.fi>
+
+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 <sakari.ailus@iki.fi>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From c4ea95d7cd08d9ffd7fa75e6c5e0332d596dd11e Mon Sep 17 00:00:00 2001
+From: Daniel Forrest <dan.forrest@ssec.wisc.edu>
+Date: Tue, 2 Dec 2014 15:59:42 -0800
+Subject: mm: fix anon_vma_clone() error treatment
+
+From: Daniel Forrest <dan.forrest@ssec.wisc.edu>
+
+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 <dan.forrest@ssec.wisc.edu>
+Reviewed-by: Michal Hocko <mhocko@suse.cz>
+Cc: Konstantin Khlebnikov <koct9i@gmail.com>
+Cc: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Rik van Riel <riel@redhat.com>
+Cc: Tim Hartrick <tim@edgecast.com>
+Cc: Hugh Dickins <hughd@google.com>
+Cc: Michel Lespinasse <walken@google.com>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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();
--- /dev/null
+From 2022b4d18a491a578218ce7a4eca8666db895a73 Mon Sep 17 00:00:00 2001
+From: Hugh Dickins <hughd@google.com>
+Date: Tue, 2 Dec 2014 15:59:39 -0800
+Subject: mm: fix swapoff hang after page migration and fork
+
+From: Hugh Dickins <hughd@google.com>
+
+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 <hughd@google.com>
+Cc: Kelley Nielsen <kelleynnn@gmail.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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))
--- /dev/null
+From fb993fa1a2f669215fa03a09eed7848f2663e336 Mon Sep 17 00:00:00 2001
+From: Weijie Yang <weijie.yang@samsung.com>
+Date: Tue, 2 Dec 2014 15:59:25 -0800
+Subject: mm: frontswap: invalidate expired data on a dup-store failure
+
+From: Weijie Yang <weijie.yang@samsung.com>
+
+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 <weijie.yang@samsung.com>
+Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: Seth Jennings <sjennings@variantweb.net>
+Cc: Dan Streetman <ddstreet@ieee.org>
+Cc: Minchan Kim <minchan@kernel.org>
+Cc: Bob Liu <bob.liu@oracle.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 */
--- /dev/null
+From 91b57191cfd152c02ded0745250167d0263084f8 Mon Sep 17 00:00:00 2001
+From: Andrew Morton <akpm@linux-foundation.org>
+Date: Tue, 2 Dec 2014 15:59:28 -0800
+Subject: mm/vmpressure.c: fix race in vmpressure_work_fn()
+
+From: Andrew Morton <akpm@linux-foundation.org>
+
+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 <ji_ang@163.com>
+Cc: Anton Vorontsov <anton.vorontsov@linaro.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From 8e71a322fdb127814bcba423a512914ca5bc6cf5 Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+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 <mathias.nyman@linux.intel.com>
+
+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 <balbi@ti.com>
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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,
--- /dev/null
+From e2e68ae688b0a3766cd75aedf4ed4e39be402009 Mon Sep 17 00:00:00 2001
+From: Chris Clayton <chris2553@googlemail.com>
+Date: Sat, 22 Nov 2014 09:51:10 +0000
+Subject: x86: Use $(OBJDUMP) instead of plain objdump
+
+From: Chris Clayton <chris2553@googlemail.com>
+
+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 <chris2553@googlemail.com>
+Acked-by: Kees Cook <keescook@chromium.org>
+Acked-by: Borislav Petkov <bp@suse.de>
+Cc: Junjie Mao <eternal.n08@gmail.com>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: H. Peter Anvin <hpa@linux.intel.com>
+Link: http://lkml.kernel.org/r/54705C8E.1080400@googlemail.com
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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 )
--- /dev/null
+From 8d609725d4357f499e2103e46011308b32f53513 Mon Sep 17 00:00:00 2001
+From: Seth Forshee <seth.forshee@canonical.com>
+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 <seth.forshee@canonical.com>
+
+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 <seth.forshee@canonical.com>
+Reviewed-by: David Vrabel <david.vrabel@citrix.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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<<compound_order(page));
+-
+ /* Skip unused frames from start of page */
+ page += offset >> 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
