--- /dev/null
+From 09712f557b31838092e1f22a5f2dd131a843a3de Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Tue, 4 Nov 2014 17:05:25 +0100
+Subject: cpufreq: Avoid crash in resume on SMP without OPP
+
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+
+commit 09712f557b31838092e1f22a5f2dd131a843a3de upstream.
+
+When resuming from s2ram on an SMP system without cpufreq operating
+points (e.g. there's no "operating-points" property for the CPU node in
+DT, or the platform doesn't use DT yet), the kernel crashes when
+bringing CPU 1 online:
+
+ Enabling non-boot CPUs ...
+ CPU1: Booted secondary processor
+ Unable to handle kernel NULL pointer dereference at virtual address 0000003c
+ pgd = ee5e6b00
+ [0000003c] *pgd=6e579003, *pmd=6e588003, *pte=00000000
+ Internal error: Oops: a07 [#1] SMP ARM
+ Modules linked in:
+ CPU: 0 PID: 1246 Comm: s2ram Tainted: G W 3.18.0-rc3-koelsch-01614-g0377af242bb175c8-dirty #589
+ task: eeec5240 ti: ee704000 task.ti: ee704000
+ PC is at __cpufreq_add_dev.isra.24+0x24c/0x77c
+ LR is at __cpufreq_add_dev.isra.24+0x244/0x77c
+ pc : [<c0298efc>] lr : [<c0298ef4>] psr: 60000153
+ sp : ee705d48 ip : ee705d48 fp : ee705d84
+ r10: c04e0450 r9 : 00000000 r8 : 00000001
+ r7 : c05426a8 r6 : 00000001 r5 : 00000001 r4 : 00000000
+ r3 : 00000000 r2 : 00000000 r1 : 20000153 r0 : c0542734
+
+Verify that policy is not NULL before dereferencing it to fix this.
+
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Fixes: 8414809c6a1e (cpufreq: Preserve policy structure across suspend/resume)
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/cpufreq.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/cpufreq/cpufreq.c
++++ b/drivers/cpufreq/cpufreq.c
+@@ -1022,7 +1022,8 @@ static struct cpufreq_policy *cpufreq_po
+
+ read_unlock_irqrestore(&cpufreq_driver_lock, flags);
+
+- policy->governor = NULL;
++ if (policy)
++ policy->governor = NULL;
+
+ return policy;
+ }
--- /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
+@@ -1435,9 +1435,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)
+@@ -1445,7 +1445,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))
+@@ -1487,7 +1487,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;
+@@ -1504,7 +1504,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
+@@ -2395,6 +2395,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
+@@ -1186,12 +1186,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
+@@ -1156,7 +1156,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
+@@ -135,8 +135,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
+ },
+ {
+@@ -163,6 +163,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
+cpufreq-avoid-crash-in-resume-on-smp-without-opp.patch
+sunrpc-fix-sleeping-under-rcu_read_lock-in-gss_stringify_acceptor.patch
--- /dev/null
+From b3ecba096729f521312d1863ad22530695527aed Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@primarydata.com>
+Date: Thu, 13 Nov 2014 07:30:46 -0500
+Subject: sunrpc: fix sleeping under rcu_read_lock in gss_stringify_acceptor
+
+From: Jeff Layton <jlayton@primarydata.com>
+
+commit b3ecba096729f521312d1863ad22530695527aed upstream.
+
+Bruce reported that he was seeing the following BUG pop:
+
+ BUG: sleeping function called from invalid context at mm/slab.c:2846
+ in_atomic(): 0, irqs_disabled(): 0, pid: 4539, name: mount.nfs
+ 2 locks held by mount.nfs/4539:
+ #0: (nfs_clid_init_mutex){+.+.+.}, at: [<ffffffffa01c0a9a>] nfs4_discover_server_trunking+0x4a/0x2f0 [nfsv4]
+ #1: (rcu_read_lock){......}, at: [<ffffffffa00e3185>] gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss]
+ Preemption disabled at:[<ffffffff81a4f082>] printk+0x4d/0x4f
+
+ CPU: 3 PID: 4539 Comm: mount.nfs Not tainted 3.18.0-rc1-00013-g5b095e9 #3393
+ Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
+ ffff880021499390 ffff8800381476a8 ffffffff81a534cf 0000000000000001
+ 0000000000000000 ffff8800381476c8 ffffffff81097854 00000000000000d0
+ 0000000000000018 ffff880038147718 ffffffff8118e4f3 0000000020479f00
+ Call Trace:
+ [<ffffffff81a534cf>] dump_stack+0x4f/0x7c
+ [<ffffffff81097854>] __might_sleep+0x114/0x180
+ [<ffffffff8118e4f3>] __kmalloc+0x1a3/0x280
+ [<ffffffffa00e31d8>] gss_stringify_acceptor+0x58/0xb0 [auth_rpcgss]
+ [<ffffffffa00e3185>] ? gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss]
+ [<ffffffffa006b438>] rpcauth_stringify_acceptor+0x18/0x30 [sunrpc]
+ [<ffffffffa01b0469>] nfs4_proc_setclientid+0x199/0x380 [nfsv4]
+ [<ffffffffa01b04d0>] ? nfs4_proc_setclientid+0x200/0x380 [nfsv4]
+ [<ffffffffa01bdf1a>] nfs40_discover_server_trunking+0xda/0x150 [nfsv4]
+ [<ffffffffa01bde45>] ? nfs40_discover_server_trunking+0x5/0x150 [nfsv4]
+ [<ffffffffa01c0acf>] nfs4_discover_server_trunking+0x7f/0x2f0 [nfsv4]
+ [<ffffffffa01c8e24>] nfs4_init_client+0x104/0x2f0 [nfsv4]
+ [<ffffffffa01539b4>] nfs_get_client+0x314/0x3f0 [nfs]
+ [<ffffffffa0153780>] ? nfs_get_client+0xe0/0x3f0 [nfs]
+ [<ffffffffa01c83aa>] nfs4_set_client+0x8a/0x110 [nfsv4]
+ [<ffffffffa0069708>] ? __rpc_init_priority_wait_queue+0xa8/0xf0 [sunrpc]
+ [<ffffffffa01c9b2f>] nfs4_create_server+0x12f/0x390 [nfsv4]
+ [<ffffffffa01c1472>] nfs4_remote_mount+0x32/0x60 [nfsv4]
+ [<ffffffff81196489>] mount_fs+0x39/0x1b0
+ [<ffffffff81166145>] ? __alloc_percpu+0x15/0x20
+ [<ffffffff811b276b>] vfs_kern_mount+0x6b/0x150
+ [<ffffffffa01c1396>] nfs_do_root_mount+0x86/0xc0 [nfsv4]
+ [<ffffffffa01c1784>] nfs4_try_mount+0x44/0xc0 [nfsv4]
+ [<ffffffffa01549b7>] ? get_nfs_version+0x27/0x90 [nfs]
+ [<ffffffffa0161a2d>] nfs_fs_mount+0x47d/0xd60 [nfs]
+ [<ffffffff81a59c5e>] ? mutex_unlock+0xe/0x10
+ [<ffffffffa01606a0>] ? nfs_remount+0x430/0x430 [nfs]
+ [<ffffffffa01609c0>] ? nfs_clone_super+0x140/0x140 [nfs]
+ [<ffffffff81196489>] mount_fs+0x39/0x1b0
+ [<ffffffff81166145>] ? __alloc_percpu+0x15/0x20
+ [<ffffffff811b276b>] vfs_kern_mount+0x6b/0x150
+ [<ffffffff811b5830>] do_mount+0x210/0xbe0
+ [<ffffffff811b54ca>] ? copy_mount_options+0x3a/0x160
+ [<ffffffff811b651f>] SyS_mount+0x6f/0xb0
+ [<ffffffff81a5c852>] system_call_fastpath+0x12/0x17
+
+Sleeping under the rcu_read_lock is bad. This patch fixes it by dropping
+the rcu_read_lock before doing the allocation and then reacquiring it
+and redoing the dereference before doing the copy. If we find that the
+string has somehow grown in the meantime, we'll reallocate and try again.
+
+Reported-by: "J. Bruce Fields" <bfields@fieldses.org>
+Signed-off-by: Jeff Layton <jlayton@primarydata.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/sunrpc/auth_gss/auth_gss.c | 35 ++++++++++++++++++++++++++++++-----
+ 1 file changed, 30 insertions(+), 5 deletions(-)
+
+--- a/net/sunrpc/auth_gss/auth_gss.c
++++ b/net/sunrpc/auth_gss/auth_gss.c
+@@ -1353,6 +1353,7 @@ gss_stringify_acceptor(struct rpc_cred *
+ char *string = NULL;
+ struct gss_cred *gss_cred = container_of(cred, struct gss_cred, gc_base);
+ struct gss_cl_ctx *ctx;
++ unsigned int len;
+ struct xdr_netobj *acceptor;
+
+ rcu_read_lock();
+@@ -1360,15 +1361,39 @@ gss_stringify_acceptor(struct rpc_cred *
+ if (!ctx)
+ goto out;
+
+- acceptor = &ctx->gc_acceptor;
++ len = ctx->gc_acceptor.len;
++ rcu_read_unlock();
+
+ /* no point if there's no string */
+- if (!acceptor->len)
+- goto out;
+-
+- string = kmalloc(acceptor->len + 1, GFP_KERNEL);
++ if (!len)
++ return NULL;
++realloc:
++ string = kmalloc(len + 1, GFP_KERNEL);
+ if (!string)
++ return NULL;
++
++ rcu_read_lock();
++ ctx = rcu_dereference(gss_cred->gc_ctx);
++
++ /* did the ctx disappear or was it replaced by one with no acceptor? */
++ if (!ctx || !ctx->gc_acceptor.len) {
++ kfree(string);
++ string = NULL;
+ goto out;
++ }
++
++ acceptor = &ctx->gc_acceptor;
++
++ /*
++ * Did we find a new acceptor that's longer than the original? Allocate
++ * a longer buffer and try again.
++ */
++ if (len < acceptor->len) {
++ len = acceptor->len;
++ rcu_read_unlock();
++ kfree(string);
++ goto realloc;
++ }
+
+ memcpy(string, acceptor->data, acceptor->len);
+ string[acceptor->len] = '\0';
projects / thirdparty / kernel / stable-queue.git / commitdiff
