--- /dev/null
+From b8839b8c55f3fdd60dc36abcda7e0266aff7985c Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Wed, 8 Oct 2014 18:26:13 -0400
+Subject: block: fix alignment_offset math that assumes io_min is a power-of-2
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit b8839b8c55f3fdd60dc36abcda7e0266aff7985c upstream.
+
+The math in both blk_stack_limits() and queue_limit_alignment_offset()
+assume that a block device's io_min (aka minimum_io_size) is always a
+power-of-2. Fix the math such that it works for non-power-of-2 io_min.
+
+This issue (of alignment_offset != 0) became apparent when testing
+dm-thinp with a thinp blocksize that matches a RAID6 stripesize of
+1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data
+block size") unlocked the potential for alignment_offset != 0 due to
+the dm-thin-pool's io_min possibly being a non-power-of-2.
+
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-settings.c | 4 ++--
+ include/linux/blkdev.h | 5 ++---
+ 2 files changed, 4 insertions(+), 5 deletions(-)
+
+--- a/block/blk-settings.c
++++ b/block/blk-settings.c
+@@ -553,7 +553,7 @@ int blk_stack_limits(struct queue_limits
+ bottom = max(b->physical_block_size, b->io_min) + alignment;
+
+ /* Verify that top and bottom intervals line up */
+- if (max(top, bottom) & (min(top, bottom) - 1)) {
++ if (max(top, bottom) % min(top, bottom)) {
+ t->misaligned = 1;
+ ret = -1;
+ }
+@@ -594,7 +594,7 @@ int blk_stack_limits(struct queue_limits
+
+ /* Find lowest common alignment_offset */
+ t->alignment_offset = lcm(t->alignment_offset, alignment)
+- & (max(t->physical_block_size, t->io_min) - 1);
++ % max(t->physical_block_size, t->io_min);
+
+ /* Verify that new alignment_offset is on a logical block boundary */
+ if (t->alignment_offset & (t->logical_block_size - 1)) {
+--- a/include/linux/blkdev.h
++++ b/include/linux/blkdev.h
+@@ -1187,10 +1187,9 @@ static inline int queue_alignment_offset
+ static inline int queue_limit_alignment_offset(struct queue_limits *lim, sector_t sector)
+ {
+ unsigned int granularity = max(lim->physical_block_size, lim->io_min);
+- unsigned int alignment = (sector << 9) & (granularity - 1);
++ unsigned int alignment = sector_div(sector, granularity >> 9) << 9;
+
+- return (granularity + lim->alignment_offset - alignment)
+- & (granularity - 1);
++ return (granularity + lim->alignment_offset - alignment) % granularity;
+ }
+
+ static inline int bdev_alignment_offset(struct block_device *bdev)
--- /dev/null
+From eb76faf53b1ff7a77ce3f78cc98ad392ac70c2a0 Mon Sep 17 00:00:00 2001
+From: Joe Thornber <ejt@redhat.com>
+Date: Tue, 30 Sep 2014 09:32:46 +0100
+Subject: dm bufio: update last_accessed when relinking a buffer
+
+From: Joe Thornber <ejt@redhat.com>
+
+commit eb76faf53b1ff7a77ce3f78cc98ad392ac70c2a0 upstream.
+
+The 'last_accessed' member of the dm_buffer structure was only set when
+the the buffer was created. This led to each buffer being discarded
+after dm_bufio_max_age time even if it was used recently. In practice
+this resulted in all thinp metadata being evicted soon after being read
+-- this is particularly problematic for metadata intensive workloads
+like multithreaded small random IO.
+
+'last_accessed' is now updated each time the buffer is moved to the head
+of the LRU list, so the buffer is now properly discarded if it was not
+used in dm_bufio_max_age time.
+
+Signed-off-by: Joe Thornber <ejt@redhat.com>
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-bufio.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/dm-bufio.c
++++ b/drivers/md/dm-bufio.c
+@@ -462,6 +462,7 @@ static void __relink_lru(struct dm_buffe
+ c->n_buffers[dirty]++;
+ b->list_mode = dirty;
+ list_move(&b->lru_list, &c->lru[dirty]);
++ b->last_accessed = jiffies;
+ }
+
+ /*----------------------------------------------------------------
--- /dev/null
+From 56ec16cb1e1ce46354de8511eef962a417c32c92 Mon Sep 17 00:00:00 2001
+From: Alexey Khoroshilov <khoroshilov@ispras.ru>
+Date: Wed, 1 Oct 2014 22:58:35 +0200
+Subject: dm log userspace: fix memory leak in dm_ulog_tfr_init failure path
+
+From: Alexey Khoroshilov <khoroshilov@ispras.ru>
+
+commit 56ec16cb1e1ce46354de8511eef962a417c32c92 upstream.
+
+If cn_add_callback() fails in dm_ulog_tfr_init(), it does not
+deallocate prealloced memory but calls cn_del_callback().
+
+Found by Linux Driver Verification project (linuxtesting.org).
+
+Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
+Reviewed-by: Jonathan Brassow <jbrassow@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-log-userspace-transfer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/md/dm-log-userspace-transfer.c
++++ b/drivers/md/dm-log-userspace-transfer.c
+@@ -272,7 +272,7 @@ int dm_ulog_tfr_init(void)
+
+ r = cn_add_callback(&ulog_cn_id, "dmlogusr", cn_ulog_callback);
+ if (r) {
+- cn_del_callback(&ulog_cn_id);
++ kfree(prealloced_cn_msg);
+ return r;
+ }
+
--- /dev/null
+From 82cfb90bc99d7b7e0ec62d0505b9d4f06805d5db Mon Sep 17 00:00:00 2001
+From: Lai Jiangshan <laijs@cn.fujitsu.com>
+Date: Thu, 18 Sep 2014 16:49:41 +0200
+Subject: drbd: compute the end before rb_insert_augmented()
+
+From: Lai Jiangshan <laijs@cn.fujitsu.com>
+
+commit 82cfb90bc99d7b7e0ec62d0505b9d4f06805d5db upstream.
+
+Commit 98683650 "Merge branch 'drbd-8.4_ed6' into
+for-3.8-drivers-drbd-8.4_ed6" switches to the new augment API, but the
+new API requires that the tree is augmented before rb_insert_augmented()
+is called, which is missing.
+
+So we add the augment-code to drbd_insert_interval() when it travels the
+tree up to down before rb_insert_augmented(). See the example in
+include/linux/interval_tree_generic.h or Documentation/rbtree.txt.
+
+drbd_insert_interval() may cancel the insertion when traveling, in this
+case, the just added augment-code does nothing before cancel since the
+@this node is already in the subtrees in this case.
+
+CC: Michel Lespinasse <walken@google.com>
+Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
+Signed-off-by: Andreas Gruenbacher <agruen@linbit.com>
+Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
+Signed-off-by: Jens Axboe <axboe@fb.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/drbd/drbd_interval.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/block/drbd/drbd_interval.c
++++ b/drivers/block/drbd/drbd_interval.c
+@@ -79,6 +79,7 @@ bool
+ drbd_insert_interval(struct rb_root *root, struct drbd_interval *this)
+ {
+ struct rb_node **new = &root->rb_node, *parent = NULL;
++ sector_t this_end = this->sector + (this->size >> 9);
+
+ BUG_ON(!IS_ALIGNED(this->size, 512));
+
+@@ -87,6 +88,8 @@ drbd_insert_interval(struct rb_root *roo
+ rb_entry(*new, struct drbd_interval, rb);
+
+ parent = *new;
++ if (here->end < this_end)
++ here->end = this_end;
+ if (this->sector < here->sector)
+ new = &(*new)->rb_left;
+ else if (this->sector > here->sector)
+@@ -99,6 +102,7 @@ drbd_insert_interval(struct rb_root *roo
+ return false;
+ }
+
++ this->end = this_end;
+ rb_link_node(&this->rb, parent, new);
+ rb_insert_augmented(&this->rb, root, &augment_callbacks);
+ return true;
--- /dev/null
+From 1e99cfa8de0f0879091e33cd65fd60418d006ad9 Mon Sep 17 00:00:00 2001
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Date: Tue, 7 Oct 2014 19:04:58 +1100
+Subject: drm/ast: Fix HW cursor image
+
+From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+
+commit 1e99cfa8de0f0879091e33cd65fd60418d006ad9 upstream.
+
+The translation from the X driver to the KMS one typo'ed a couple
+of array indices, causing the HW cursor to look weird (blocky with
+leaking edge colors). This fixes it.
+
+Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/ast/ast_mode.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/ast/ast_mode.c
++++ b/drivers/gpu/drm/ast/ast_mode.c
+@@ -1012,8 +1012,8 @@ static u32 copy_cursor_image(u8 *src, u8
+ srcdata32[1].ul = *((u32 *)(srcxor + 4)) & 0xf0f0f0f0;
+ data32.b[0] = srcdata32[0].b[1] | (srcdata32[0].b[0] >> 4);
+ data32.b[1] = srcdata32[0].b[3] | (srcdata32[0].b[2] >> 4);
+- data32.b[2] = srcdata32[0].b[1] | (srcdata32[1].b[0] >> 4);
+- data32.b[3] = srcdata32[0].b[3] | (srcdata32[1].b[2] >> 4);
++ data32.b[2] = srcdata32[1].b[1] | (srcdata32[1].b[0] >> 4);
++ data32.b[3] = srcdata32[1].b[3] | (srcdata32[1].b[2] >> 4);
+
+ writel(data32.ul, dstxor);
+ csum += data32.ul;
--- /dev/null
+From 595d373f1e9c9ce0fc946457fdb488e8a58972cd Mon Sep 17 00:00:00 2001
+From: Ben Skeggs <bskeggs@redhat.com>
+Date: Mon, 8 Sep 2014 10:33:32 +1000
+Subject: drm/nouveau/bios: memset dcb struct to zero before parsing
+
+From: Ben Skeggs <bskeggs@redhat.com>
+
+commit 595d373f1e9c9ce0fc946457fdb488e8a58972cd upstream.
+
+Fixes type/mask calculation being based on uninitialised data for VGA
+outputs.
+
+Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c
++++ b/drivers/gpu/drm/nouveau/core/subdev/bios/dcb.c
+@@ -124,6 +124,7 @@ dcb_outp_parse(struct nouveau_bios *bios
+ struct dcb_output *outp)
+ {
+ u16 dcb = dcb_outp(bios, idx, ver, len);
++ memset(outp, 0x00, sizeof(*outp));
+ if (dcb) {
+ if (*ver >= 0x20) {
+ u32 conn = nv_ro32(bios, dcb + 0x00);
--- /dev/null
+From b478e336b3e75505707a11e78ef8b964ef0a03af Mon Sep 17 00:00:00 2001
+From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
+Date: Tue, 2 Sep 2014 09:51:15 -0300
+Subject: drm/tilcdc: Fix the error path in tilcdc_load()
+
+From: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
+
+commit b478e336b3e75505707a11e78ef8b964ef0a03af upstream.
+
+The current error path calls tilcdc_unload() in case of an error to release
+the resources. However, this is wrong because not all resources have been
+allocated by the time an error occurs in tilcdc_load().
+
+To fix it, this commit adds proper labels to bail out at the different
+stages in the load function, and release only the resources actually allocated.
+
+Tested-by: Darren Etheridge <detheridge@ti.com>
+Tested-by: Johannes Pointner <johannes.pointner@br-automation.com>
+Signed-off-by: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
+Signed-off-by: Dave Airlie <airlied@redhat.com>
+Fixes: 3a49012224ca ("drm/tilcdc: panel: fix leak when unloading the module")
+Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/tilcdc/tilcdc_drv.c | 60 ++++++++++++++++++++++++++++++------
+ 1 file changed, 50 insertions(+), 10 deletions(-)
+
+--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
++++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+@@ -78,6 +78,7 @@ static int modeset_init(struct drm_devic
+ if ((priv->num_encoders == 0) || (priv->num_connectors == 0)) {
+ /* oh nos! */
+ dev_err(dev->dev, "no encoders/connectors found\n");
++ drm_mode_config_cleanup(dev);
+ return -ENXIO;
+ }
+
+@@ -170,33 +171,37 @@ static int tilcdc_load(struct drm_device
+ dev->dev_private = priv;
+
+ priv->wq = alloc_ordered_workqueue("tilcdc", 0);
++ if (!priv->wq) {
++ ret = -ENOMEM;
++ goto fail_free_priv;
++ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(dev->dev, "failed to get memory resource\n");
+ ret = -EINVAL;
+- goto fail;
++ goto fail_free_wq;
+ }
+
+ priv->mmio = ioremap_nocache(res->start, resource_size(res));
+ if (!priv->mmio) {
+ dev_err(dev->dev, "failed to ioremap\n");
+ ret = -ENOMEM;
+- goto fail;
++ goto fail_free_wq;
+ }
+
+ priv->clk = clk_get(dev->dev, "fck");
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev->dev, "failed to get functional clock\n");
+ ret = -ENODEV;
+- goto fail;
++ goto fail_iounmap;
+ }
+
+ priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
+ if (IS_ERR(priv->clk)) {
+ dev_err(dev->dev, "failed to get display clock\n");
+ ret = -ENODEV;
+- goto fail;
++ goto fail_put_clk;
+ }
+
+ #ifdef CONFIG_CPU_FREQ
+@@ -206,7 +211,7 @@ static int tilcdc_load(struct drm_device
+ CPUFREQ_TRANSITION_NOTIFIER);
+ if (ret) {
+ dev_err(dev->dev, "failed to register cpufreq notifier\n");
+- goto fail;
++ goto fail_put_disp_clk;
+ }
+ #endif
+
+@@ -238,13 +243,13 @@ static int tilcdc_load(struct drm_device
+ ret = modeset_init(dev);
+ if (ret < 0) {
+ dev_err(dev->dev, "failed to initialize mode setting\n");
+- goto fail;
++ goto fail_cpufreq_unregister;
+ }
+
+ ret = drm_vblank_init(dev, 1);
+ if (ret < 0) {
+ dev_err(dev->dev, "failed to initialize vblank\n");
+- goto fail;
++ goto fail_mode_config_cleanup;
+ }
+
+ pm_runtime_get_sync(dev->dev);
+@@ -252,7 +257,7 @@ static int tilcdc_load(struct drm_device
+ pm_runtime_put_sync(dev->dev);
+ if (ret < 0) {
+ dev_err(dev->dev, "failed to install IRQ handler\n");
+- goto fail;
++ goto fail_vblank_cleanup;
+ }
+
+ platform_set_drvdata(pdev, dev);
+@@ -260,13 +265,48 @@ static int tilcdc_load(struct drm_device
+ priv->fbdev = drm_fbdev_cma_init(dev, 16,
+ dev->mode_config.num_crtc,
+ dev->mode_config.num_connector);
++ if (IS_ERR(priv->fbdev)) {
++ ret = PTR_ERR(priv->fbdev);
++ goto fail_irq_uninstall;
++ }
+
+ drm_kms_helper_poll_init(dev);
+
+ return 0;
+
+-fail:
+- tilcdc_unload(dev);
++fail_irq_uninstall:
++ pm_runtime_get_sync(dev->dev);
++ drm_irq_uninstall(dev);
++ pm_runtime_put_sync(dev->dev);
++
++fail_vblank_cleanup:
++ drm_vblank_cleanup(dev);
++
++fail_mode_config_cleanup:
++ drm_mode_config_cleanup(dev);
++
++fail_cpufreq_unregister:
++ pm_runtime_disable(dev->dev);
++#ifdef CONFIG_CPU_FREQ
++ cpufreq_unregister_notifier(&priv->freq_transition,
++ CPUFREQ_TRANSITION_NOTIFIER);
++fail_put_disp_clk:
++ clk_put(priv->disp_clk);
++#endif
++
++fail_put_clk:
++ clk_put(priv->clk);
++
++fail_iounmap:
++ iounmap(priv->mmio);
++
++fail_free_wq:
++ flush_workqueue(priv->wq);
++ destroy_workqueue(priv->wq);
++
++fail_free_priv:
++ dev->dev_private = NULL;
++ kfree(priv);
+ return ret;
+ }
+
--- /dev/null
+From f74a289b9480648a654e5afd8458c2263c03a1e1 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Tue, 16 Sep 2014 12:40:26 -0400
+Subject: framebuffer: fix border color
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream.
+
+The framebuffer code uses the current background color to fill the border
+when switching consoles, however, this results in inconsistent behavior.
+For example:
+- start Midnigh Commander
+- the border is black
+- switch to another console and switch back
+- the border is cyan
+- type something into the command line in mc
+- the border is cyan
+- switch to another console and switch back
+- the border is black
+- press F9 to go to menu
+- the border is black
+- switch to another console and switch back
+- the border is dark blue
+
+When switching to a console with Midnight Commander, the border is random
+color that was left selected by the slang subsystem.
+
+This patch fixes this inconsistency by always using black as the
+background color when switching consoles.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/console/bitblit.c | 3 +--
+ drivers/video/console/fbcon_ccw.c | 3 +--
+ drivers/video/console/fbcon_cw.c | 3 +--
+ drivers/video/console/fbcon_ud.c | 3 +--
+ 4 files changed, 4 insertions(+), 8 deletions(-)
+
+--- a/drivers/video/console/bitblit.c
++++ b/drivers/video/console/bitblit.c
+@@ -205,7 +205,6 @@ static void bit_putcs(struct vc_data *vc
+ static void bit_clear_margins(struct vc_data *vc, struct fb_info *info,
+ int bottom_only)
+ {
+- int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
+ unsigned int cw = vc->vc_font.width;
+ unsigned int ch = vc->vc_font.height;
+ unsigned int rw = info->var.xres - (vc->vc_cols*cw);
+@@ -214,7 +213,7 @@ static void bit_clear_margins(struct vc_
+ unsigned int bs = info->var.yres - bh;
+ struct fb_fillrect region;
+
+- region.color = attr_bgcol_ec(bgshift, vc, info);
++ region.color = 0;
+ region.rop = ROP_COPY;
+
+ if (rw && !bottom_only) {
+--- a/drivers/video/console/fbcon_ccw.c
++++ b/drivers/video/console/fbcon_ccw.c
+@@ -197,9 +197,8 @@ static void ccw_clear_margins(struct vc_
+ unsigned int bh = info->var.xres - (vc->vc_rows*ch);
+ unsigned int bs = vc->vc_rows*ch;
+ struct fb_fillrect region;
+- int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
+
+- region.color = attr_bgcol_ec(bgshift,vc,info);
++ region.color = 0;
+ region.rop = ROP_COPY;
+
+ if (rw && !bottom_only) {
+--- a/drivers/video/console/fbcon_cw.c
++++ b/drivers/video/console/fbcon_cw.c
+@@ -180,9 +180,8 @@ static void cw_clear_margins(struct vc_d
+ unsigned int bh = info->var.xres - (vc->vc_rows*ch);
+ unsigned int rs = info->var.yres - rw;
+ struct fb_fillrect region;
+- int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
+
+- region.color = attr_bgcol_ec(bgshift,vc,info);
++ region.color = 0;
+ region.rop = ROP_COPY;
+
+ if (rw && !bottom_only) {
+--- a/drivers/video/console/fbcon_ud.c
++++ b/drivers/video/console/fbcon_ud.c
+@@ -227,9 +227,8 @@ static void ud_clear_margins(struct vc_d
+ unsigned int rw = info->var.xres - (vc->vc_cols*cw);
+ unsigned int bh = info->var.yres - (vc->vc_rows*ch);
+ struct fb_fillrect region;
+- int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
+
+- region.color = attr_bgcol_ec(bgshift,vc,info);
++ region.color = 0;
+ region.rop = ROP_COPY;
+
+ if (rw && !bottom_only) {
--- /dev/null
+From 9ff84a17302aeb8913ff244ecc0d8f9d219fecb5 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Sat, 11 Oct 2014 11:27:37 -0700
+Subject: Input: i8042 - add noloop quirk for Asus X750LN
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 9ff84a17302aeb8913ff244ecc0d8f9d219fecb5 upstream.
+
+Without this the aux port does not get detected, and consequently the
+touchpad will not work.
+
+https://bugzilla.redhat.com/show_bug.cgi?id=1110011
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/serio/i8042-x86ia64io.h | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -101,6 +101,12 @@ static const struct dmi_system_id __init
+ },
+ {
+ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
++ DMI_MATCH(DMI_PRODUCT_NAME, "X750LN"),
++ },
++ },
++ {
++ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Compaq"),
+ DMI_MATCH(DMI_PRODUCT_NAME , "ProLiant"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "8500"),
--- /dev/null
+From 993b3a3f80a7842a48cd46c2b41e1b3ef6302468 Mon Sep 17 00:00:00 2001
+From: Hans de Goede <hdegoede@redhat.com>
+Date: Fri, 24 Oct 2014 14:55:24 -0700
+Subject: Input: i8042 - quirks for Fujitsu Lifebook A544 and Lifebook AH544
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+commit 993b3a3f80a7842a48cd46c2b41e1b3ef6302468 upstream.
+
+These models need i8042.notimeout, otherwise the touchpad will not work.
+
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=69731
+BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1111138
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/serio/i8042-x86ia64io.h | 16 ++++++++++++++++
+ 1 file changed, 16 insertions(+)
+
+--- a/drivers/input/serio/i8042-x86ia64io.h
++++ b/drivers/input/serio/i8042-x86ia64io.h
+@@ -615,6 +615,22 @@ static const struct dmi_system_id __init
+ },
+ },
+ {
++ /* Fujitsu A544 laptop */
++ /* https://bugzilla.redhat.com/show_bug.cgi?id=1111138 */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK A544"),
++ },
++ },
++ {
++ /* Fujitsu AH544 laptop */
++ /* https://bugzilla.kernel.org/show_bug.cgi?id=69731 */
++ .matches = {
++ DMI_MATCH(DMI_SYS_VENDOR, "FUJITSU"),
++ DMI_MATCH(DMI_PRODUCT_NAME, "LIFEBOOK AH544"),
++ },
++ },
++ {
+ /* Fujitsu U574 laptop */
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=69731 */
+ .matches = {
--- /dev/null
+From 5152970538a5e16c03bbcb9f1c780489a795ed40 Mon Sep 17 00:00:00 2001
+From: Chris Ball <chris@printf.net>
+Date: Thu, 4 Sep 2014 17:11:53 +0100
+Subject: mfd: rtsx_pcr: Fix MSI enable error handling
+
+From: Chris Ball <chris@printf.net>
+
+commit 5152970538a5e16c03bbcb9f1c780489a795ed40 upstream.
+
+pci_enable_msi() can return failure with both positive and negative
+integers -- it returns 0 for success -- but is only tested here for
+"if (ret < 0)". This causes us to try to use MSI on the RTS5249 SD
+reader in the Dell XPS 11 when enabling MSI failed, causing:
+
+[ 1.737110] rtsx_pci: probe of 0000:05:00.0 failed with error -110
+
+Reported-by: D. Jared Dominguez <Jared_Dominguez@Dell.com>
+Tested-by: D. Jared Dominguez <Jared_Dominguez@Dell.com>
+Signed-off-by: Chris Ball <chris@printf.net>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mfd/rtsx_pcr.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mfd/rtsx_pcr.c
++++ b/drivers/mfd/rtsx_pcr.c
+@@ -1137,7 +1137,7 @@ static int rtsx_pci_probe(struct pci_dev
+ pcr->msi_en = msi_en;
+ if (pcr->msi_en) {
+ ret = pci_enable_msi(pcidev);
+- if (ret < 0)
++ if (ret)
+ pcr->msi_en = false;
+ }
+
--- /dev/null
+From 0d0826019e529f21c84687521d03f60cd241ca7d Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Wed, 8 Oct 2014 10:42:27 -0700
+Subject: mnt: Prevent pivot_root from creating a loop in the mount tree
+
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+
+commit 0d0826019e529f21c84687521d03f60cd241ca7d upstream.
+
+Andy Lutomirski recently demonstrated that when chroot is used to set
+the root path below the path for the new ``root'' passed to pivot_root
+the pivot_root system call succeeds and leaks mounts.
+
+In examining the code I see that starting with a new root that is
+below the current root in the mount tree will result in a loop in the
+mount tree after the mounts are detached and then reattached to one
+another. Resulting in all kinds of ugliness including a leak of that
+mounts involved in the leak of the mount loop.
+
+Prevent this problem by ensuring that the new mount is reachable from
+the current root of the mount tree.
+
+[Added stable cc. Fixes CVE-2014-7970. --Andy]
+
+Reported-by: Andy Lutomirski <luto@amacapital.net>
+Reviewed-by: Andy Lutomirski <luto@amacapital.net>
+Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.org
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Andy Lutomirski <luto@amacapital.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/namespace.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/fs/namespace.c
++++ b/fs/namespace.c
+@@ -2696,6 +2696,9 @@ SYSCALL_DEFINE2(pivot_root, const char _
+ /* make sure we can reach put_old from new_root */
+ if (!is_path_reachable(old_mnt, old.dentry, &new))
+ goto out4;
++ /* make certain new is below the root */
++ if (!is_path_reachable(new_mnt, new.dentry, &root))
++ goto out4;
+ root_mp->m_count++; /* pin it so it won't go away */
+ br_write_lock(&vfsmount_lock);
+ detach_mnt(new_mnt, &parent_path);
--- /dev/null
+From d3051b489aa81ca9ba62af366149ef42b8dae97c Mon Sep 17 00:00:00 2001
+From: Prarit Bhargava <prarit@redhat.com>
+Date: Tue, 14 Oct 2014 02:51:39 +1030
+Subject: modules, lock around setting of MODULE_STATE_UNFORMED
+
+From: Prarit Bhargava <prarit@redhat.com>
+
+commit d3051b489aa81ca9ba62af366149ef42b8dae97c upstream.
+
+A panic was seen in the following sitation.
+
+There are two threads running on the system. The first thread is a system
+monitoring thread that is reading /proc/modules. The second thread is
+loading and unloading a module (in this example I'm using my simple
+dummy-module.ko). Note, in the "real world" this occurred with the qlogic
+driver module.
+
+When doing this, the following panic occurred:
+
+ ------------[ cut here ]------------
+ kernel BUG at kernel/module.c:3739!
+ invalid opcode: 0000 [#1] SMP
+ Modules linked in: binfmt_misc sg nfsv3 rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel lrw igb gf128mul glue_helper iTCO_wdt iTCO_vendor_support ablk_helper ptp sb_edac cryptd pps_core edac_core shpchp i2c_i801 pcspkr wmi lpc_ich ioatdma mfd_core dca ipmi_si nfsd ipmi_msghandler auth_rpcgss nfs_acl lockd sunrpc xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_common mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm isci drm libsas ahci libahci scsi_transport_sas libata i2c_core dm_mirror dm_region_hash dm_log dm_mod [last unloaded: dummy_module]
+ CPU: 37 PID: 186343 Comm: cat Tainted: GF O-------------- 3.10.0+ #7
+ Hardware name: Intel Corporation S2600CP/S2600CP, BIOS RMLSDP.86I.00.29.D696.1311111329 11/11/2013
+ task: ffff8807fd2d8000 ti: ffff88080fa7c000 task.ti: ffff88080fa7c000
+ RIP: 0010:[<ffffffff810d64c5>] [<ffffffff810d64c5>] module_flags+0xb5/0xc0
+ RSP: 0018:ffff88080fa7fe18 EFLAGS: 00010246
+ RAX: 0000000000000003 RBX: ffffffffa03b5200 RCX: 0000000000000000
+ RDX: 0000000000001000 RSI: ffff88080fa7fe38 RDI: ffffffffa03b5000
+ RBP: ffff88080fa7fe28 R08: 0000000000000010 R09: 0000000000000000
+ R10: 0000000000000000 R11: 000000000000000f R12: ffffffffa03b5000
+ R13: ffffffffa03b5008 R14: ffffffffa03b5200 R15: ffffffffa03b5000
+ FS: 00007f6ae57ef740(0000) GS:ffff88101e7a0000(0000) knlGS:0000000000000000
+ CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+ CR2: 0000000000404f70 CR3: 0000000ffed48000 CR4: 00000000001407e0
+ DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+ DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
+ Stack:
+ ffffffffa03b5200 ffff8810101e4800 ffff88080fa7fe70 ffffffff810d666c
+ ffff88081e807300 000000002e0f2fbf 0000000000000000 ffff88100f257b00
+ ffffffffa03b5008 ffff88080fa7ff48 ffff8810101e4800 ffff88080fa7fee0
+ Call Trace:
+ [<ffffffff810d666c>] m_show+0x19c/0x1e0
+ [<ffffffff811e4d7e>] seq_read+0x16e/0x3b0
+ [<ffffffff812281ed>] proc_reg_read+0x3d/0x80
+ [<ffffffff811c0f2c>] vfs_read+0x9c/0x170
+ [<ffffffff811c1a58>] SyS_read+0x58/0xb0
+ [<ffffffff81605829>] system_call_fastpath+0x16/0x1b
+ Code: 48 63 c2 83 c2 01 c6 04 03 29 48 63 d2 eb d9 0f 1f 80 00 00 00 00 48 63 d2 c6 04 13 2d 41 8b 0c 24 8d 50 02 83 f9 01 75 b2 eb cb <0f> 0b 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41
+ RIP [<ffffffff810d64c5>] module_flags+0xb5/0xc0
+ RSP <ffff88080fa7fe18>
+
+ Consider the two processes running on the system.
+
+ CPU 0 (/proc/modules reader)
+ CPU 1 (loading/unloading module)
+
+ CPU 0 opens /proc/modules, and starts displaying data for each module by
+ traversing the modules list via fs/seq_file.c:seq_open() and
+ fs/seq_file.c:seq_read(). For each module in the modules list, seq_read
+ does
+
+ op->start() <-- this is a pointer to m_start()
+ op->show() <- this is a pointer to m_show()
+ op->stop() <-- this is a pointer to m_stop()
+
+ The m_start(), m_show(), and m_stop() module functions are defined in
+ kernel/module.c. The m_start() and m_stop() functions acquire and release
+ the module_mutex respectively.
+
+ ie) When reading /proc/modules, the module_mutex is acquired and released
+ for each module.
+
+ m_show() is called with the module_mutex held. It accesses the module
+ struct data and attempts to write out module data. It is in this code
+ path that the above BUG_ON() warning is encountered, specifically m_show()
+ calls
+
+ static char *module_flags(struct module *mod, char *buf)
+ {
+ int bx = 0;
+
+ BUG_ON(mod->state == MODULE_STATE_UNFORMED);
+ ...
+
+ The other thread, CPU 1, in unloading the module calls the syscall
+ delete_module() defined in kernel/module.c. The module_mutex is acquired
+ for a short time, and then released. free_module() is called without the
+ module_mutex. free_module() then sets mod->state = MODULE_STATE_UNFORMED,
+ also without the module_mutex. Some additional code is called and then the
+ module_mutex is reacquired to remove the module from the modules list:
+
+ /* Now we can delete it from the lists */
+ mutex_lock(&module_mutex);
+ stop_machine(__unlink_module, mod, NULL);
+ mutex_unlock(&module_mutex);
+
+This is the sequence of events that leads to the panic.
+
+CPU 1 is removing dummy_module via delete_module(). It acquires the
+module_mutex, and then releases it. CPU 1 has NOT set dummy_module->state to
+MODULE_STATE_UNFORMED yet.
+
+CPU 0, which is reading the /proc/modules, acquires the module_mutex and
+acquires a pointer to the dummy_module which is still in the modules list.
+CPU 0 calls m_show for dummy_module. The check in m_show() for
+MODULE_STATE_UNFORMED passed for dummy_module even though it is being
+torn down.
+
+Meanwhile CPU 1, which has been continuing to remove dummy_module without
+holding the module_mutex, now calls free_module() and sets
+dummy_module->state to MODULE_STATE_UNFORMED.
+
+CPU 0 now calls module_flags() with dummy_module and ...
+
+static char *module_flags(struct module *mod, char *buf)
+{
+ int bx = 0;
+
+ BUG_ON(mod->state == MODULE_STATE_UNFORMED);
+
+and BOOM.
+
+Acquire and release the module_mutex lock around the setting of
+MODULE_STATE_UNFORMED in the teardown path, which should resolve the
+problem.
+
+Testing: In the unpatched kernel I can panic the system within 1 minute by
+doing
+
+while (true) do insmod dummy_module.ko; rmmod dummy_module.ko; done
+
+and
+
+while (true) do cat /proc/modules; done
+
+in separate terminals.
+
+In the patched kernel I was able to run just over one hour without seeing
+any issues. I also verified the output of panic via sysrq-c and the output
+of /proc/modules looks correct for all three states for the dummy_module.
+
+ dummy_module 12661 0 - Unloading 0xffffffffa03a5000 (OE-)
+ dummy_module 12661 0 - Live 0xffffffffa03bb000 (OE)
+ dummy_module 14015 1 - Loading 0xffffffffa03a5000 (OE+)
+
+Signed-off-by: Prarit Bhargava <prarit@redhat.com>
+Reviewed-by: Oleg Nesterov <oleg@redhat.com>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/module.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/module.c
++++ b/kernel/module.c
+@@ -1866,7 +1866,9 @@ static void free_module(struct module *m
+
+ /* We leave it in list to prevent duplicate loads, but make sure
+ * that noone uses it while it's being deconstructed. */
++ mutex_lock(&module_mutex);
+ mod->state = MODULE_STATE_UNFORMED;
++ mutex_unlock(&module_mutex);
+
+ /* Remove dynamic debug info */
+ ddebug_remove_module(mod->name);
--- /dev/null
+From d4bf205da618bbd0b038e404d646f14e76915718 Mon Sep 17 00:00:00 2001
+From: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
+Date: Sun, 12 Oct 2014 23:09:08 -0400
+Subject: pstore: Fix duplicate {console,ftrace}-efi entries
+
+From: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
+
+commit d4bf205da618bbd0b038e404d646f14e76915718 upstream.
+
+The pstore filesystem still creates duplicate filename/inode pairs for
+some pstore types. Add the id to the filename to prevent that.
+
+Before patch:
+
+[/sys/fs/pstore] ls -li
+total 0
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi
+
+After:
+
+[/sys/fs/pstore] ls -li
+total 0
+1232 -r--r--r--. 1 root root 148 Sep 29 17:09 console-efi-141202499100000
+1231 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi-141202499200000
+1230 -r--r--r--. 1 root root 148 Sep 29 17:44 console-efi-141202705400000
+1229 -r--r--r--. 1 root root 67 Sep 29 17:44 console-efi-141202705500000
+1228 -r--r--r--. 1 root root 67 Sep 29 20:42 console-efi-141203772600000
+1227 -r--r--r--. 1 root root 148 Sep 29 23:42 console-efi-141204854900000
+1226 -r--r--r--. 1 root root 67 Sep 29 23:42 console-efi-141204855000000
+1225 -r--r--r--. 1 root root 148 Sep 29 23:59 console-efi-141204954200000
+1224 -r--r--r--. 1 root root 67 Sep 29 23:59 console-efi-141204954400000
+
+Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
+Acked-by: Kees Cook <keescook@chromium.org>
+Signed-off-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/pstore/inode.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/pstore/inode.c
++++ b/fs/pstore/inode.c
+@@ -316,10 +316,10 @@ int pstore_mkfile(enum pstore_type_id ty
+ sprintf(name, "dmesg-%s-%lld", psname, id);
+ break;
+ case PSTORE_TYPE_CONSOLE:
+- sprintf(name, "console-%s", psname);
++ sprintf(name, "console-%s-%lld", psname, id);
+ break;
+ case PSTORE_TYPE_FTRACE:
+- sprintf(name, "ftrace-%s", psname);
++ sprintf(name, "ftrace-%s-%lld", psname, id);
+ break;
+ case PSTORE_TYPE_MCE:
+ sprintf(name, "mce-%s-%lld", psname, id);
--- /dev/null
+From 923190d32de4428afbea5e5773be86bea60a9925 Mon Sep 17 00:00:00 2001
+From: Stephen Smalley <sds@tycho.nsa.gov>
+Date: Mon, 6 Oct 2014 16:32:52 -0400
+Subject: selinux: fix inode security list corruption
+
+From: Stephen Smalley <sds@tycho.nsa.gov>
+
+commit 923190d32de4428afbea5e5773be86bea60a9925 upstream.
+
+sb_finish_set_opts() can race with inode_free_security()
+when initializing inode security structures for inodes
+created prior to initial policy load or by the filesystem
+during ->mount(). This appears to have always been
+a possible race, but commit 3dc91d4 ("SELinux: Fix possible
+NULL pointer dereference in selinux_inode_permission()")
+made it more evident by immediately reusing the unioned
+list/rcu element of the inode security structure for call_rcu()
+upon an inode_free_security(). But the underlying issue
+was already present before that commit as a possible use-after-free
+of isec.
+
+Shivnandan Kumar reported the list corruption and proposed
+a patch to split the list and rcu elements out of the union
+as separate fields of the inode_security_struct so that setting
+the rcu element would not affect the list element. However,
+this would merely hide the issue and not truly fix the code.
+
+This patch instead moves up the deletion of the list entry
+prior to dropping the sbsec->isec_lock initially. Then,
+if the inode is dropped subsequently, there will be no further
+references to the isec.
+
+Reported-by: Shivnandan Kumar <shivnandan.k@samsung.com>
+Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
+Signed-off-by: Paul Moore <pmoore@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ security/selinux/hooks.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/security/selinux/hooks.c
++++ b/security/selinux/hooks.c
+@@ -437,6 +437,7 @@ next_inode:
+ list_entry(sbsec->isec_head.next,
+ struct inode_security_struct, list);
+ struct inode *inode = isec->inode;
++ list_del_init(&isec->list);
+ spin_unlock(&sbsec->isec_lock);
+ inode = igrab(inode);
+ if (inode) {
+@@ -445,7 +446,6 @@ next_inode:
+ iput(inode);
+ }
+ spin_lock(&sbsec->isec_lock);
+- list_del_init(&isec->list);
+ goto next_inode;
+ }
+ spin_unlock(&sbsec->isec_lock);
fix-misuses-of-f_count-in-ppp-and-netlink.patch
crypto-more-robust-crypto_memneq.patch
random-add-and-use-memzero_explicit-for-clearing-data.patch
+ubi-add-missing-kmem_cache_free-in-process_pool_aeb-error-path.patch
+mnt-prevent-pivot_root-from-creating-a-loop-in-the-mount-tree.patch
+mfd-rtsx_pcr-fix-msi-enable-error-handling.patch
+pstore-fix-duplicate-console-ftrace-efi-entries.patch
+selinux-fix-inode-security-list-corruption.patch
+virtio_pci-fix-virtio-spec-compliance-on-restore.patch
+dm-bufio-update-last_accessed-when-relinking-a-buffer.patch
+drbd-compute-the-end-before-rb_insert_augmented.patch
+block-fix-alignment_offset-math-that-assumes-io_min-is-a-power-of-2.patch
+dm-log-userspace-fix-memory-leak-in-dm_ulog_tfr_init-failure-path.patch
+modules-lock-around-setting-of-module_state_unformed.patch
+framebuffer-fix-border-color.patch
+input-i8042-add-noloop-quirk-for-asus-x750ln.patch
+input-i8042-quirks-for-fujitsu-lifebook-a544-and-lifebook-ah544.patch
+drm-ast-fix-hw-cursor-image.patch
+drm-tilcdc-fix-the-error-path-in-tilcdc_load.patch
+drm-nouveau-bios-memset-dcb-struct-to-zero-before-parsing.patch
--- /dev/null
+From 1bf1890e86869032099b539bc83b098be12fc5a7 Mon Sep 17 00:00:00 2001
+From: Richard Genoud <richard.genoud@gmail.com>
+Date: Tue, 9 Sep 2014 14:25:01 +0200
+Subject: UBI: add missing kmem_cache_free() in process_pool_aeb error path
+
+From: Richard Genoud <richard.genoud@gmail.com>
+
+commit 1bf1890e86869032099b539bc83b098be12fc5a7 upstream.
+
+I ran into this error after a ubiupdatevol, because I forgot to backport
+e9110361a9a4 UBI: fix the volumes tree sorting criteria.
+
+UBI error: process_pool_aeb: orphaned volume in fastmap pool
+UBI error: ubi_scan_fastmap: Attach by fastmap failed, doing a full scan!
+kmem_cache_destroy ubi_ainf_peb_slab: Slab cache still has objects
+CPU: 0 PID: 1 Comm: swapper Not tainted 3.14.18-00053-gf05cac8dbf85 #1
+[<c000d298>] (unwind_backtrace) from [<c000baa8>] (show_stack+0x10/0x14)
+[<c000baa8>] (show_stack) from [<c01b7a68>] (destroy_ai+0x230/0x244)
+[<c01b7a68>] (destroy_ai) from [<c01b8fd4>] (ubi_attach+0x98/0x1ec)
+[<c01b8fd4>] (ubi_attach) from [<c01ade90>] (ubi_attach_mtd_dev+0x2b8/0x868)
+[<c01ade90>] (ubi_attach_mtd_dev) from [<c038b510>] (ubi_init+0x1dc/0x2ac)
+[<c038b510>] (ubi_init) from [<c0008860>] (do_one_initcall+0x94/0x140)
+[<c0008860>] (do_one_initcall) from [<c037aadc>] (kernel_init_freeable+0xe8/0x1b0)
+[<c037aadc>] (kernel_init_freeable) from [<c02730ac>] (kernel_init+0x8/0xe4)
+[<c02730ac>] (kernel_init) from [<c00093f0>] (ret_from_fork+0x14/0x24)
+UBI: scanning is finished
+
+Freeing the cache in the error path fixes the Slab error.
+
+Tested on at91sam9g35 (3.14.18+fastmap backports)
+
+Signed-off-by: Richard Genoud <richard.genoud@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/fastmap.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/mtd/ubi/fastmap.c
++++ b/drivers/mtd/ubi/fastmap.c
+@@ -330,6 +330,7 @@ static int process_pool_aeb(struct ubi_d
+ av = tmp_av;
+ else {
+ ubi_err("orphaned volume in fastmap pool!");
++ kmem_cache_free(ai->aeb_slab_cache, new_aeb);
+ return UBI_BAD_FASTMAP;
+ }
+
--- /dev/null
+From 6fbc198cf623944ab60a1db6d306a4d55cdd820d Mon Sep 17 00:00:00 2001
+From: "Michael S. Tsirkin" <mst@redhat.com>
+Date: Tue, 14 Oct 2014 10:40:29 +1030
+Subject: virtio_pci: fix virtio spec compliance on restore
+
+From: "Michael S. Tsirkin" <mst@redhat.com>
+
+commit 6fbc198cf623944ab60a1db6d306a4d55cdd820d upstream.
+
+On restore, virtio pci does the following:
++ set features
++ init vqs etc - device can be used at this point!
++ set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits
+
+This is in violation of the virtio spec, which
+requires the following order:
+- ACKNOWLEDGE
+- DRIVER
+- init vqs
+- DRIVER_OK
+
+This behaviour will break with hypervisors that assume spec compliant
+behaviour. It seems like a good idea to have this patch applied to
+stable branches to reduce the support butden for the hypervisors.
+
+Cc: Amit Shah <amit.shah@redhat.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/virtio/virtio_pci.c | 33 ++++++++++++++++++++++++++++++---
+ 1 file changed, 30 insertions(+), 3 deletions(-)
+
+--- a/drivers/virtio/virtio_pci.c
++++ b/drivers/virtio/virtio_pci.c
+@@ -791,6 +791,7 @@ static int virtio_pci_restore(struct dev
+ struct pci_dev *pci_dev = to_pci_dev(dev);
+ struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev);
+ struct virtio_driver *drv;
++ unsigned status = 0;
+ int ret;
+
+ drv = container_of(vp_dev->vdev.dev.driver,
+@@ -801,14 +802,40 @@ static int virtio_pci_restore(struct dev
+ return ret;
+
+ pci_set_master(pci_dev);
++ /* We always start by resetting the device, in case a previous
++ * driver messed it up. */
++ vp_reset(&vp_dev->vdev);
++
++ /* Acknowledge that we've seen the device. */
++ status |= VIRTIO_CONFIG_S_ACKNOWLEDGE;
++ vp_set_status(&vp_dev->vdev, status);
++
++ /* Maybe driver failed before freeze.
++ * Restore the failed status, for debugging. */
++ status |= vp_dev->saved_status & VIRTIO_CONFIG_S_FAILED;
++ vp_set_status(&vp_dev->vdev, status);
++
++ if (!drv)
++ return 0;
++
++ /* We have a driver! */
++ status |= VIRTIO_CONFIG_S_DRIVER;
++ vp_set_status(&vp_dev->vdev, status);
++
+ vp_finalize_features(&vp_dev->vdev);
+
+- if (drv && drv->restore)
++ if (drv->restore) {
+ ret = drv->restore(&vp_dev->vdev);
++ if (ret) {
++ status |= VIRTIO_CONFIG_S_FAILED;
++ vp_set_status(&vp_dev->vdev, status);
++ return ret;
++ }
++ }
+
+ /* Finally, tell the device we're all set */
+- if (!ret)
+- vp_set_status(&vp_dev->vdev, vp_dev->saved_status);
++ status |= VIRTIO_CONFIG_S_DRIVER_OK;
++ vp_set_status(&vp_dev->vdev, status);
+
+ return ret;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
