--- /dev/null
+From 9b460d3699324d570a4d4161c3741431887f102f Mon Sep 17 00:00:00 2001
+From: Joe Thornber <ejt@redhat.com>
+Date: Mon, 10 Nov 2014 15:03:24 +0000
+Subject: dm btree: fix a recursion depth bug in btree walking code
+
+From: Joe Thornber <ejt@redhat.com>
+
+commit 9b460d3699324d570a4d4161c3741431887f102f upstream.
+
+The walk code was using a 'ro_spine' to hold it's locked btree nodes.
+But this data structure is designed for the rolling lock scheme, and
+as such automatically unlocks blocks that are two steps up the call
+chain. This is not suitable for the simple recursive walk algorithm,
+which retraces its steps.
+
+This code is only used by the persistent array code, which in turn is
+only used by dm-cache. In order to trigger it you need to have a
+mapping tree that is more than 2 levels deep; which equates to 8-16
+million cache blocks. For instance a 4T ssd with a very small block
+size of 32k only just triggers this bug.
+
+The fix just places the locked blocks on the stack, and stops using
+the ro_spine altogether.
+
+Signed-off-by: Joe Thornber <ejt@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/persistent-data/dm-btree-internal.h | 6 ++++++
+ drivers/md/persistent-data/dm-btree-spine.c | 2 +-
+ drivers/md/persistent-data/dm-btree.c | 24 ++++++++++--------------
+ 3 files changed, 17 insertions(+), 15 deletions(-)
+
+--- a/drivers/md/persistent-data/dm-btree-internal.h
++++ b/drivers/md/persistent-data/dm-btree-internal.h
+@@ -42,6 +42,12 @@ struct btree_node {
+ } __packed;
+
+
++/*
++ * Locks a block using the btree node validator.
++ */
++int bn_read_lock(struct dm_btree_info *info, dm_block_t b,
++ struct dm_block **result);
++
+ void inc_children(struct dm_transaction_manager *tm, struct btree_node *n,
+ struct dm_btree_value_type *vt);
+
+--- a/drivers/md/persistent-data/dm-btree-spine.c
++++ b/drivers/md/persistent-data/dm-btree-spine.c
+@@ -92,7 +92,7 @@ struct dm_block_validator btree_node_val
+
+ /*----------------------------------------------------------------*/
+
+-static int bn_read_lock(struct dm_btree_info *info, dm_block_t b,
++int bn_read_lock(struct dm_btree_info *info, dm_block_t b,
+ struct dm_block **result)
+ {
+ return dm_tm_read_lock(info->tm, b, &btree_node_validator, result);
+--- a/drivers/md/persistent-data/dm-btree.c
++++ b/drivers/md/persistent-data/dm-btree.c
+@@ -847,22 +847,26 @@ EXPORT_SYMBOL_GPL(dm_btree_find_lowest_k
+ * FIXME: We shouldn't use a recursive algorithm when we have limited stack
+ * space. Also this only works for single level trees.
+ */
+-static int walk_node(struct ro_spine *s, dm_block_t block,
++static int walk_node(struct dm_btree_info *info, dm_block_t block,
+ int (*fn)(void *context, uint64_t *keys, void *leaf),
+ void *context)
+ {
+ int r;
+ unsigned i, nr;
++ struct dm_block *node;
+ struct btree_node *n;
+ uint64_t keys;
+
+- r = ro_step(s, block);
+- n = ro_node(s);
++ r = bn_read_lock(info, block, &node);
++ if (r)
++ return r;
++
++ n = dm_block_data(node);
+
+ nr = le32_to_cpu(n->header.nr_entries);
+ for (i = 0; i < nr; i++) {
+ if (le32_to_cpu(n->header.flags) & INTERNAL_NODE) {
+- r = walk_node(s, value64(n, i), fn, context);
++ r = walk_node(info, value64(n, i), fn, context);
+ if (r)
+ goto out;
+ } else {
+@@ -874,7 +878,7 @@ static int walk_node(struct ro_spine *s,
+ }
+
+ out:
+- ro_pop(s);
++ dm_tm_unlock(info->tm, node);
+ return r;
+ }
+
+@@ -882,15 +886,7 @@ int dm_btree_walk(struct dm_btree_info *
+ int (*fn)(void *context, uint64_t *keys, void *leaf),
+ void *context)
+ {
+- int r;
+- struct ro_spine spine;
+-
+ BUG_ON(info->levels > 1);
+-
+- init_ro_spine(&spine, info);
+- r = walk_node(&spine, root, fn, context);
+- exit_ro_spine(&spine);
+-
+- return r;
++ return walk_node(info, root, fn, context);
+ }
+ EXPORT_SYMBOL_GPL(dm_btree_walk);
--- /dev/null
+From 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Thu, 16 Oct 2014 14:45:20 -0400
+Subject: dm bufio: change __GFP_IO to __GFP_FS in shrinker callbacks
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 upstream.
+
+The shrinker uses gfp flags to indicate what kind of operation can the
+driver wait for. If __GFP_IO flag is present, the driver can wait for
+block I/O operations, if __GFP_FS flag is present, the driver can wait on
+operations involving the filesystem.
+
+dm-bufio tested for __GFP_IO. However, dm-bufio can run on a loop block
+device that makes calls into the filesystem. If __GFP_IO is present and
+__GFP_FS isn't, dm-bufio could still block on filesystem operations if it
+runs on a loop block device.
+
+The change from __GFP_IO to __GFP_FS supposedly fixes one observed (though
+unreproducible) deadlock involving dm-bufio and loop device.
+
+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 | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+--- a/drivers/md/dm-bufio.c
++++ b/drivers/md/dm-bufio.c
+@@ -1448,9 +1448,9 @@ static void drop_buffers(struct dm_bufio
+
+ /*
+ * Test if the buffer is unused and too old, and commit it.
+- * At if noio is set, we must not do any I/O because we hold
+- * dm_bufio_clients_lock and we would risk deadlock if the I/O gets rerouted to
+- * different bufio client.
++ * And if GFP_NOFS is used, we must not do any I/O because we hold
++ * dm_bufio_clients_lock and we would risk deadlock if the I/O gets
++ * rerouted to different bufio client.
+ */
+ static int __cleanup_old_buffer(struct dm_buffer *b, gfp_t gfp,
+ unsigned long max_jiffies)
+@@ -1458,7 +1458,7 @@ static int __cleanup_old_buffer(struct d
+ if (jiffies - b->last_accessed < max_jiffies)
+ return 0;
+
+- if (!(gfp & __GFP_IO)) {
++ if (!(gfp & __GFP_FS)) {
+ if (test_bit(B_READING, &b->state) ||
+ test_bit(B_WRITING, &b->state) ||
+ test_bit(B_DIRTY, &b->state))
+@@ -1500,7 +1500,7 @@ dm_bufio_shrink_scan(struct shrinker *sh
+ unsigned long freed;
+
+ c = container_of(shrink, struct dm_bufio_client, shrinker);
+- if (sc->gfp_mask & __GFP_IO)
++ if (sc->gfp_mask & __GFP_FS)
+ dm_bufio_lock(c);
+ else if (!dm_bufio_trylock(c))
+ return SHRINK_STOP;
+@@ -1517,7 +1517,7 @@ dm_bufio_shrink_count(struct shrinker *s
+ unsigned long count;
+
+ c = container_of(shrink, struct dm_bufio_client, shrinker);
+- if (sc->gfp_mask & __GFP_IO)
++ if (sc->gfp_mask & __GFP_FS)
+ dm_bufio_lock(c);
+ else if (!dm_bufio_trylock(c))
+ return 0;
--- /dev/null
+From 40d43c4b4cac4c2647bf07110d7b07d35f399a84 Mon Sep 17 00:00:00 2001
+From: Heinz Mauelshagen <heinzm@redhat.com>
+Date: Fri, 17 Oct 2014 13:38:50 +0200
+Subject: dm raid: ensure superblock's size matches device's logical block size
+
+From: Heinz Mauelshagen <heinzm@redhat.com>
+
+commit 40d43c4b4cac4c2647bf07110d7b07d35f399a84 upstream.
+
+The dm-raid superblock (struct dm_raid_superblock) is padded to 512
+bytes and that size is being used to read it in from the metadata
+device into one preallocated page.
+
+Reading or writing this on a 512-byte sector device works fine but on
+a 4096-byte sector device this fails.
+
+Set the dm-raid superblock's size to the logical block size of the
+metadata device, because IO at that size is guaranteed too work. Also
+add a size check to avoid silent partial metadata loss in case the
+superblock should ever grow past the logical block size or PAGE_SIZE.
+
+[includes pointer math fix from Dan Carpenter]
+Reported-by: "Liuhua Wang" <lwang@suse.com>
+Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com>
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-raid.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/drivers/md/dm-raid.c
++++ b/drivers/md/dm-raid.c
+@@ -785,8 +785,7 @@ struct dm_raid_superblock {
+ __le32 layout;
+ __le32 stripe_sectors;
+
+- __u8 pad[452]; /* Round struct to 512 bytes. */
+- /* Always set to 0 when writing. */
++ /* Remainder of a logical block is zero-filled when writing (see super_sync()). */
+ } __packed;
+
+ static int read_disk_sb(struct md_rdev *rdev, int size)
+@@ -823,7 +822,7 @@ static void super_sync(struct mddev *mdd
+ test_bit(Faulty, &(rs->dev[i].rdev.flags)))
+ failed_devices |= (1ULL << i);
+
+- memset(sb, 0, sizeof(*sb));
++ memset(sb + 1, 0, rdev->sb_size - sizeof(*sb));
+
+ sb->magic = cpu_to_le32(DM_RAID_MAGIC);
+ sb->features = cpu_to_le32(0); /* No features yet */
+@@ -858,7 +857,11 @@ static int super_load(struct md_rdev *rd
+ uint64_t events_sb, events_refsb;
+
+ rdev->sb_start = 0;
+- rdev->sb_size = sizeof(*sb);
++ rdev->sb_size = bdev_logical_block_size(rdev->meta_bdev);
++ if (rdev->sb_size < sizeof(*sb) || rdev->sb_size > PAGE_SIZE) {
++ DMERR("superblock size of a logical block is no longer valid");
++ return -EINVAL;
++ }
+
+ ret = read_disk_sb(rdev, rdev->sb_size);
+ if (ret)
--- /dev/null
+From 9d720b34c0a432639252f63012e18b0507f5b432 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali.rohar@gmail.com>
+Date: Sat, 8 Nov 2014 12:58:57 -0800
+Subject: Input: alps - allow up to 2 invalid packets without resetting device
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali.rohar@gmail.com>
+
+commit 9d720b34c0a432639252f63012e18b0507f5b432 upstream.
+
+On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte
+in 6 bytes ALPS packet. In this case psmouse driver enter out of sync
+state. It looks like that all other bytes in packets are valid and also
+device working properly. So there is no need to do full device reset, just
+need to wait for byte which match condition for first byte (start of
+packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is
+small.
+
+This patch increase number of invalid bytes to size of 2 ALPS packets which
+psmouse driver can drop before do full reset.
+
+Resetting ALPS devices take some time and when doing reset on some Dell
+laptops touchpad, trackstick and also keyboard do not respond. So it is
+better to do it only if really necessary.
+
+Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
+Tested-by: Pali Rohár <pali.rohar@gmail.com>
+Reviewed-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/mouse/alps.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/input/mouse/alps.c
++++ b/drivers/input/mouse/alps.c
+@@ -2154,6 +2154,9 @@ int alps_init(struct psmouse *psmouse)
+ /* We are having trouble resyncing ALPS touchpads so disable it for now */
+ psmouse->resync_time = 0;
+
++ /* Allow 2 invalid packets without resetting device */
++ psmouse->resetafter = psmouse->pktsize * 2;
++
+ return 0;
+
+ init_fail:
--- /dev/null
+From a7ef82aee91f26da79b981b9f5bca43b8817d3e4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali.rohar@gmail.com>
+Date: Sat, 8 Nov 2014 23:36:09 -0800
+Subject: Input: alps - ignore bad data on Dell Latitudes E6440 and E7440
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali.rohar@gmail.com>
+
+commit a7ef82aee91f26da79b981b9f5bca43b8817d3e4 upstream.
+
+Sometimes on Dell Latitude laptops psmouse/alps driver receive invalid ALPS
+protocol V3 packets with bit7 set in last byte. More often it can be
+reproduced on Dell Latitude E6440 or E7440 with closed lid and pushing
+cover above touchpad.
+
+If bit7 in last packet byte is set then it is not valid ALPS packet. I was
+told that ALPS devices never send these packets. It is not know yet who
+send those packets, it could be Dell EC, bug in BIOS and also bug in
+touchpad firmware...
+
+With this patch alps driver does not process those invalid packets, but
+instead of reporting PSMOUSE_BAD_DATA, getting into out of sync state,
+getting back in sync with the next byte and spam dmesg we return
+PSMOUSE_FULL_PACKET. If driver is truly out of sync we'll fail the checks
+on the next byte and report PSMOUSE_BAD_DATA then.
+
+Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
+Tested-by: Pali Rohár <pali.rohar@gmail.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/alps.c | 17 ++++++++++++++++-
+ 1 file changed, 16 insertions(+), 1 deletion(-)
+
+--- a/drivers/input/mouse/alps.c
++++ b/drivers/input/mouse/alps.c
+@@ -1077,12 +1077,27 @@ static psmouse_ret_t alps_process_byte(s
+ }
+
+ /* Bytes 2 - pktsize should have 0 in the highest bit */
+- if ((priv->proto_version < ALPS_PROTO_V5) &&
++ if (priv->proto_version < ALPS_PROTO_V5 &&
+ psmouse->pktcnt >= 2 && psmouse->pktcnt <= psmouse->pktsize &&
+ (psmouse->packet[psmouse->pktcnt - 1] & 0x80)) {
+ psmouse_dbg(psmouse, "refusing packet[%i] = %x\n",
+ psmouse->pktcnt - 1,
+ psmouse->packet[psmouse->pktcnt - 1]);
++
++ if (priv->proto_version == ALPS_PROTO_V3 &&
++ psmouse->pktcnt == psmouse->pktsize) {
++ /*
++ * Some Dell boxes, such as Latitude E6440 or E7440
++ * with closed lid, quite often smash last byte of
++ * otherwise valid packet with 0xff. Given that the
++ * next packet is very likely to be valid let's
++ * report PSMOUSE_FULL_PACKET but not process data,
++ * rather than reporting PSMOUSE_BAD_DATA and
++ * filling the logs.
++ */
++ return PSMOUSE_FULL_PACKET;
++ }
++
+ return PSMOUSE_BAD_DATA;
+ }
+
--- /dev/null
+From 4ab8f7f320f91f279c3f06a9795cfea5c972888a Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali.rohar@gmail.com>
+Date: Sat, 8 Nov 2014 12:45:23 -0800
+Subject: Input: alps - ignore potential bare packets when device is out of sync
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Pali=20Roh=C3=A1r?= <pali.rohar@gmail.com>
+
+commit 4ab8f7f320f91f279c3f06a9795cfea5c972888a upstream.
+
+5th and 6th byte of ALPS trackstick V3 protocol match condition for first
+byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS
+trackstick is sending data then driver match 5th, 6th and next 1st bytes as
+PS/2.
+
+It basically means if user is using trackstick when driver is in out of
+sync state driver will never resync. Processing these bytes as 3 bytes PS/2
+data cause total mess (random cursor movements, random clicks) and make
+trackstick unusable until psmouse driver decide to do full device reset.
+
+Lot of users reported problems with ALPS devices on Dell Latitude E6440,
+E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send
+some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like
+that i8042 and psmouse/alps driver always receive group of 6 bytes packets
+so there are no missing bytes and no bytes were inserted between valid
+ones.
+
+This patch does not fix root of problem with ALPS devices found in Dell
+Latitude laptops but it does not allow to process some (invalid)
+subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of
+sync.
+
+So with this patch trackstick input device does not report bogus data when
+also driver is out of sync, so trackstick should be usable on those
+machines.
+
+Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
+Tested-by: Pali Rohár <pali.rohar@gmail.com>
+Reviewed-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/mouse/alps.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/drivers/input/mouse/alps.c
++++ b/drivers/input/mouse/alps.c
+@@ -1047,7 +1047,13 @@ static psmouse_ret_t alps_process_byte(s
+ {
+ struct alps_data *priv = psmouse->private;
+
+- if ((psmouse->packet[0] & 0xc8) == 0x08) { /* PS/2 packet */
++ /*
++ * Check if we are dealing with a bare PS/2 packet, presumably from
++ * a device connected to the external PS/2 port. Because bare PS/2
++ * protocol does not have enough constant bits to self-synchronize
++ * properly we only do this if the device is fully synchronized.
++ */
++ if (!psmouse->out_of_sync_cnt && (psmouse->packet[0] & 0xc8) == 0x08) {
+ if (psmouse->pktcnt == 3) {
+ alps_report_bare_ps2_packet(psmouse, psmouse->packet,
+ true);
--- /dev/null
+From e4742b1e786ca386e88e6cfb2801e14e15e365cd Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Thu, 6 Nov 2014 09:27:11 -0800
+Subject: Input: synaptics - add min/max quirk for Lenovo T440s
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit e4742b1e786ca386e88e6cfb2801e14e15e365cd upstream.
+
+The new Lenovo T440s laptop has a different PnP ID "LEN0039", and it
+needs the similar min/max quirk to make its clickpad working.
+
+BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=903748
+Reported-and-tested-by: Joschi Brauchle <joschibrauchle@gmx.de>
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/synaptics.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/mouse/synaptics.c
++++ b/drivers/input/mouse/synaptics.c
+@@ -132,8 +132,8 @@ static const struct min_max_quirk min_ma
+ 1232, 5710, 1156, 4696
+ },
+ {
+- (const char * const []){"LEN0034", "LEN0036", "LEN2002",
+- "LEN2004", NULL},
++ (const char * const []){"LEN0034", "LEN0036", "LEN0039",
++ "LEN2002", "LEN2004", NULL},
+ 1024, 5112, 2024, 4832
+ },
+ {
+@@ -160,6 +160,7 @@ static const char * const topbuttonpad_p
+ "LEN0036", /* T440 */
+ "LEN0037",
+ "LEN0038",
++ "LEN0039", /* T440s */
+ "LEN0041",
+ "LEN0042", /* Yoga */
+ "LEN0045",
scsi-only-re-lock-door-after-eh-on-devices-that-were-reset.patch
parisc-use-compat-layer-for-msgctl-shmat-shmctl-and-semtimedop-syscalls.patch
block-fix-computation-of-merged-request-priority.patch
+dm-bufio-change-__gfp_io-to-__gfp_fs-in-shrinker-callbacks.patch
+dm-btree-fix-a-recursion-depth-bug-in-btree-walking-code.patch
+dm-raid-ensure-superblock-s-size-matches-device-s-logical-block-size.patch
+input-synaptics-add-min-max-quirk-for-lenovo-t440s.patch
+input-alps-ignore-potential-bare-packets-when-device-is-out-of-sync.patch
+input-alps-allow-up-to-2-invalid-packets-without-resetting-device.patch
+input-alps-ignore-bad-data-on-dell-latitudes-e6440-and-e7440.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
