--- /dev/null
+From 56aeb07c914a616ab84357d34f8414a69b140cdf Mon Sep 17 00:00:00 2001
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Date: Thu, 4 Jan 2018 17:53:12 +0100
+Subject: ARM: dts: kirkwood: fix pin-muxing of MPP7 on OpenBlocks A7
+
+From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+
+commit 56aeb07c914a616ab84357d34f8414a69b140cdf upstream.
+
+MPP7 is currently muxed as "gpio", but this function doesn't exist for
+MPP7, only "gpo" is available. This causes the following error:
+
+kirkwood-pinctrl f1010000.pin-controller: unsupported function gpio on pin mpp7
+pinctrl core: failed to register map default (6): invalid type given
+kirkwood-pinctrl f1010000.pin-controller: error claiming hogs: -22
+kirkwood-pinctrl f1010000.pin-controller: could not claim hogs: -22
+kirkwood-pinctrl f1010000.pin-controller: unable to register pinctrl driver
+kirkwood-pinctrl: probe of f1010000.pin-controller failed with error -22
+
+So the pinctrl driver is not probed, all device drivers (including the
+UART driver) do a -EPROBE_DEFER, and therefore the system doesn't
+really boot (well, it boots, but with no UART, and no devices that
+require pin-muxing).
+
+Back when the Device Tree file for this board was introduced, the
+definition was already wrong. The pinctrl driver also always described
+as "gpo" this function for MPP7. However, between Linux 4.10 and 4.11,
+a hog pin failing to be muxed was turned from a simple warning to a
+hard error that caused the entire pinctrl driver probe to bail
+out. This is probably the result of commit 6118714275f0a ("pinctrl:
+core: Fix pinctrl_register_and_init() with pinctrl_enable()").
+
+This commit fixes the Device Tree to use the proper "gpo" function for
+MPP7, which fixes the boot of OpenBlocks A7, which was broken since
+Linux 4.11.
+
+Fixes: f24b56cbcd9d ("ARM: kirkwood: add support for OpenBlocks A7 platform")
+Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+Reviewed-by: Andrew Lunn <andrew@lunn.ch>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/boot/dts/kirkwood-openblocks_a7.dts | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
++++ b/arch/arm/boot/dts/kirkwood-openblocks_a7.dts
+@@ -53,7 +53,8 @@
+ };
+
+ pinctrl: pin-controller@10000 {
+- pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header>;
++ pinctrl-0 = <&pmx_dip_switches &pmx_gpio_header
++ &pmx_gpio_header_gpo>;
+ pinctrl-names = "default";
+
+ pmx_uart0: pmx-uart0 {
+@@ -85,11 +86,16 @@
+ * ground.
+ */
+ pmx_gpio_header: pmx-gpio-header {
+- marvell,pins = "mpp17", "mpp7", "mpp29", "mpp28",
++ marvell,pins = "mpp17", "mpp29", "mpp28",
+ "mpp35", "mpp34", "mpp40";
+ marvell,function = "gpio";
+ };
+
++ pmx_gpio_header_gpo: pxm-gpio-header-gpo {
++ marvell,pins = "mpp7";
++ marvell,function = "gpo";
++ };
++
+ pmx_gpio_init: pmx-init {
+ marvell,pins = "mpp38";
+ marvell,function = "gpio";
--- /dev/null
+From c13e7f313da33d1488355440f1a10feb1897480a Mon Sep 17 00:00:00 2001
+From: Maxime Ripard <maxime.ripard@free-electrons.com>
+Date: Fri, 19 Jan 2018 14:32:08 +0100
+Subject: ARM: sunxi_defconfig: Enable CMA
+
+From: Maxime Ripard <maxime.ripard@free-electrons.com>
+
+commit c13e7f313da33d1488355440f1a10feb1897480a upstream.
+
+The DRM driver most notably, but also out of tree drivers (for now) like
+the VPU or GPU drivers, are quite big consumers of large, contiguous memory
+buffers. However, the sunxi_defconfig doesn't enable CMA in order to
+mitigate that, which makes them almost unusable.
+
+Enable it to make sure it somewhat works.
+
+Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/configs/sunxi_defconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm/configs/sunxi_defconfig
++++ b/arch/arm/configs/sunxi_defconfig
+@@ -10,6 +10,7 @@ CONFIG_SMP=y
+ CONFIG_NR_CPUS=8
+ CONFIG_AEABI=y
+ CONFIG_HIGHMEM=y
++CONFIG_CMA=y
+ CONFIG_ARM_APPENDED_DTB=y
+ CONFIG_ARM_ATAG_DTB_COMPAT=y
+ CONFIG_CPU_FREQ=y
+@@ -33,6 +34,7 @@ CONFIG_CAN_SUN4I=y
+ # CONFIG_WIRELESS is not set
+ CONFIG_DEVTMPFS=y
+ CONFIG_DEVTMPFS_MOUNT=y
++CONFIG_DMA_CMA=y
+ CONFIG_BLK_DEV_SD=y
+ CONFIG_ATA=y
+ CONFIG_AHCI_SUNXI=y
--- /dev/null
+From e3af9f7c6ece29fdb7fe0aeb83ac5d3077a06edb Mon Sep 17 00:00:00 2001
+From: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Date: Tue, 25 Jul 2017 16:51:20 +0200
+Subject: ARM64: dts: marvell: armada-cp110: Fix clock resources for various node
+
+From: Gregory CLEMENT <gregory.clement@free-electrons.com>
+
+commit e3af9f7c6ece29fdb7fe0aeb83ac5d3077a06edb upstream.
+
+On the CP modules we found on Armada 7K/8K, many IP block actually also
+need a "functional" clock (from the bus). This patch add them which allows
+to fix some issues hanging the kernel:
+
+If Ethernet and sdhci driver are built as modules and sdhci was loaded
+first then the kernel hang.
+
+Fixes: bb16ea1742c8 ("mmc: sdhci-xenon: Fix clock resource by adding an optional bus clock")
+Reported-by: Riku Voipio <riku.voipio@linaro.org>
+Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 13 ++++++++-----
+ arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 9 ++++++---
+ 2 files changed, 14 insertions(+), 8 deletions(-)
+
+--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
++++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+@@ -63,8 +63,10 @@
+ cpm_ethernet: ethernet@0 {
+ compatible = "marvell,armada-7k-pp22";
+ reg = <0x0 0x100000>, <0x129000 0xb000>;
+- clocks = <&cpm_clk 1 3>, <&cpm_clk 1 9>, <&cpm_clk 1 5>;
+- clock-names = "pp_clk", "gop_clk", "mg_clk";
++ clocks = <&cpm_clk 1 3>, <&cpm_clk 1 9>,
++ <&cpm_clk 1 5>, <&cpm_clk 1 18>;
++ clock-names = "pp_clk", "gop_clk",
++ "mg_clk","axi_clk";
+ marvell,system-controller = <&cpm_syscon0>;
+ status = "disabled";
+ dma-coherent;
+@@ -114,7 +116,8 @@
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a200 0x10>;
+- clocks = <&cpm_clk 1 9>, <&cpm_clk 1 5>;
++ clocks = <&cpm_clk 1 9>, <&cpm_clk 1 5>,
++ <&cpm_clk 1 6>, <&cpm_clk 1 18>;
+ status = "disabled";
+ };
+
+@@ -295,8 +298,8 @@
+ compatible = "marvell,armada-cp110-sdhci";
+ reg = <0x780000 0x300>;
+ interrupts = <ICU_GRP_NSR 27 IRQ_TYPE_LEVEL_HIGH>;
+- clock-names = "core";
+- clocks = <&cpm_clk 1 4>;
++ clock-names = "core","axi";
++ clocks = <&cpm_clk 1 4>, <&cpm_clk 1 18>;
+ dma-coherent;
+ status = "disabled";
+ };
+--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
++++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+@@ -63,8 +63,10 @@
+ cps_ethernet: ethernet@0 {
+ compatible = "marvell,armada-7k-pp22";
+ reg = <0x0 0x100000>, <0x129000 0xb000>;
+- clocks = <&cps_clk 1 3>, <&cps_clk 1 9>, <&cps_clk 1 5>;
+- clock-names = "pp_clk", "gop_clk", "mg_clk";
++ clocks = <&cps_clk 1 3>, <&cps_clk 1 9>,
++ <&cps_clk 1 5>, <&cps_clk 1 18>;
++ clock-names = "pp_clk", "gop_clk",
++ "mg_clk", "axi_clk";
+ marvell,system-controller = <&cps_syscon0>;
+ status = "disabled";
+ dma-coherent;
+@@ -114,7 +116,8 @@
+ #size-cells = <0>;
+ compatible = "marvell,orion-mdio";
+ reg = <0x12a200 0x10>;
+- clocks = <&cps_clk 1 9>, <&cps_clk 1 5>;
++ clocks = <&cps_clk 1 9>, <&cps_clk 1 5>,
++ <&cps_clk 1 6>, <&cps_clk 1 18>;
+ status = "disabled";
+ };
+
--- /dev/null
+From 8cb68751c115d176ec851ca56ecfbb411568c9e8 Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+Date: Tue, 16 Jan 2018 19:30:14 +0100
+Subject: can: af_can: can_rcv(): replace WARN_ONCE by pr_warn_once
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+commit 8cb68751c115d176ec851ca56ecfbb411568c9e8 upstream.
+
+If an invalid CAN frame is received, from a driver or from a tun
+interface, a Kernel warning is generated.
+
+This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
+kernel, bootet with panic_on_warn, does not panic. A printk seems to be
+more appropriate here.
+
+Reported-by: syzbot+4386709c0c1284dca827@syzkaller.appspotmail.com
+Suggested-by: Dmitry Vyukov <dvyukov@google.com>
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/can/af_can.c | 18 +++++++-----------
+ 1 file changed, 7 insertions(+), 11 deletions(-)
+
+--- a/net/can/af_can.c
++++ b/net/can/af_can.c
+@@ -721,20 +721,16 @@ static int can_rcv(struct sk_buff *skb,
+ {
+ struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
+
+- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
+- skb->len != CAN_MTU ||
+- cfd->len > CAN_MAX_DLEN,
+- "PF_CAN: dropped non conform CAN skbuf: "
+- "dev type %d, len %d, datalen %d\n",
+- dev->type, skb->len, cfd->len))
+- goto drop;
++ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CAN_MTU ||
++ cfd->len > CAN_MAX_DLEN)) {
++ pr_warn_once("PF_CAN: dropped non conform CAN skbuf: dev type %d, len %d, datalen %d\n",
++ dev->type, skb->len, cfd->len);
++ kfree_skb(skb);
++ return NET_RX_DROP;
++ }
+
+ can_receive(skb, dev);
+ return NET_RX_SUCCESS;
+-
+-drop:
+- kfree_skb(skb);
+- return NET_RX_DROP;
+ }
+
+ static int canfd_rcv(struct sk_buff *skb, struct net_device *dev,
--- /dev/null
+From d4689846881d160a4d12a514e991a740bcb5d65a Mon Sep 17 00:00:00 2001
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+Date: Tue, 16 Jan 2018 19:30:14 +0100
+Subject: can: af_can: canfd_rcv(): replace WARN_ONCE by pr_warn_once
+
+From: Marc Kleine-Budde <mkl@pengutronix.de>
+
+commit d4689846881d160a4d12a514e991a740bcb5d65a upstream.
+
+If an invalid CANFD frame is received, from a driver or from a tun
+interface, a Kernel warning is generated.
+
+This patch replaces the WARN_ONCE by a simple pr_warn_once, so that a
+kernel, bootet with panic_on_warn, does not panic. A printk seems to be
+more appropriate here.
+
+Reported-by: syzbot+e3b775f40babeff6e68b@syzkaller.appspotmail.com
+Suggested-by: Dmitry Vyukov <dvyukov@google.com>
+Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/can/af_can.c | 18 +++++++-----------
+ 1 file changed, 7 insertions(+), 11 deletions(-)
+
+--- a/net/can/af_can.c
++++ b/net/can/af_can.c
+@@ -738,20 +738,16 @@ static int canfd_rcv(struct sk_buff *skb
+ {
+ struct canfd_frame *cfd = (struct canfd_frame *)skb->data;
+
+- if (WARN_ONCE(dev->type != ARPHRD_CAN ||
+- skb->len != CANFD_MTU ||
+- cfd->len > CANFD_MAX_DLEN,
+- "PF_CAN: dropped non conform CAN FD skbuf: "
+- "dev type %d, len %d, datalen %d\n",
+- dev->type, skb->len, cfd->len))
+- goto drop;
++ if (unlikely(dev->type != ARPHRD_CAN || skb->len != CANFD_MTU ||
++ cfd->len > CANFD_MAX_DLEN)) {
++ pr_warn_once("PF_CAN: dropped non conform CAN FD skbuf: dev type %d, len %d, datalen %d\n",
++ dev->type, skb->len, cfd->len);
++ kfree_skb(skb);
++ return NET_RX_DROP;
++ }
+
+ can_receive(skb, dev);
+ return NET_RX_SUCCESS;
+-
+-drop:
+- kfree_skb(skb);
+- return NET_RX_DROP;
+ }
+
+ /*
--- /dev/null
+From d8a243af1a68395e07ac85384a2740d4134c67f4 Mon Sep 17 00:00:00 2001
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+Date: Mon, 15 Jan 2018 16:31:19 +0100
+Subject: can: peak: fix potential bug in packet fragmentation
+
+From: Stephane Grosjean <s.grosjean@peak-system.com>
+
+commit d8a243af1a68395e07ac85384a2740d4134c67f4 upstream.
+
+In some rare conditions when running one PEAK USB-FD interface over
+a non high-speed USB controller, one useless USB fragment might be sent.
+This patch fixes the way a USB command is fragmented when its length is
+greater than 64 bytes and when the underlying USB controller is not a
+high-speed one.
+
+Signed-off-by: Stephane Grosjean <s.grosjean@peak-system.com>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/can/usb/peak_usb/pcan_usb_fd.c | 21 +++++++++++----------
+ 1 file changed, 11 insertions(+), 10 deletions(-)
+
+--- a/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
++++ b/drivers/net/can/usb/peak_usb/pcan_usb_fd.c
+@@ -184,7 +184,7 @@ static int pcan_usb_fd_send_cmd(struct p
+ void *cmd_head = pcan_usb_fd_cmd_buffer(dev);
+ int err = 0;
+ u8 *packet_ptr;
+- int i, n = 1, packet_len;
++ int packet_len;
+ ptrdiff_t cmd_len;
+
+ /* usb device unregistered? */
+@@ -201,17 +201,13 @@ static int pcan_usb_fd_send_cmd(struct p
+ }
+
+ packet_ptr = cmd_head;
++ packet_len = cmd_len;
+
+ /* firmware is not able to re-assemble 512 bytes buffer in full-speed */
+- if ((dev->udev->speed != USB_SPEED_HIGH) &&
+- (cmd_len > PCAN_UFD_LOSPD_PKT_SIZE)) {
+- packet_len = PCAN_UFD_LOSPD_PKT_SIZE;
+- n += cmd_len / packet_len;
+- } else {
+- packet_len = cmd_len;
+- }
++ if (unlikely(dev->udev->speed != USB_SPEED_HIGH))
++ packet_len = min(packet_len, PCAN_UFD_LOSPD_PKT_SIZE);
+
+- for (i = 0; i < n; i++) {
++ do {
+ err = usb_bulk_msg(dev->udev,
+ usb_sndbulkpipe(dev->udev,
+ PCAN_USBPRO_EP_CMDOUT),
+@@ -224,7 +220,12 @@ static int pcan_usb_fd_send_cmd(struct p
+ }
+
+ packet_ptr += packet_len;
+- }
++ cmd_len -= packet_len;
++
++ if (cmd_len < PCAN_UFD_LOSPD_PKT_SIZE)
++ packet_len = cmd_len;
++
++ } while (packet_len > 0);
+
+ return err;
+ }
--- /dev/null
+From bc68d0a43560e950850fc69b58f0f8254b28f6d6 Mon Sep 17 00:00:00 2001
+From: Joe Thornber <thornber@redhat.com>
+Date: Wed, 20 Dec 2017 09:56:06 +0000
+Subject: dm btree: fix serious bug in btree_split_beneath()
+
+From: Joe Thornber <thornber@redhat.com>
+
+commit bc68d0a43560e950850fc69b58f0f8254b28f6d6 upstream.
+
+When inserting a new key/value pair into a btree we walk down the spine of
+btree nodes performing the following 2 operations:
+
+ i) space for a new entry
+ ii) adjusting the first key entry if the new key is lower than any in the node.
+
+If the _root_ node is full, the function btree_split_beneath() allocates 2 new
+nodes, and redistibutes the root nodes entries between them. The root node is
+left with 2 entries corresponding to the 2 new nodes.
+
+btree_split_beneath() then adjusts the spine to point to one of the two new
+children. This means the first key is never adjusted if the new key was lower,
+ie. operation (ii) gets missed out. This can result in the new key being
+'lost' for a period; until another low valued key is inserted that will uncover
+it.
+
+This is a serious bug, and quite hard to make trigger in normal use. A
+reproducing test case ("thin create devices-in-reverse-order") is
+available as part of the thin-provision-tools project:
+ https://github.com/jthornber/thin-provisioning-tools/blob/master/functional-tests/device-mapper/dm-tests.scm#L593
+
+Fix the issue by changing btree_split_beneath() so it no longer adjusts
+the spine. Instead it unlocks both the new nodes, and lets the main
+loop in btree_insert_raw() relock the appropriate one and make any
+neccessary adjustments.
+
+Reported-by: Monty Pavel <monty_pavel@sina.com>
+Signed-off-by: Joe Thornber <thornber@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.c | 19 ++-----------------
+ 1 file changed, 2 insertions(+), 17 deletions(-)
+
+--- a/drivers/md/persistent-data/dm-btree.c
++++ b/drivers/md/persistent-data/dm-btree.c
+@@ -683,23 +683,8 @@ static int btree_split_beneath(struct sh
+ pn->keys[1] = rn->keys[0];
+ memcpy_disk(value_ptr(pn, 1), &val, sizeof(__le64));
+
+- /*
+- * rejig the spine. This is ugly, since it knows too
+- * much about the spine
+- */
+- if (s->nodes[0] != new_parent) {
+- unlock_block(s->info, s->nodes[0]);
+- s->nodes[0] = new_parent;
+- }
+- if (key < le64_to_cpu(rn->keys[0])) {
+- unlock_block(s->info, right);
+- s->nodes[1] = left;
+- } else {
+- unlock_block(s->info, left);
+- s->nodes[1] = right;
+- }
+- s->count = 2;
+-
++ unlock_block(s->info, left);
++ unlock_block(s->info, right);
+ return 0;
+ }
+
--- /dev/null
+From 27c7003697fc2c78f965984aa224ef26cd6b2949 Mon Sep 17 00:00:00 2001
+From: Milan Broz <gmazyland@gmail.com>
+Date: Wed, 3 Jan 2018 22:48:59 +0100
+Subject: dm crypt: fix crash by adding missing check for auth key size
+
+From: Milan Broz <gmazyland@gmail.com>
+
+commit 27c7003697fc2c78f965984aa224ef26cd6b2949 upstream.
+
+If dm-crypt uses authenticated mode with separate MAC, there are two
+concatenated part of the key structure - key(s) for encryption and
+authentication key.
+
+Add a missing check for authenticated key length. If this key length is
+smaller than actually provided key, dm-crypt now properly fails instead
+of crashing.
+
+Fixes: ef43aa3806 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
+Reported-by: Salah Coronya <salahx@yahoo.com>
+Signed-off-by: Milan Broz <gmazyland@gmail.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-crypt.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-crypt.c
++++ b/drivers/md/dm-crypt.c
+@@ -1954,10 +1954,15 @@ static int crypt_setkey(struct crypt_con
+ /* Ignore extra keys (which are used for IV etc) */
+ subkey_size = crypt_subkey_size(cc);
+
+- if (crypt_integrity_hmac(cc))
++ if (crypt_integrity_hmac(cc)) {
++ if (subkey_size < cc->key_mac_size)
++ return -EINVAL;
++
+ crypt_copy_authenckey(cc->authenc_key, cc->key,
+ subkey_size - cc->key_mac_size,
+ cc->key_mac_size);
++ }
++
+ for (i = 0; i < cc->tfms_count; i++) {
+ if (crypt_integrity_hmac(cc))
+ r = crypto_aead_setkey(cc->cipher_tfm.tfms_aead[i],
--- /dev/null
+From 3cc2e57c4beabcbbaa46e1ac6d77ca8276a4a42d Mon Sep 17 00:00:00 2001
+From: Wei Yongjun <weiyongjun1@huawei.com>
+Date: Wed, 17 Jan 2018 11:24:26 +0000
+Subject: dm crypt: fix error return code in crypt_ctr()
+
+From: Wei Yongjun <weiyongjun1@huawei.com>
+
+commit 3cc2e57c4beabcbbaa46e1ac6d77ca8276a4a42d upstream.
+
+Fix to return error code -ENOMEM from the mempool_create_kmalloc_pool()
+error handling case instead of 0, as done elsewhere in this function.
+
+Fixes: ef43aa38063a6 ("dm crypt: add cryptographic data integrity protection (authenticated encryption)")
+Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-crypt.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/md/dm-crypt.c
++++ b/drivers/md/dm-crypt.c
+@@ -2746,6 +2746,7 @@ static int crypt_ctr(struct dm_target *t
+ cc->tag_pool_max_sectors * cc->on_disk_tag_size);
+ if (!cc->tag_pool) {
+ ti->error = "Cannot allocate integrity tags mempool";
++ ret = -ENOMEM;
+ goto bad;
+ }
+
--- /dev/null
+From dc94902bde1e158cd19c4deab208e5d6eb382a44 Mon Sep 17 00:00:00 2001
+From: Ondrej Kozina <okozina@redhat.com>
+Date: Fri, 12 Jan 2018 16:30:32 +0100
+Subject: dm crypt: wipe kernel key copy after IV initialization
+
+From: Ondrej Kozina <okozina@redhat.com>
+
+commit dc94902bde1e158cd19c4deab208e5d6eb382a44 upstream.
+
+Loading key via kernel keyring service erases the internal
+key copy immediately after we pass it in crypto layer. This is
+wrong because IV is initialized later and we use wrong key
+for the initialization (instead of real key there's just zeroed
+block).
+
+The bug may cause data corruption if key is loaded via kernel keyring
+service first and later same crypt device is reactivated using exactly
+same key in hexbyte representation, or vice versa. The bug (and fix)
+affects only ciphers using following IVs: essiv, lmk and tcw.
+
+Fixes: c538f6ec9f56 ("dm crypt: add ability to use keys from the kernel key retention service")
+Signed-off-by: Ondrej Kozina <okozina@redhat.com>
+Reviewed-by: Milan Broz <gmazyland@gmail.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-crypt.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/drivers/md/dm-crypt.c
++++ b/drivers/md/dm-crypt.c
+@@ -2058,9 +2058,6 @@ static int crypt_set_keyring_key(struct
+
+ ret = crypt_setkey(cc);
+
+- /* wipe the kernel key payload copy in each case */
+- memset(cc->key, 0, cc->key_size * sizeof(u8));
+-
+ if (!ret) {
+ set_bit(DM_CRYPT_KEY_VALID, &cc->flags);
+ kzfree(cc->key_string);
+@@ -2528,6 +2525,10 @@ static int crypt_ctr_cipher(struct dm_ta
+ }
+ }
+
++ /* wipe the kernel key payload copy */
++ if (cc->key_string)
++ memset(cc->key, 0, cc->key_size * sizeof(u8));
++
+ return ret;
+ }
+
+@@ -2966,6 +2967,9 @@ static int crypt_message(struct dm_targe
+ return ret;
+ if (cc->iv_gen_ops && cc->iv_gen_ops->init)
+ ret = cc->iv_gen_ops->init(cc);
++ /* wipe the kernel key payload copy */
++ if (cc->key_string)
++ memset(cc->key, 0, cc->key_size * sizeof(u8));
+ return ret;
+ }
+ if (argc == 2 && !strcasecmp(argv[1], "wipe")) {
+@@ -3012,7 +3016,7 @@ static void crypt_io_hints(struct dm_tar
+
+ static struct target_type crypt_target = {
+ .name = "crypt",
+- .version = {1, 18, 0},
++ .version = {1, 18, 1},
+ .module = THIS_MODULE,
+ .ctr = crypt_ctr,
+ .dtr = crypt_dtr,
--- /dev/null
+From 717f4b1c52135f279112df82583e0c77e80f90de Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Wed, 10 Jan 2018 09:32:47 -0500
+Subject: dm integrity: don't store cipher request on the stack
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 717f4b1c52135f279112df82583e0c77e80f90de upstream.
+
+Some asynchronous cipher implementations may use DMA. The stack may
+be mapped in the vmalloc area that doesn't support DMA. Therefore,
+the cipher request and initialization vector shouldn't be on the
+stack.
+
+Fix this by allocating the request and iv with kmalloc.
+
+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-integrity.c | 49 ++++++++++++++++++++++++++++++++++------------
+ 1 file changed, 37 insertions(+), 12 deletions(-)
+
+--- a/drivers/md/dm-integrity.c
++++ b/drivers/md/dm-integrity.c
+@@ -2558,7 +2558,8 @@ static int create_journal(struct dm_inte
+ int r = 0;
+ unsigned i;
+ __u64 journal_pages, journal_desc_size, journal_tree_size;
+- unsigned char *crypt_data = NULL;
++ unsigned char *crypt_data = NULL, *crypt_iv = NULL;
++ struct skcipher_request *req = NULL;
+
+ ic->commit_ids[0] = cpu_to_le64(0x1111111111111111ULL);
+ ic->commit_ids[1] = cpu_to_le64(0x2222222222222222ULL);
+@@ -2616,9 +2617,20 @@ static int create_journal(struct dm_inte
+
+ if (blocksize == 1) {
+ struct scatterlist *sg;
+- SKCIPHER_REQUEST_ON_STACK(req, ic->journal_crypt);
+- unsigned char iv[ivsize];
+- skcipher_request_set_tfm(req, ic->journal_crypt);
++
++ req = skcipher_request_alloc(ic->journal_crypt, GFP_KERNEL);
++ if (!req) {
++ *error = "Could not allocate crypt request";
++ r = -ENOMEM;
++ goto bad;
++ }
++
++ crypt_iv = kmalloc(ivsize, GFP_KERNEL);
++ if (!crypt_iv) {
++ *error = "Could not allocate iv";
++ r = -ENOMEM;
++ goto bad;
++ }
+
+ ic->journal_xor = dm_integrity_alloc_page_list(ic);
+ if (!ic->journal_xor) {
+@@ -2640,9 +2652,9 @@ static int create_journal(struct dm_inte
+ sg_set_buf(&sg[i], va, PAGE_SIZE);
+ }
+ sg_set_buf(&sg[i], &ic->commit_ids, sizeof ic->commit_ids);
+- memset(iv, 0x00, ivsize);
++ memset(crypt_iv, 0x00, ivsize);
+
+- skcipher_request_set_crypt(req, sg, sg, PAGE_SIZE * ic->journal_pages + sizeof ic->commit_ids, iv);
++ skcipher_request_set_crypt(req, sg, sg, PAGE_SIZE * ic->journal_pages + sizeof ic->commit_ids, crypt_iv);
+ init_completion(&comp.comp);
+ comp.in_flight = (atomic_t)ATOMIC_INIT(1);
+ if (do_crypt(true, req, &comp))
+@@ -2658,10 +2670,22 @@ static int create_journal(struct dm_inte
+ crypto_free_skcipher(ic->journal_crypt);
+ ic->journal_crypt = NULL;
+ } else {
+- SKCIPHER_REQUEST_ON_STACK(req, ic->journal_crypt);
+- unsigned char iv[ivsize];
+ unsigned crypt_len = roundup(ivsize, blocksize);
+
++ req = skcipher_request_alloc(ic->journal_crypt, GFP_KERNEL);
++ if (!req) {
++ *error = "Could not allocate crypt request";
++ r = -ENOMEM;
++ goto bad;
++ }
++
++ crypt_iv = kmalloc(ivsize, GFP_KERNEL);
++ if (!crypt_iv) {
++ *error = "Could not allocate iv";
++ r = -ENOMEM;
++ goto bad;
++ }
++
+ crypt_data = kmalloc(crypt_len, GFP_KERNEL);
+ if (!crypt_data) {
+ *error = "Unable to allocate crypt data";
+@@ -2669,8 +2693,6 @@ static int create_journal(struct dm_inte
+ goto bad;
+ }
+
+- skcipher_request_set_tfm(req, ic->journal_crypt);
+-
+ ic->journal_scatterlist = dm_integrity_alloc_journal_scatterlist(ic, ic->journal);
+ if (!ic->journal_scatterlist) {
+ *error = "Unable to allocate sg list";
+@@ -2694,12 +2716,12 @@ static int create_journal(struct dm_inte
+ struct skcipher_request *section_req;
+ __u32 section_le = cpu_to_le32(i);
+
+- memset(iv, 0x00, ivsize);
++ memset(crypt_iv, 0x00, ivsize);
+ memset(crypt_data, 0x00, crypt_len);
+ memcpy(crypt_data, §ion_le, min((size_t)crypt_len, sizeof(section_le)));
+
+ sg_init_one(&sg, crypt_data, crypt_len);
+- skcipher_request_set_crypt(req, &sg, &sg, crypt_len, iv);
++ skcipher_request_set_crypt(req, &sg, &sg, crypt_len, crypt_iv);
+ init_completion(&comp.comp);
+ comp.in_flight = (atomic_t)ATOMIC_INIT(1);
+ if (do_crypt(true, req, &comp))
+@@ -2757,6 +2779,9 @@ retest_commit_id:
+ }
+ bad:
+ kfree(crypt_data);
++ kfree(crypt_iv);
++ skcipher_request_free(req);
++
+ return r;
+ }
+
--- /dev/null
+From 490ae017f54e55bde382d45ea24bddfb6d1a0aaf Mon Sep 17 00:00:00 2001
+From: Dennis Yang <dennisyang@qnap.com>
+Date: Tue, 12 Dec 2017 18:21:40 +0800
+Subject: dm thin metadata: THIN_MAX_CONCURRENT_LOCKS should be 6
+
+From: Dennis Yang <dennisyang@qnap.com>
+
+commit 490ae017f54e55bde382d45ea24bddfb6d1a0aaf upstream.
+
+For btree removal, there is a corner case that a single thread
+could takes 6 locks which is more than THIN_MAX_CONCURRENT_LOCKS(5)
+and leads to deadlock.
+
+A btree removal might eventually call
+rebalance_children()->rebalance3() to rebalance entries of three
+neighbor child nodes when shadow_spine has already acquired two
+write locks. In rebalance3(), it tries to shadow and acquire the
+write locks of all three child nodes. However, shadowing a child
+node requires acquiring a read lock of the original child node and
+a write lock of the new block. Although the read lock will be
+released after block shadowing, shadowing the third child node
+in rebalance3() could still take the sixth lock.
+(2 write locks for shadow_spine +
+ 2 write locks for the first two child nodes's shadow +
+ 1 write lock for the last child node's shadow +
+ 1 read lock for the last child node)
+
+Signed-off-by: Dennis Yang <dennisyang@qnap.com>
+Acked-by: Joe Thornber <thornber@redhat.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-thin-metadata.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/drivers/md/dm-thin-metadata.c
++++ b/drivers/md/dm-thin-metadata.c
+@@ -80,10 +80,14 @@
+ #define SECTOR_TO_BLOCK_SHIFT 3
+
+ /*
++ * For btree insert:
+ * 3 for btree insert +
+ * 2 for btree lookup used within space map
++ * For btree remove:
++ * 2 for shadow spine +
++ * 4 for rebalance 3 child node
+ */
+-#define THIN_MAX_CONCURRENT_LOCKS 5
++#define THIN_MAX_CONCURRENT_LOCKS 6
+
+ /* This should be plenty */
+ #define SPACE_MAP_ROOT_SIZE 128
--- /dev/null
+From 8a510a5c75261ba0ec39155326982aa786541e29 Mon Sep 17 00:00:00 2001
+From: Rob Clark <rclark@redhat.com>
+Date: Wed, 17 Jan 2018 10:16:20 -0500
+Subject: drm/vmwgfx: fix memory corruption with legacy/sou connectors
+
+From: Rob Clark <rclark@redhat.com>
+
+commit 8a510a5c75261ba0ec39155326982aa786541e29 upstream.
+
+It looks like in all cases 'struct vmw_connector_state' is used. But
+only in stdu connectors, was atomic_{duplicate,destroy}_state() properly
+subclassed. Leading to writes beyond the end of the allocated connector
+state block and all sorts of fun memory corruption related crashes.
+
+Fixes: d7721ca71126 "drm/vmwgfx: Connector atomic state"
+Signed-off-by: Rob Clark <rclark@redhat.com>
+Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ++--
+ drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ++--
+ 2 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+@@ -266,8 +266,8 @@ static const struct drm_connector_funcs
+ .set_property = vmw_du_connector_set_property,
+ .destroy = vmw_ldu_connector_destroy,
+ .reset = vmw_du_connector_reset,
+- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
++ .atomic_duplicate_state = vmw_du_connector_duplicate_state,
++ .atomic_destroy_state = vmw_du_connector_destroy_state,
+ .atomic_set_property = vmw_du_connector_atomic_set_property,
+ .atomic_get_property = vmw_du_connector_atomic_get_property,
+ };
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+@@ -420,8 +420,8 @@ static const struct drm_connector_funcs
+ .set_property = vmw_du_connector_set_property,
+ .destroy = vmw_sou_connector_destroy,
+ .reset = vmw_du_connector_reset,
+- .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+- .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
++ .atomic_duplicate_state = vmw_du_connector_duplicate_state,
++ .atomic_destroy_state = vmw_du_connector_destroy_state,
+ .atomic_set_property = vmw_du_connector_atomic_set_property,
+ .atomic_get_property = vmw_du_connector_atomic_get_property,
+ };
--- /dev/null
+From 89c6efa61f5709327ecfa24bff18e57a4e80c7fa Mon Sep 17 00:00:00 2001
+From: Jeremy Compostella <jeremy.compostella@intel.com>
+Date: Wed, 15 Nov 2017 12:31:44 -0700
+Subject: i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA
+
+From: Jeremy Compostella <jeremy.compostella@intel.com>
+
+commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.
+
+On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
+greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
+data out of the msgbuf1 array boundary.
+
+It is possible from a user application to run into that issue by
+calling the I2C_SMBUS ioctl with data.block[0] greater than
+I2C_SMBUS_BLOCK_MAX + 1.
+
+This patch makes the code compliant with
+Documentation/i2c/dev-interface by raising an error when the requested
+size is larger than 32 bytes.
+
+Call Trace:
+ [<ffffffff8139f695>] dump_stack+0x67/0x92
+ [<ffffffff811802a4>] panic+0xc5/0x1eb
+ [<ffffffff810ecb5f>] ? vprintk_default+0x1f/0x30
+ [<ffffffff817456d3>] ? i2cdev_ioctl_smbus+0x303/0x320
+ [<ffffffff8109a68b>] __stack_chk_fail+0x1b/0x20
+ [<ffffffff817456d3>] i2cdev_ioctl_smbus+0x303/0x320
+ [<ffffffff81745aed>] i2cdev_ioctl+0x4d/0x1e0
+ [<ffffffff811f761a>] do_vfs_ioctl+0x2ba/0x490
+ [<ffffffff81336e43>] ? security_file_ioctl+0x43/0x60
+ [<ffffffff811f7869>] SyS_ioctl+0x79/0x90
+ [<ffffffff81a22e97>] entry_SYSCALL_64_fastpath+0x12/0x6a
+
+Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
+Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/i2c/i2c-core-smbus.c | 13 +++++++------
+ 1 file changed, 7 insertions(+), 6 deletions(-)
+
+--- a/drivers/i2c/i2c-core-smbus.c
++++ b/drivers/i2c/i2c-core-smbus.c
+@@ -396,16 +396,17 @@ static s32 i2c_smbus_xfer_emulated(struc
+ the underlying bus driver */
+ break;
+ case I2C_SMBUS_I2C_BLOCK_DATA:
++ if (data->block[0] > I2C_SMBUS_BLOCK_MAX) {
++ dev_err(&adapter->dev, "Invalid block %s size %d\n",
++ read_write == I2C_SMBUS_READ ? "read" : "write",
++ data->block[0]);
++ return -EINVAL;
++ }
++
+ if (read_write == I2C_SMBUS_READ) {
+ msg[1].len = data->block[0];
+ } else {
+ msg[0].len = data->block[0] + 1;
+- if (msg[0].len > I2C_SMBUS_BLOCK_MAX + 1) {
+- dev_err(&adapter->dev,
+- "Invalid block write size %d\n",
+- data->block[0]);
+- return -EINVAL;
+- }
+ for (i = 1; i <= data->block[0]; i++)
+ msgbuf0[i] = data->block[i];
+ }
--- /dev/null
+From 906bf7daa0618d0ef39f4872ca42218c29a3631f Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Jan 2018 17:20:18 -0800
+Subject: Input: 88pm860x-ts - fix child-node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 906bf7daa0618d0ef39f4872ca42218c29a3631f upstream.
+
+Fix child node-lookup during probe, which ended up searching the whole
+device tree depth-first starting at parent rather than just matching on
+its children.
+
+To make things worse, the parent node was prematurely freed, while the
+child node was leaked.
+
+Fixes: 2e57d56747e6 ("mfd: 88pm860x: Device tree support")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/touchscreen/88pm860x-ts.c | 16 ++++++++++++----
+ 1 file changed, 12 insertions(+), 4 deletions(-)
+
+--- a/drivers/input/touchscreen/88pm860x-ts.c
++++ b/drivers/input/touchscreen/88pm860x-ts.c
+@@ -126,7 +126,7 @@ static int pm860x_touch_dt_init(struct p
+ int data, n, ret;
+ if (!np)
+ return -ENODEV;
+- np = of_find_node_by_name(np, "touch");
++ np = of_get_child_by_name(np, "touch");
+ if (!np) {
+ dev_err(&pdev->dev, "Can't find touch node\n");
+ return -EINVAL;
+@@ -144,13 +144,13 @@ static int pm860x_touch_dt_init(struct p
+ if (data) {
+ ret = pm860x_reg_write(i2c, PM8607_GPADC_MISC1, data);
+ if (ret < 0)
+- return -EINVAL;
++ goto err_put_node;
+ }
+ /* set tsi prebias time */
+ if (!of_property_read_u32(np, "marvell,88pm860x-tsi-prebias", &data)) {
+ ret = pm860x_reg_write(i2c, PM8607_TSI_PREBIAS, data);
+ if (ret < 0)
+- return -EINVAL;
++ goto err_put_node;
+ }
+ /* set prebias & prechg time of pen detect */
+ data = 0;
+@@ -161,10 +161,18 @@ static int pm860x_touch_dt_init(struct p
+ if (data) {
+ ret = pm860x_reg_write(i2c, PM8607_PD_PREBIAS, data);
+ if (ret < 0)
+- return -EINVAL;
++ goto err_put_node;
+ }
+ of_property_read_u32(np, "marvell,88pm860x-resistor-X", res_x);
++
++ of_node_put(np);
++
+ return 0;
++
++err_put_node:
++ of_node_put(np);
++
++ return -EINVAL;
+ }
+ #else
+ #define pm860x_touch_dt_init(x, y, z) (-1)
--- /dev/null
+From 4d94e776bd29670f01befa27e12df784fa05fa2e Mon Sep 17 00:00:00 2001
+From: Nir Perry <nirperry@gmail.com>
+Date: Thu, 11 Jan 2018 23:43:26 -0800
+Subject: Input: ALPS - fix multi-touch decoding on SS4 plus touchpads
+
+From: Nir Perry <nirperry@gmail.com>
+
+commit 4d94e776bd29670f01befa27e12df784fa05fa2e upstream.
+
+The fix for handling two-finger scroll (i4a646580f793 - "Input: ALPS -
+fix two-finger scroll breakage in right side on ALPS touchpad")
+introduced a minor "typo" that broke decoding of multi-touch events are
+decoded on some ALPS touchpads. For example, tapping with three-fingers
+can no longer be used to emulate middle-mouse-button (the kernel doesn't
+recognize this as the proper event, and doesn't report it correctly to
+userspace). This affects touchpads that use SS4 "plus" protocol
+variant, like those found on Dell E7270 & E7470 laptops (tested on
+E7270).
+
+First, probably the code in alps_decode_ss4_v2() for case
+SS4_PACKET_ID_MULTI used inconsistent indices to "f->mt[]". You can see
+0 & 1 are used for the "if" part but 2 & 3 are used for the "else" part.
+
+Second, in the previous patch, new macros were introduced to decode X
+coordinates specific to the SS4 "plus" variant, but the macro to
+define the maximum X value wasn't changed accordingly. The macros to
+decode X values for "plus" variant are effectively shifted right by 1
+bit, but the max wasn't shifted too. This causes the driver to
+incorrectly handle "no data" cases, which also interfered with how
+multi-touch was handled.
+
+Fixes: 4a646580f793 ("Input: ALPS - fix two-finger scroll breakage...")
+Signed-off-by: Nir Perry <nirperry@gmail.com>
+Reviewed-by: Masaki Ota <masaki.ota@jp.alps.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/mouse/alps.c | 23 +++++++++++++----------
+ drivers/input/mouse/alps.h | 10 ++++++----
+ 2 files changed, 19 insertions(+), 14 deletions(-)
+
+--- a/drivers/input/mouse/alps.c
++++ b/drivers/input/mouse/alps.c
+@@ -1250,29 +1250,32 @@ static int alps_decode_ss4_v2(struct alp
+ case SS4_PACKET_ID_MULTI:
+ if (priv->flags & ALPS_BUTTONPAD) {
+ if (IS_SS4PLUS_DEV(priv->dev_id)) {
+- f->mt[0].x = SS4_PLUS_BTL_MF_X_V2(p, 0);
+- f->mt[1].x = SS4_PLUS_BTL_MF_X_V2(p, 1);
++ f->mt[2].x = SS4_PLUS_BTL_MF_X_V2(p, 0);
++ f->mt[3].x = SS4_PLUS_BTL_MF_X_V2(p, 1);
++ no_data_x = SS4_PLUS_MFPACKET_NO_AX_BL;
+ } else {
+ f->mt[2].x = SS4_BTL_MF_X_V2(p, 0);
+ f->mt[3].x = SS4_BTL_MF_X_V2(p, 1);
++ no_data_x = SS4_MFPACKET_NO_AX_BL;
+ }
++ no_data_y = SS4_MFPACKET_NO_AY_BL;
+
+ f->mt[2].y = SS4_BTL_MF_Y_V2(p, 0);
+ f->mt[3].y = SS4_BTL_MF_Y_V2(p, 1);
+- no_data_x = SS4_MFPACKET_NO_AX_BL;
+- no_data_y = SS4_MFPACKET_NO_AY_BL;
+ } else {
+ if (IS_SS4PLUS_DEV(priv->dev_id)) {
+- f->mt[0].x = SS4_PLUS_STD_MF_X_V2(p, 0);
+- f->mt[1].x = SS4_PLUS_STD_MF_X_V2(p, 1);
++ f->mt[2].x = SS4_PLUS_STD_MF_X_V2(p, 0);
++ f->mt[3].x = SS4_PLUS_STD_MF_X_V2(p, 1);
++ no_data_x = SS4_PLUS_MFPACKET_NO_AX;
+ } else {
+- f->mt[0].x = SS4_STD_MF_X_V2(p, 0);
+- f->mt[1].x = SS4_STD_MF_X_V2(p, 1);
++ f->mt[2].x = SS4_STD_MF_X_V2(p, 0);
++ f->mt[3].x = SS4_STD_MF_X_V2(p, 1);
++ no_data_x = SS4_MFPACKET_NO_AX;
+ }
++ no_data_y = SS4_MFPACKET_NO_AY;
++
+ f->mt[2].y = SS4_STD_MF_Y_V2(p, 0);
+ f->mt[3].y = SS4_STD_MF_Y_V2(p, 1);
+- no_data_x = SS4_MFPACKET_NO_AX;
+- no_data_y = SS4_MFPACKET_NO_AY;
+ }
+
+ f->first_mp = 0;
+--- a/drivers/input/mouse/alps.h
++++ b/drivers/input/mouse/alps.h
+@@ -141,10 +141,12 @@ enum SS4_PACKET_ID {
+ #define SS4_TS_Z_V2(_b) (s8)(_b[4] & 0x7F)
+
+
+-#define SS4_MFPACKET_NO_AX 8160 /* X-Coordinate value */
+-#define SS4_MFPACKET_NO_AY 4080 /* Y-Coordinate value */
+-#define SS4_MFPACKET_NO_AX_BL 8176 /* Buttonless X-Coordinate value */
+-#define SS4_MFPACKET_NO_AY_BL 4088 /* Buttonless Y-Coordinate value */
++#define SS4_MFPACKET_NO_AX 8160 /* X-Coordinate value */
++#define SS4_MFPACKET_NO_AY 4080 /* Y-Coordinate value */
++#define SS4_MFPACKET_NO_AX_BL 8176 /* Buttonless X-Coord value */
++#define SS4_MFPACKET_NO_AY_BL 4088 /* Buttonless Y-Coord value */
++#define SS4_PLUS_MFPACKET_NO_AX 4080 /* SS4 PLUS, X */
++#define SS4_PLUS_MFPACKET_NO_AX_BL 4088 /* Buttonless SS4 PLUS, X */
+
+ /*
+ * enum V7_PACKET_ID - defines the packet type for V7
--- /dev/null
+From 55edde9fff1ae4114c893c572e641620c76c9c21 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <nick.desaulniers@gmail.com>
+Date: Thu, 18 Jan 2018 11:36:41 -0800
+Subject: Input: synaptics-rmi4 - prevent UAF reported by KASAN
+
+From: Nick Desaulniers <nick.desaulniers@gmail.com>
+
+commit 55edde9fff1ae4114c893c572e641620c76c9c21 upstream.
+
+KASAN found a UAF due to dangling pointer. As the report below says,
+rmi_f11_attention() accesses drvdata->attn_data.data, which was freed in
+rmi_irq_fn.
+
+[ 311.424062] BUG: KASAN: use-after-free in rmi_f11_attention+0x526/0x5e0 [rmi_core]
+[ 311.424067] Read of size 27 at addr ffff88041fd610db by task irq/131-i2c_hid/1162
+[ 311.424075] CPU: 0 PID: 1162 Comm: irq/131-i2c_hid Not tainted 4.15.0-rc8+ #2
+[ 311.424076] Hardware name: Razer Blade Stealth/Razer, BIOS 6.05 01/26/2017
+[ 311.424078] Call Trace:
+[ 311.424086] dump_stack+0xae/0x12d
+[ 311.424090] ? _atomic_dec_and_lock+0x103/0x103
+[ 311.424094] ? show_regs_print_info+0xa/0xa
+[ 311.424099] ? input_handle_event+0x10b/0x810
+[ 311.424104] print_address_description+0x65/0x229
+[ 311.424108] kasan_report.cold.5+0xa7/0x281
+[ 311.424117] rmi_f11_attention+0x526/0x5e0 [rmi_core]
+[ 311.424123] ? memcpy+0x1f/0x50
+[ 311.424132] ? rmi_f11_attention+0x526/0x5e0 [rmi_core]
+[ 311.424143] ? rmi_f11_probe+0x1e20/0x1e20 [rmi_core]
+[ 311.424153] ? rmi_process_interrupt_requests+0x220/0x2a0 [rmi_core]
+[ 311.424163] ? rmi_irq_fn+0x22c/0x270 [rmi_core]
+[ 311.424173] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
+[ 311.424177] ? free_irq+0xa0/0xa0
+[ 311.424180] ? irq_finalize_oneshot.part.39+0xeb/0x180
+[ 311.424190] ? rmi_process_interrupt_requests+0x2a0/0x2a0 [rmi_core]
+[ 311.424193] ? irq_thread_fn+0x3d/0x80
+[ 311.424197] ? irq_finalize_oneshot.part.39+0x180/0x180
+[ 311.424200] ? irq_thread+0x21d/0x290
+[ 311.424203] ? irq_thread_check_affinity+0x170/0x170
+[ 311.424207] ? remove_wait_queue+0x150/0x150
+[ 311.424212] ? kasan_unpoison_shadow+0x30/0x40
+[ 311.424214] ? __init_waitqueue_head+0xa0/0xd0
+[ 311.424218] ? task_non_contending.cold.55+0x18/0x18
+[ 311.424221] ? irq_forced_thread_fn+0xa0/0xa0
+[ 311.424226] ? irq_thread_check_affinity+0x170/0x170
+[ 311.424230] ? kthread+0x19e/0x1c0
+[ 311.424233] ? kthread_create_worker_on_cpu+0xc0/0xc0
+[ 311.424237] ? ret_from_fork+0x32/0x40
+
+[ 311.424244] Allocated by task 899:
+[ 311.424249] kasan_kmalloc+0xbf/0xe0
+[ 311.424252] __kmalloc_track_caller+0xd9/0x1f0
+[ 311.424255] kmemdup+0x17/0x40
+[ 311.424264] rmi_set_attn_data+0xa4/0x1b0 [rmi_core]
+[ 311.424269] rmi_raw_event+0x10b/0x1f0 [hid_rmi]
+[ 311.424278] hid_input_report+0x1a8/0x2c0 [hid]
+[ 311.424283] i2c_hid_irq+0x146/0x1d0 [i2c_hid]
+[ 311.424286] irq_thread_fn+0x3d/0x80
+[ 311.424288] irq_thread+0x21d/0x290
+[ 311.424291] kthread+0x19e/0x1c0
+[ 311.424293] ret_from_fork+0x32/0x40
+
+[ 311.424296] Freed by task 1162:
+[ 311.424300] kasan_slab_free+0x71/0xc0
+[ 311.424303] kfree+0x90/0x190
+[ 311.424311] rmi_irq_fn+0x1b2/0x270 [rmi_core]
+[ 311.424319] rmi_irq_fn+0x257/0x270 [rmi_core]
+[ 311.424322] irq_thread_fn+0x3d/0x80
+[ 311.424324] irq_thread+0x21d/0x290
+[ 311.424327] kthread+0x19e/0x1c0
+[ 311.424330] ret_from_fork+0x32/0x40
+
+[ 311.424334] The buggy address belongs to the object at ffff88041fd610c0 which belongs to the cache kmalloc-64 of size 64
+[ 311.424340] The buggy address is located 27 bytes inside of 64-byte region [ffff88041fd610c0, ffff88041fd61100)
+[ 311.424344] The buggy address belongs to the page:
+[ 311.424348] page:ffffea00107f5840 count:1 mapcount:0 mapping: (null) index:0x0
+[ 311.424353] flags: 0x17ffffc0000100(slab)
+[ 311.424358] raw: 0017ffffc0000100 0000000000000000 0000000000000000 00000001802a002a
+[ 311.424363] raw: dead000000000100 dead000000000200 ffff8804228036c0 0000000000000000
+[ 311.424366] page dumped because: kasan: bad access detected
+
+[ 311.424369] Memory state around the buggy address:
+[ 311.424373] ffff88041fd60f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
+[ 311.424377] ffff88041fd61000: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
+[ 311.424381] >ffff88041fd61080: fb fb fb fb fc fc fc fc fb fb fb fb fb fb fb fb
+[ 311.424384] ^
+[ 311.424387] ffff88041fd61100: fc fc fc fc fb fb fb fb fb fb fb fb fc fc fc fc
+[ 311.424391] ffff88041fd61180: fb fb fb fb fb fb fb fb fc fc fc fc fb fb fb fb
+
+Signed-off-by: Nick Desaulniers <nick.desaulniers@gmail.com>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/rmi4/rmi_driver.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/input/rmi4/rmi_driver.c
++++ b/drivers/input/rmi4/rmi_driver.c
+@@ -230,8 +230,10 @@ static irqreturn_t rmi_irq_fn(int irq, v
+ rmi_dbg(RMI_DEBUG_CORE, &rmi_dev->dev,
+ "Failed to process interrupt request: %d\n", ret);
+
+- if (count)
++ if (count) {
+ kfree(attn_data.data);
++ attn_data.data = NULL;
++ }
+
+ if (!kfifo_is_empty(&drvdata->attn_fifo))
+ return rmi_irq_fn(irq, dev_id);
--- /dev/null
+From 5b189201993ab03001a398de731045bfea90c689 Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Jan 2018 17:15:06 -0800
+Subject: Input: twl4030-vibra - fix sibling-node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 5b189201993ab03001a398de731045bfea90c689 upstream.
+
+A helper purported to look up a child node based on its name was using
+the wrong of-helper and ended up prematurely freeing the parent of-node
+while searching the whole device tree depth-first starting at the parent
+node.
+
+Fixes: 64b9e4d803b1 ("input: twl4030-vibra: Support for DT booted kernel")
+Fixes: e661d0a04462 ("Input: twl4030-vibra - fix ERROR: Bad of_node_put() warning")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/misc/twl4030-vibra.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/drivers/input/misc/twl4030-vibra.c
++++ b/drivers/input/misc/twl4030-vibra.c
+@@ -178,12 +178,14 @@ static SIMPLE_DEV_PM_OPS(twl4030_vibra_p
+ twl4030_vibra_suspend, twl4030_vibra_resume);
+
+ static bool twl4030_vibra_check_coexist(struct twl4030_vibra_data *pdata,
+- struct device_node *node)
++ struct device_node *parent)
+ {
++ struct device_node *node;
++
+ if (pdata && pdata->coexist)
+ return true;
+
+- node = of_find_node_by_name(node, "codec");
++ node = of_get_child_by_name(parent, "codec");
+ if (node) {
+ of_node_put(node);
+ return true;
--- /dev/null
+From dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Mon, 8 Jan 2018 17:17:48 -0800
+Subject: Input: twl6040-vibra - fix child-node lookup
+
+From: Johan Hovold <johan@kernel.org>
+
+commit dcaf12a8b0bbdbfcfa2be8dff2c4948d9844b4ad upstream.
+
+Fix child-node lookup during probe, which ended up searching the whole
+device tree depth-first starting at parent rather than just matching on
+its children.
+
+Later sanity checks on node properties (which would likely be missing)
+should prevent this from causing much trouble however, especially as the
+original premature free of the parent node has already been fixed
+separately (but that "fix" was apparently never backported to stable).
+
+Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support")
+Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management")
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Tested-by: H. Nikolaus Schaller <hns@goldelico.com> (on Pyra OMAP5 hardware)
+Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/input/misc/twl6040-vibra.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/drivers/input/misc/twl6040-vibra.c
++++ b/drivers/input/misc/twl6040-vibra.c
+@@ -248,8 +248,7 @@ static int twl6040_vibra_probe(struct pl
+ int vddvibr_uV = 0;
+ int error;
+
+- of_node_get(twl6040_core_dev->of_node);
+- twl6040_core_node = of_find_node_by_name(twl6040_core_dev->of_node,
++ twl6040_core_node = of_get_child_by_name(twl6040_core_dev->of_node,
+ "vibra");
+ if (!twl6040_core_node) {
+ dev_err(&pdev->dev, "parent of node is missing?\n");
--- /dev/null
+From db5ff909798ef0099004ad50a0ff5fde92426fd1 Mon Sep 17 00:00:00 2001
+From: Xinyu Lin <xinyu0123@gmail.com>
+Date: Sun, 17 Dec 2017 20:13:39 +0800
+Subject: libata: apply MAX_SEC_1024 to all LITEON EP1 series devices
+
+From: Xinyu Lin <xinyu0123@gmail.com>
+
+commit db5ff909798ef0099004ad50a0ff5fde92426fd1 upstream.
+
+LITEON EP1 has the same timeout issues as CX1 series devices.
+
+Revert max_sectors to the value of 1024.
+
+Fixes: e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")
+Signed-off-by: Xinyu Lin <xinyu0123@gmail.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4439,6 +4439,7 @@ static const struct ata_blacklist_entry
+ * https://bugzilla.kernel.org/show_bug.cgi?id=121671
+ */
+ { "LITEON CX1-JB*-HP", NULL, ATA_HORKAGE_MAX_SEC_1024 },
++ { "LITEON EP1-*", NULL, ATA_HORKAGE_MAX_SEC_1024 },
+
+ /* Devices we expect to fail diagnostics */
+
--- /dev/null
+From b7563e2796f8b23c98afcfea7363194227fa089d Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 12 Jan 2018 11:12:05 +0100
+Subject: phy: work around 'phys' references to usb-nop-xceiv devices
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit b7563e2796f8b23c98afcfea7363194227fa089d upstream.
+
+Stefan Wahren reports a problem with a warning fix that was merged
+for v4.15: we had lots of device nodes with a 'phys' property pointing
+to a device node that is not compliant with the binding documented in
+Documentation/devicetree/bindings/phy/phy-bindings.txt
+
+This generally works because USB HCD drivers that support both the generic
+phy subsystem and the older usb-phy subsystem ignore most errors from
+phy_get() and related calls and then use the usb-phy driver instead.
+
+However, it turns out that making the usb-nop-xceiv device compatible with
+the generic-phy binding changes the phy_get() return code from -EINVAL to
+-EPROBE_DEFER, and the dwc2 usb controller driver for bcm2835 now returns
+-EPROBE_DEFER from its probe function rather than ignoring the failure,
+breaking all USB support on raspberry-pi when CONFIG_GENERIC_PHY is
+enabled. The same code is used in the dwc3 driver and the usb_add_hcd()
+function, so a reasonable assumption would be that many other platforms
+are affected as well.
+
+I have reviewed all the related patches and concluded that "usb-nop-xceiv"
+is the only USB phy that is affected by the change, and since it is by far
+the most commonly referenced phy, all the other USB phy drivers appear
+to be used in ways that are are either safe in DT (they don't use the
+'phys' property), or in the driver (they already ignore -EPROBE_DEFER
+from generic-phy when usb-phy is available).
+
+To work around the problem, this adds a special case to _of_phy_get()
+so we ignore any PHY node that is compatible with "usb-nop-xceiv",
+as we know that this can never load no matter how much we defer. In the
+future, we might implement a generic-phy driver for "usb-nop-xceiv"
+and then remove this workaround.
+
+Since we generally want older kernels to also want to work with the
+fixed devicetree files, it would be good to backport the patch into
+stable kernels as well (3.13+ are possibly affected), even though they
+don't contain any of the patches that may have caused regressions.
+
+Fixes: 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
+Fixes: c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
+Fixes: 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
+Fixes: f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
+Fixes: d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
+Fixes: 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
+Link: https://marc.info/?l=linux-usb&m=151518314314753&w=2
+Link: https://patchwork.kernel.org/patch/10158145/
+Cc: Felipe Balbi <balbi@kernel.org>
+Cc: Eric Anholt <eric@anholt.net>
+Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
+Acked-by: Rob Herring <robh@kernel.org>
+Tested-by: Hans Verkuil <hans.verkuil@cisco.com>
+Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/phy/phy-core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/phy/phy-core.c
++++ b/drivers/phy/phy-core.c
+@@ -395,6 +395,10 @@ static struct phy *_of_phy_get(struct de
+ if (ret)
+ return ERR_PTR(-ENODEV);
+
++ /* This phy type handled by the usb-phy subsystem for now */
++ if (of_device_is_compatible(args.np, "usb-nop-xceiv"))
++ return ERR_PTR(-ENODEV);
++
+ mutex_lock(&phy_provider_mutex);
+ phy_provider = of_phy_provider_lookup(args.np);
+ if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
--- /dev/null
+From 8bb2ee192e482c5d500df9f2b1b26a560bd3026f Mon Sep 17 00:00:00 2001
+From: Alexey Dobriyan <adobriyan@gmail.com>
+Date: Thu, 18 Jan 2018 16:34:05 -0800
+Subject: proc: fix coredump vs read /proc/*/stat race
+
+From: Alexey Dobriyan <adobriyan@gmail.com>
+
+commit 8bb2ee192e482c5d500df9f2b1b26a560bd3026f upstream.
+
+do_task_stat() accesses IP and SP of a task without bumping reference
+count of a stack (which became an entity with independent lifetime at
+some point).
+
+Steps to reproduce:
+
+ #include <stdio.h>
+ #include <sys/types.h>
+ #include <sys/stat.h>
+ #include <fcntl.h>
+ #include <sys/time.h>
+ #include <sys/resource.h>
+ #include <unistd.h>
+ #include <sys/wait.h>
+
+ int main(void)
+ {
+ setrlimit(RLIMIT_CORE, &(struct rlimit){});
+
+ while (1) {
+ char buf[64];
+ char buf2[4096];
+ pid_t pid;
+ int fd;
+
+ pid = fork();
+ if (pid == 0) {
+ *(volatile int *)0 = 0;
+ }
+
+ snprintf(buf, sizeof(buf), "/proc/%u/stat", pid);
+ fd = open(buf, O_RDONLY);
+ read(fd, buf2, sizeof(buf2));
+ close(fd);
+
+ waitpid(pid, NULL, 0);
+ }
+ return 0;
+ }
+
+ BUG: unable to handle kernel paging request at 0000000000003fd8
+ IP: do_task_stat+0x8b4/0xaf0
+ PGD 800000003d73e067 P4D 800000003d73e067 PUD 3d558067 PMD 0
+ Oops: 0000 [#1] PREEMPT SMP PTI
+ CPU: 0 PID: 1417 Comm: a.out Not tainted 4.15.0-rc8-dirty #2
+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1.fc27 04/01/2014
+ RIP: 0010:do_task_stat+0x8b4/0xaf0
+ Call Trace:
+ proc_single_show+0x43/0x70
+ seq_read+0xe6/0x3b0
+ __vfs_read+0x1e/0x120
+ vfs_read+0x84/0x110
+ SyS_read+0x3d/0xa0
+ entry_SYSCALL_64_fastpath+0x13/0x6c
+ RIP: 0033:0x7f4d7928cba0
+ RSP: 002b:00007ffddb245158 EFLAGS: 00000246
+ Code: 03 b7 a0 01 00 00 4c 8b 4c 24 70 4c 8b 44 24 78 4c 89 74 24 18 e9 91 f9 ff ff f6 45 4d 02 0f 84 fd f7 ff ff 48 8b 45 40 48 89 ef <48> 8b 80 d8 3f 00 00 48 89 44 24 20 e8 9b 97 eb ff 48 89 44 24
+ RIP: do_task_stat+0x8b4/0xaf0 RSP: ffffc90000607cc8
+ CR2: 0000000000003fd8
+
+John Ogness said: for my tests I added an else case to verify that the
+race is hit and correctly mitigated.
+
+Link: http://lkml.kernel.org/r/20180116175054.GA11513@avx2
+Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
+Reported-by: "Kohli, Gaurav" <gkohli@codeaurora.org>
+Tested-by: John Ogness <john.ogness@linutronix.de>
+Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
+Cc: Ingo Molnar <mingo@elte.hu>
+Cc: Oleg Nesterov <oleg@redhat.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>
+
+---
+ fs/proc/array.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/fs/proc/array.c
++++ b/fs/proc/array.c
+@@ -424,8 +424,11 @@ static int do_task_stat(struct seq_file
+ * safe because the task has stopped executing permanently.
+ */
+ if (permitted && (task->flags & PF_DUMPCORE)) {
+- eip = KSTK_EIP(task);
+- esp = KSTK_ESP(task);
++ if (try_get_task_stack(task)) {
++ eip = KSTK_EIP(task);
++ esp = KSTK_ESP(task);
++ put_task_stack(task);
++ }
+ }
+ }
+
--- /dev/null
+From 883d50f56d263f70fd73c0d96b09eb36c34e9305 Mon Sep 17 00:00:00 2001
+From: Xi Kangjie <imxikangjie@gmail.com>
+Date: Thu, 18 Jan 2018 16:34:00 -0800
+Subject: scripts/gdb/linux/tasks.py: fix get_thread_info
+
+From: Xi Kangjie <imxikangjie@gmail.com>
+
+commit 883d50f56d263f70fd73c0d96b09eb36c34e9305 upstream.
+
+Since kernel 4.9, the thread_info has been moved into task_struct, no
+longer locates at the bottom of kernel stack.
+
+See commits c65eacbe290b ("sched/core: Allow putting thread_info into
+task_struct") and 15f4eae70d36 ("x86: Move thread_info into
+task_struct").
+
+Before fix:
+ (gdb) set $current = $lx_current()
+ (gdb) p $lx_thread_info($current)
+ $1 = {flags = 1470918301}
+ (gdb) p $current.thread_info
+ $2 = {flags = 2147483648}
+
+After fix:
+ (gdb) p $lx_thread_info($current)
+ $1 = {flags = 2147483648}
+ (gdb) p $current.thread_info
+ $2 = {flags = 2147483648}
+
+Link: http://lkml.kernel.org/r/20180118210159.17223-1-imxikangjie@gmail.com
+Fixes: 15f4eae70d36 ("x86: Move thread_info into task_struct")
+Signed-off-by: Xi Kangjie <imxikangjie@gmail.com>
+Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
+Acked-by: Kieran Bingham <kbingham@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ scripts/gdb/linux/tasks.py | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/scripts/gdb/linux/tasks.py
++++ b/scripts/gdb/linux/tasks.py
+@@ -96,6 +96,8 @@ def get_thread_info(task):
+ thread_info_addr = task.address + ia64_task_size
+ thread_info = thread_info_addr.cast(thread_info_ptr_type)
+ else:
++ if task.type.fields()[0].type == thread_info_type.get_type():
++ return task['thread_info']
+ thread_info = task['stack'].cast(thread_info_ptr_type)
+ return thread_info.dereference()
+
--- /dev/null
+From c9f926000fe3b84135a81602a9f7e63a6a7898e2 Mon Sep 17 00:00:00 2001
+From: Hannes Reinecke <hare@suse.de>
+Date: Wed, 10 Jan 2018 09:34:02 +0100
+Subject: scsi: libsas: Disable asynchronous aborts for SATA devices
+
+From: Hannes Reinecke <hare@suse.de>
+
+commit c9f926000fe3b84135a81602a9f7e63a6a7898e2 upstream.
+
+Handling CD-ROM devices from libsas is decidedly odd, as libata relies
+on SCSI EH to be started to figure out that no medium is present. So we
+cannot do asynchronous aborts for SATA devices.
+
+Fixes: 909657615d9 ("scsi: libsas: allow async aborts")
+Signed-off-by: Hannes Reinecke <hare@suse.com>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Tested-by: Yves-Alexis Perez <corsac@debian.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/libsas/sas_scsi_host.c | 17 +++++++++++++++--
+ 1 file changed, 15 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/libsas/sas_scsi_host.c
++++ b/drivers/scsi/libsas/sas_scsi_host.c
+@@ -486,15 +486,28 @@ static int sas_queue_reset(struct domain
+
+ int sas_eh_abort_handler(struct scsi_cmnd *cmd)
+ {
+- int res;
++ int res = TMF_RESP_FUNC_FAILED;
+ struct sas_task *task = TO_SAS_TASK(cmd);
+ struct Scsi_Host *host = cmd->device->host;
++ struct domain_device *dev = cmd_to_domain_dev(cmd);
+ struct sas_internal *i = to_sas_internal(host->transportt);
++ unsigned long flags;
+
+ if (!i->dft->lldd_abort_task)
+ return FAILED;
+
+- res = i->dft->lldd_abort_task(task);
++ spin_lock_irqsave(host->host_lock, flags);
++ /* We cannot do async aborts for SATA devices */
++ if (dev_is_sata(dev) && !host->host_eh_scheduled) {
++ spin_unlock_irqrestore(host->host_lock, flags);
++ return FAILED;
++ }
++ spin_unlock_irqrestore(host->host_lock, flags);
++
++ if (task)
++ res = i->dft->lldd_abort_task(task);
++ else
++ SAS_DPRINTK("no task to abort\n");
+ if (res == TMF_RESP_FUNC_SUCC || res == TMF_RESP_FUNC_COMPLETE)
+ return SUCCESS;
+
x86-mm-prepare-sme_encrypt_kernel-for-page-aligned-encryption.patch
arm-omap3-hwmod_data-add-missing-module_offs-for-mmc3.patch
x86-mm-encrypt-the-initrd-earlier-for-bsp-microcode-update.patch
+input-alps-fix-multi-touch-decoding-on-ss4-plus-touchpads.patch
+input-synaptics-rmi4-prevent-uaf-reported-by-kasan.patch
+input-88pm860x-ts-fix-child-node-lookup.patch
+input-twl6040-vibra-fix-child-node-lookup.patch
+input-twl4030-vibra-fix-sibling-node-lookup.patch
+tracing-fix-converting-enum-s-from-the-map-in-trace_event_eval_update.patch
+phy-work-around-phys-references-to-usb-nop-xceiv-devices.patch
+arm64-dts-marvell-armada-cp110-fix-clock-resources-for-various-node.patch
+arm-sunxi_defconfig-enable-cma.patch
+arm-dts-kirkwood-fix-pin-muxing-of-mpp7-on-openblocks-a7.patch
+can-peak-fix-potential-bug-in-packet-fragmentation.patch
+can-af_can-can_rcv-replace-warn_once-by-pr_warn_once.patch
+can-af_can-canfd_rcv-replace-warn_once-by-pr_warn_once.patch
+i2c-core-smbus-prevent-stack-corruption-on-read-i2c_block_data.patch
+scripts-gdb-linux-tasks.py-fix-get_thread_info.patch
+proc-fix-coredump-vs-read-proc-stat-race.patch
+libata-apply-max_sec_1024-to-all-liteon-ep1-series-devices.patch
+scsi-libsas-disable-asynchronous-aborts-for-sata-devices.patch
+workqueue-avoid-hard-lockups-in-show_workqueue_state.patch
+drm-vmwgfx-fix-memory-corruption-with-legacy-sou-connectors.patch
+dm-btree-fix-serious-bug-in-btree_split_beneath.patch
+dm-thin-metadata-thin_max_concurrent_locks-should-be-6.patch
+dm-integrity-don-t-store-cipher-request-on-the-stack.patch
+dm-crypt-fix-crash-by-adding-missing-check-for-auth-key-size.patch
+dm-crypt-wipe-kernel-key-copy-after-iv-initialization.patch
+dm-crypt-fix-error-return-code-in-crypt_ctr.patch
--- /dev/null
+From 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
+Date: Thu, 18 Jan 2018 15:53:10 -0500
+Subject: tracing: Fix converting enum's from the map in trace_event_eval_update()
+
+From: Steven Rostedt (VMware) <rostedt@goodmis.org>
+
+commit 1ebe1eaf2f02784921759992ae1fde1a9bec8fd0 upstream.
+
+Since enums do not get converted by the TRACE_EVENT macro into their values,
+the event format displaces the enum name and not the value. This breaks
+tools like perf and trace-cmd that need to interpret the raw binary data. To
+solve this, an enum map was created to convert these enums into their actual
+numbers on boot up. This is done by TRACE_EVENTS() adding a
+TRACE_DEFINE_ENUM() macro.
+
+Some enums were not being converted. This was caused by an optization that
+had a bug in it.
+
+All calls get checked against this enum map to see if it should be converted
+or not, and it compares the call's system to the system that the enum map
+was created under. If they match, then they call is processed.
+
+To cut down on the number of iterations needed to find the maps with a
+matching system, since calls and maps are grouped by system, when a match is
+made, the index into the map array is saved, so that the next call, if it
+belongs to the same system as the previous call, could start right at that
+array index and not have to scan all the previous arrays.
+
+The problem was, the saved index was used as the variable to know if this is
+a call in a new system or not. If the index was zero, it was assumed that
+the call is in a new system and would keep incrementing the saved index
+until it found a matching system. The issue arises when the first matching
+system was at index zero. The next map, if it belonged to the same system,
+would then think it was the first match and increment the index to one. If
+the next call belong to the same system, it would begin its search of the
+maps off by one, and miss the first enum that should be converted. This left
+a single enum not converted properly.
+
+Also add a comment to describe exactly what that index was for. It took me a
+bit too long to figure out what I was thinking when debugging this issue.
+
+Link: http://lkml.kernel.org/r/717BE572-2070-4C1E-9902-9F2E0FEDA4F8@oracle.com
+
+Fixes: 0c564a538aa93 ("tracing: Add TRACE_DEFINE_ENUM() macro to map enums to their values")
+Reported-by: Chuck Lever <chuck.lever@oracle.com>
+Teste-by: Chuck Lever <chuck.lever@oracle.com>
+Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/trace/trace_events.c | 16 +++++++++++++++-
+ 1 file changed, 15 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace_events.c
++++ b/kernel/trace/trace_events.c
+@@ -2213,6 +2213,7 @@ void trace_event_eval_update(struct trac
+ {
+ struct trace_event_call *call, *p;
+ const char *last_system = NULL;
++ bool first = false;
+ int last_i;
+ int i;
+
+@@ -2220,15 +2221,28 @@ void trace_event_eval_update(struct trac
+ list_for_each_entry_safe(call, p, &ftrace_events, list) {
+ /* events are usually grouped together with systems */
+ if (!last_system || call->class->system != last_system) {
++ first = true;
+ last_i = 0;
+ last_system = call->class->system;
+ }
+
++ /*
++ * Since calls are grouped by systems, the likelyhood that the
++ * next call in the iteration belongs to the same system as the
++ * previous call is high. As an optimization, we skip seaching
++ * for a map[] that matches the call's system if the last call
++ * was from the same system. That's what last_i is for. If the
++ * call has the same system as the previous call, then last_i
++ * will be the index of the first map[] that has a matching
++ * system.
++ */
+ for (i = last_i; i < len; i++) {
+ if (call->class->system == map[i]->system) {
+ /* Save the first system if need be */
+- if (!last_i)
++ if (first) {
+ last_i = i;
++ first = false;
++ }
+ update_event_printk(call, map[i]);
+ }
+ }
--- /dev/null
+From 62635ea8c18f0f62df4cc58379e4f1d33afd5801 Mon Sep 17 00:00:00 2001
+From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
+Date: Thu, 11 Jan 2018 09:53:35 +0900
+Subject: workqueue: avoid hard lockups in show_workqueue_state()
+
+From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
+
+commit 62635ea8c18f0f62df4cc58379e4f1d33afd5801 upstream.
+
+show_workqueue_state() can print out a lot of messages while being in
+atomic context, e.g. sysrq-t -> show_workqueue_state(). If the console
+device is slow it may end up triggering NMI hard lockup watchdog.
+
+Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ kernel/workqueue.c | 13 +++++++++++++
+ 1 file changed, 13 insertions(+)
+
+--- a/kernel/workqueue.c
++++ b/kernel/workqueue.c
+@@ -48,6 +48,7 @@
+ #include <linux/nodemask.h>
+ #include <linux/moduleparam.h>
+ #include <linux/uaccess.h>
++#include <linux/nmi.h>
+
+ #include "workqueue_internal.h"
+
+@@ -4479,6 +4480,12 @@ void show_workqueue_state(void)
+ if (pwq->nr_active || !list_empty(&pwq->delayed_works))
+ show_pwq(pwq);
+ spin_unlock_irqrestore(&pwq->pool->lock, flags);
++ /*
++ * We could be printing a lot from atomic context, e.g.
++ * sysrq-t -> show_workqueue_state(). Avoid triggering
++ * hard lockup.
++ */
++ touch_nmi_watchdog();
+ }
+ }
+
+@@ -4506,6 +4513,12 @@ void show_workqueue_state(void)
+ pr_cont("\n");
+ next_pool:
+ spin_unlock_irqrestore(&pool->lock, flags);
++ /*
++ * We could be printing a lot from atomic context, e.g.
++ * sysrq-t -> show_workqueue_state(). Avoid triggering
++ * hard lockup.
++ */
++ touch_nmi_watchdog();
+ }
+
+ rcu_read_unlock_sched();
projects / thirdparty / kernel / stable-queue.git / commitdiff
