--- /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
+@@ -1097,6 +1097,17 @@ bool 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 false;
+
+@@ -1280,17 +1291,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
+@@ -666,6 +666,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
+@@ -414,11 +414,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
+@@ -958,11 +958,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
+@@ -928,14 +928,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
+@@ -2139,7 +2139,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 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
+@@ -834,20 +834,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
+mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
+mm-fix-swapoff-hang-after-page-migration-and-fork.patch
+xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
+i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
+i2c-omap-fix-i207-errata-handling.patch
+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-unlock-panel-even-when-lvds-is-disabled.patch
+media-smiapp-only-some-selection-targets-are-settable.patch
--- /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
+@@ -459,9 +459,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;
+@@ -469,8 +466,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;
--- /dev/null
+mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
+mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch
+mm-fix-swapoff-hang-after-page-migration-and-fork.patch
+mm-fix-anon_vma_clone-error-treatment.patch
+xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
+i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
+i2c-omap-fix-i207-errata-handling.patch
+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
--- /dev/null
+mm-frontswap-invalidate-expired-data-on-a-dup-store-failure.patch
+mm-vmpressure.c-fix-race-in-vmpressure_work_fn.patch
+drivers-input-evdev.c-don-t-kfree-a-vmalloc-address.patch
+fat-fix-oops-on-corrupted-vfat-fs.patch
+mm-fix-swapoff-hang-after-page-migration-and-fork.patch
+mm-fix-anon_vma_clone-error-treatment.patch
+slab-fix-nodeid-bounds-check-for-non-contiguous-node-ids.patch
+xen-netfront-remove-bugs-on-paged-skb-data-which-crosses-a-page-boundary.patch
+drm-nouveau-gf116-remove-copy1-engine.patch
+nouveau-move-the-hotplug-ignore-to-correct-place.patch
+i2c-omap-fix-nack-and-arbitration-lost-irq-handling.patch
+i2c-omap-fix-i207-errata-handling.patch
+i2c-davinci-generate-stp-always-when-nack-is-received.patch
+i2c-cadence-set-the-hardware-time-out-register-to-maximum-value.patch
+drm-radeon-ignore-radeon_gem_gtt_wc-on-32-bit-x86.patch
+drm-radeon-kernel-panic-in-drm_calc_vbltimestamp_from_scanoutpos-with-3.18.0-rc6.patch
+of-fdt-memblock_reserve-memreserve-regions-in-the-case-of-partial-overlap.patch
+drm-i915-more-cautious-with-pch-fifo-underruns.patch
+drm-i915-unlock-panel-even-when-lvds-is-disabled.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
