--- /dev/null
+From 87c5f8d9e9e5ebd3f5a0c3a3dcf92e6a812ee9de Mon Sep 17 00:00:00 2001
+From: Sven Eckelmann <sven@narfation.org>
+Date: Wed, 7 Nov 2018 23:09:12 +0100
+Subject: batman-adv: Expand merged fragment buffer for full packet
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit d7d8bbb40a5b1f682ee6589e212934f4c6b8ad60 ]
+
+The complete size ("total_size") of the fragmented packet is stored in the
+fragment header and in the size of the fragment chain. When the fragments
+are ready for merge, the skbuff's tail of the first fragment is expanded to
+have enough room after the data pointer for at least total_size. This means
+that it gets expanded by total_size - first_skb->len.
+
+But this is ignoring the fact that after expanding the buffer, the fragment
+header is pulled by from this buffer. Assuming that the tailroom of the
+buffer was already 0, the buffer after the data pointer of the skbuff is
+now only total_size - len(fragment_header) large. When the merge function
+is then processing the remaining fragments, the code to copy the data over
+to the merged skbuff will cause an skb_over_panic when it tries to actually
+put enough data to fill the total_size bytes of the packet.
+
+The size of the skb_pull must therefore also be taken into account when the
+buffer's tailroom is expanded.
+
+Fixes: 610bfc6bc99b ("batman-adv: Receive fragmented packets and merge")
+Reported-by: Martin Weinelt <martin@darmstadt.freifunk.net>
+Co-authored-by: Linus Lüssing <linus.luessing@c0d3.blue>
+Signed-off-by: Sven Eckelmann <sven@narfation.org>
+Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/batman-adv/fragmentation.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/net/batman-adv/fragmentation.c b/net/batman-adv/fragmentation.c
+index 57215e3fd1a0..a06b6041f3e0 100644
+--- a/net/batman-adv/fragmentation.c
++++ b/net/batman-adv/fragmentation.c
+@@ -264,7 +264,7 @@ batadv_frag_merge_packets(struct hlist_head *chain)
+ kfree(entry);
+
+ packet = (struct batadv_frag_packet *)skb_out->data;
+- size = ntohs(packet->total_size);
++ size = ntohs(packet->total_size) + hdr_size;
+
+ /* Make room for the rest of the fragments. */
+ if (pskb_expand_head(skb_out, 0, size - skb_out->len, GFP_ATOMIC) < 0) {
+--
+2.19.1
+
--- /dev/null
+From f4e5a077049c331397831092c34d485eba7936d7 Mon Sep 17 00:00:00 2001
+From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
+Date: Sun, 11 Nov 2018 18:27:34 -0800
+Subject: bnx2x: Assign unique DMAE channel number for FW DMAE transactions.
+
+[ Upstream commit 77e461d14ed141253573eeeb4d34eccc51e38328 ]
+
+Driver assigns DMAE channel 0 for FW as part of START_RAMROD command. FW
+uses this channel for DMAE operations (e.g., TIME_SYNC implementation).
+Driver also uses the same channel 0 for DMAE operations for some of the PFs
+(e.g., PF0 on Port0). This could lead to concurrent access to the DMAE
+channel by FW and driver which is not legal. Hence need to assign unique
+DMAE id for FW.
+Currently following DMAE channels are used by the clients,
+ MFW - OCBB/OCSD functionality uses DMAE channel 14/15
+ Driver 0-3 and 8-11 (for PF dmae operations)
+ 4 and 12 (for stats requests)
+Assigning unique dmae_id '13' to the FW.
+
+Changes from previous version:
+------------------------------
+v2: Incorporated the review comments.
+
+Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru@cavium.com>
+Signed-off-by: Michal Kalderon <Michal.Kalderon@cavium.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 7 +++++++
+ drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c | 1 +
+ 2 files changed, 8 insertions(+)
+
+diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+index f3f2d66432ab..d5e4c42662b6 100644
+--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
++++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h
+@@ -2187,6 +2187,13 @@ void bnx2x_igu_clear_sb_gen(struct bnx2x *bp, u8 func, u8 idu_sb_id,
+ #define PMF_DMAE_C(bp) (BP_PORT(bp) * MAX_DMAE_C_PER_PORT + \
+ E1HVN_MAX)
+
++/* Following is the DMAE channel number allocation for the clients.
++ * MFW: OCBB/OCSD implementations use DMAE channels 14/15 respectively.
++ * Driver: 0-3 and 8-11 (for PF dmae operations)
++ * 4 and 12 (for stats requests)
++ */
++#define BNX2X_FW_DMAE_C 13 /* Channel for FW DMAE operations */
++
+ /* PCIE link and speed */
+ #define PCICFG_LINK_WIDTH 0x1f00000
+ #define PCICFG_LINK_WIDTH_SHIFT 20
+diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
+index cea6bdcde33f..bf760c9cff6a 100644
+--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
++++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sp.c
+@@ -6149,6 +6149,7 @@ static inline int bnx2x_func_send_start(struct bnx2x *bp,
+ rdata->sd_vlan_tag = cpu_to_le16(start_params->sd_vlan_tag);
+ rdata->path_id = BP_PATH(bp);
+ rdata->network_cos_mode = start_params->network_cos_mode;
++ rdata->dmae_cmd_id = BNX2X_FW_DMAE_C;
+
+ rdata->vxlan_dst_port = cpu_to_le16(start_params->vxlan_dst_port);
+ rdata->geneve_dst_port = cpu_to_le16(start_params->geneve_dst_port);
+--
+2.19.1
+
--- /dev/null
+From 07d7a0ec04f5e5a10831e5836807ed9d30975abe Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= <rafal@milecki.pl>
+Date: Fri, 26 Oct 2018 12:50:39 +0200
+Subject: brcmutil: really fix decoding channel info for 160 MHz bandwidth
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 3401d42c7ea2d064d15c66698ff8eb96553179ce ]
+
+Previous commit /adding/ support for 160 MHz chanspecs was incomplete.
+It didn't set bandwidth info and didn't extract control channel info. As
+the result it was also using uninitialized "sb" var.
+
+This change has been tested for two chanspecs found to be reported by
+some devices/firmwares:
+1) 60/160 (0xee32)
+ Before: chnum:50 control_ch_num:36
+ After: chnum:50 control_ch_num:60
+2) 120/160 (0xed72)
+ Before: chnum:114 control_ch_num:100
+ After: chnum:114 control_ch_num:120
+
+Fixes: 330994e8e8ec ("brcmfmac: fix for proper support of 160MHz bandwidth")
+Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c b/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
+index e7584b842dce..eb5db94f5745 100644
+--- a/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
++++ b/drivers/net/wireless/broadcom/brcm80211/brcmutil/d11.c
+@@ -193,6 +193,9 @@ static void brcmu_d11ac_decchspec(struct brcmu_chan *ch)
+ }
+ break;
+ case BRCMU_CHSPEC_D11AC_BW_160:
++ ch->bw = BRCMU_CHAN_BW_160;
++ ch->sb = brcmu_maskget16(ch->chspec, BRCMU_CHSPEC_D11AC_SB_MASK,
++ BRCMU_CHSPEC_D11AC_SB_SHIFT);
+ switch (ch->sb) {
+ case BRCMU_CHAN_SB_LLL:
+ ch->control_ch_num -= CH_70MHZ_APART;
+--
+2.19.1
+
--- /dev/null
+From a3bef4b54ea43cdb30256a678510c5ead2b7b1ce Mon Sep 17 00:00:00 2001
+From: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
+Date: Mon, 10 Sep 2018 11:43:13 +0100
+Subject: can: rcar_can: Fix erroneous registration
+
+[ Upstream commit 68c8d209cd4337da4fa04c672f0b62bb735969bc ]
+
+Assigning 2 to "renesas,can-clock-select" tricks the driver into
+registering the CAN interface, even though we don't want that.
+This patch improves one of the checks to prevent that from happening.
+
+Fixes: 862e2b6af9413b43 ("can: rcar_can: support all input clocks")
+Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
+Signed-off-by: Chris Paterson <Chris.Paterson2@renesas.com>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/can/rcar/rcar_can.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/can/rcar/rcar_can.c b/drivers/net/can/rcar/rcar_can.c
+index 788459f6bf5c..9b2c3bd00f8b 100644
+--- a/drivers/net/can/rcar/rcar_can.c
++++ b/drivers/net/can/rcar/rcar_can.c
+@@ -24,6 +24,9 @@
+
+ #define RCAR_CAN_DRV_NAME "rcar_can"
+
++#define RCAR_SUPPORTED_CLOCKS (BIT(CLKR_CLKP1) | BIT(CLKR_CLKP2) | \
++ BIT(CLKR_CLKEXT))
++
+ /* Mailbox configuration:
+ * mailbox 60 - 63 - Rx FIFO mailboxes
+ * mailbox 56 - 59 - Tx FIFO mailboxes
+@@ -789,7 +792,7 @@ static int rcar_can_probe(struct platform_device *pdev)
+ goto fail_clk;
+ }
+
+- if (clock_select >= ARRAY_SIZE(clock_names)) {
++ if (!(BIT(clock_select) & RCAR_SUPPORTED_CLOCKS)) {
+ err = -EINVAL;
+ dev_err(&pdev->dev, "invalid CAN clock selected\n");
+ goto fail_clk;
+--
+2.19.1
+
--- /dev/null
+From bd0fc716878dcac5e9cc609183cb813984f552f2 Mon Sep 17 00:00:00 2001
+From: Benson Leung <bleung@chromium.org>
+Date: Thu, 8 Nov 2018 15:59:21 -0800
+Subject: HID: input: Ignore battery reported by Symbol DS4308
+
+[ Upstream commit 0fd791841a6d67af1155a9c3de54dea51220721e ]
+
+The Motorola/Zebra Symbol DS4308-HD is a handheld USB barcode scanner
+which does not have a battery, but reports one anyway that always has
+capacity 2.
+
+Let's apply the IGNORE quirk to prevent it from being treated like a
+power supply so that userspaces don't get confused that this
+accessory is almost out of power and warn the user that they need to charge
+their wired barcode scanner.
+
+Reported here: https://bugs.chromium.org/p/chromium/issues/detail?id=804720
+
+Signed-off-by: Benson Leung <bleung@chromium.org>
+Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hid/hid-ids.h | 1 +
+ drivers/hid/hid-input.c | 3 +++
+ 2 files changed, 4 insertions(+)
+
+diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
+index 8913f357e78f..6f4c84d824e6 100644
+--- a/drivers/hid/hid-ids.h
++++ b/drivers/hid/hid-ids.h
+@@ -965,6 +965,7 @@
+ #define USB_VENDOR_ID_SYMBOL 0x05e0
+ #define USB_DEVICE_ID_SYMBOL_SCANNER_1 0x0800
+ #define USB_DEVICE_ID_SYMBOL_SCANNER_2 0x1300
++#define USB_DEVICE_ID_SYMBOL_SCANNER_3 0x1200
+
+ #define USB_VENDOR_ID_SYNAPTICS 0x06cb
+ #define USB_DEVICE_ID_SYNAPTICS_TP 0x0001
+diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
+index 5ff6dd8147b6..fc7ada26457e 100644
+--- a/drivers/hid/hid-input.c
++++ b/drivers/hid/hid-input.c
+@@ -324,6 +324,9 @@ static const struct hid_device_id hid_battery_quirks[] = {
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_ELECOM,
+ USB_DEVICE_ID_ELECOM_BM084),
+ HID_BATTERY_QUIRK_IGNORE },
++ { HID_USB_DEVICE(USB_VENDOR_ID_SYMBOL,
++ USB_DEVICE_ID_SYMBOL_SCANNER_3),
++ HID_BATTERY_QUIRK_IGNORE },
+ {}
+ };
+
+--
+2.19.1
+
--- /dev/null
+From a275417a91e73b556752a599a1ba46be0b44e8e3 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Wed, 7 Nov 2018 14:18:50 +0100
+Subject: iommu/ipmmu-vmsa: Fix crash on early domain free
+
+[ Upstream commit e5b78f2e349eef5d4fca5dc1cf5a3b4b2cc27abd ]
+
+If iommu_ops.add_device() fails, iommu_ops.domain_free() is still
+called, leading to a crash, as the domain was only partially
+initialized:
+
+ ipmmu-vmsa e67b0000.mmu: Cannot accommodate DMA translation for IOMMU page tables
+ sata_rcar ee300000.sata: Unable to initialize IPMMU context
+ iommu: Failed to add device ee300000.sata to group 0: -22
+ Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038
+ ...
+ Call trace:
+ ipmmu_domain_free+0x1c/0xa0
+ iommu_group_release+0x48/0x68
+ kobject_put+0x74/0xe8
+ kobject_del.part.0+0x3c/0x50
+ kobject_put+0x60/0xe8
+ iommu_group_get_for_dev+0xa8/0x1f0
+ ipmmu_add_device+0x1c/0x40
+ of_iommu_configure+0x118/0x190
+
+Fix this by checking if the domain's context already exists, before
+trying to destroy it.
+
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Fixes: d25a2a16f0889 ('iommu: Add driver for Renesas VMSA-compatible IPMMU')
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/ipmmu-vmsa.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
+index 85b5e75c7faa..3d2e9ca78f02 100644
+--- a/drivers/iommu/ipmmu-vmsa.c
++++ b/drivers/iommu/ipmmu-vmsa.c
+@@ -372,6 +372,9 @@ static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain)
+
+ static void ipmmu_domain_destroy_context(struct ipmmu_vmsa_domain *domain)
+ {
++ if (!domain->mmu)
++ return;
++
+ /*
+ * Disable the context. Flush the TLB as required when modifying the
+ * context registers.
+--
+2.19.1
+
--- /dev/null
+From 0d08564bfdade181fae9913e4aacbd8704262ca0 Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Mon, 5 Nov 2018 10:18:58 +0800
+Subject: iommu/vt-d: Fix NULL pointer dereference in prq_event_thread()
+
+[ Upstream commit 19ed3e2dd8549c1a34914e8dad01b64e7837645a ]
+
+When handling page request without pasid event, go to "no_pasid"
+branch instead of "bad_req". Otherwise, a NULL pointer deference
+will happen there.
+
+Cc: Ashok Raj <ashok.raj@intel.com>
+Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
+Cc: Sohil Mehta <sohil.mehta@intel.com>
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Fixes: a222a7f0bb6c9 'iommu/vt-d: Implement page request handling'
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/intel-svm.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
+index f846f0140a9d..7dc2f8d415b6 100644
+--- a/drivers/iommu/intel-svm.c
++++ b/drivers/iommu/intel-svm.c
+@@ -558,7 +558,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
+ pr_err("%s: Page request without PASID: %08llx %08llx\n",
+ iommu->name, ((unsigned long long *)req)[0],
+ ((unsigned long long *)req)[1]);
+- goto bad_req;
++ goto no_pasid;
+ }
+
+ if (!svm || svm->pasid != req->pasid) {
+--
+2.19.1
+
--- /dev/null
+From e39e96db94dbb207e418c121765db116f66b8d0b Mon Sep 17 00:00:00 2001
+From: Pan Bian <bianpan2016@163.com>
+Date: Wed, 21 Nov 2018 17:53:47 +0800
+Subject: iommu/vt-d: Use memunmap to free memremap
+
+[ Upstream commit 829383e183728dec7ed9150b949cd6de64127809 ]
+
+memunmap() should be used to free the return of memremap(), not
+iounmap().
+
+Fixes: dfddb969edf0 ('iommu/vt-d: Switch from ioremap_cache to memremap')
+Signed-off-by: Pan Bian <bianpan2016@163.com>
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/iommu/intel-iommu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
+index 2558a381e118..f8c8537f0587 100644
+--- a/drivers/iommu/intel-iommu.c
++++ b/drivers/iommu/intel-iommu.c
+@@ -3054,7 +3054,7 @@ static int copy_context_table(struct intel_iommu *iommu,
+ }
+
+ if (old_ce)
+- iounmap(old_ce);
++ memunmap(old_ce);
+
+ ret = 0;
+ if (devfn < 0x80)
+--
+2.19.1
+
--- /dev/null
+From 6718b8f3ea082a06ec874e42da48c82440948fee Mon Sep 17 00:00:00 2001
+From: Sakari Ailus <sakari.ailus@linux.intel.com>
+Date: Tue, 9 Oct 2018 07:49:49 -0400
+Subject: media: omap3isp: Unregister media device as first
+
+[ Upstream commit 30efae3d789cd0714ef795545a46749236e29558 ]
+
+While there are issues related to object lifetime management, unregister the
+media device first when the driver is being unbound. This is slightly
+safer.
+
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/media/platform/omap3isp/isp.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/media/platform/omap3isp/isp.c b/drivers/media/platform/omap3isp/isp.c
+index 1e98b4845ea1..a21b12c5c085 100644
+--- a/drivers/media/platform/omap3isp/isp.c
++++ b/drivers/media/platform/omap3isp/isp.c
+@@ -1591,6 +1591,8 @@ static void isp_pm_complete(struct device *dev)
+
+ static void isp_unregister_entities(struct isp_device *isp)
+ {
++ media_device_unregister(&isp->media_dev);
++
+ omap3isp_csi2_unregister_entities(&isp->isp_csi2a);
+ omap3isp_ccp2_unregister_entities(&isp->isp_ccp2);
+ omap3isp_ccdc_unregister_entities(&isp->isp_ccdc);
+@@ -1601,7 +1603,6 @@ static void isp_unregister_entities(struct isp_device *isp)
+ omap3isp_stat_unregister_entities(&isp->isp_hist);
+
+ v4l2_device_unregister(&isp->v4l2_dev);
+- media_device_unregister(&isp->media_dev);
+ media_device_cleanup(&isp->media_dev);
+ }
+
+--
+2.19.1
+
--- /dev/null
+From e37fde4c2a4ad649d6a0be878a70856a87f3ce55 Mon Sep 17 00:00:00 2001
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Date: Fri, 7 Dec 2018 12:33:56 -0800
+Subject: mm: don't warn about allocations which stall for too long
+
+commit 400e22499dd92613821374c8c6c88c7225359980 upstream.
+
+Commit 63f53dea0c98 ("mm: warn about allocations which stall for too
+long") was a great step for reducing possibility of silent hang up
+problem caused by memory allocation stalls. But this commit reverts it,
+for it is possible to trigger OOM lockup and/or soft lockups when many
+threads concurrently called warn_alloc() (in order to warn about memory
+allocation stalls) due to current implementation of printk(), and it is
+difficult to obtain useful information due to limitation of synchronous
+warning approach.
+
+Current printk() implementation flushes all pending logs using the
+context of a thread which called console_unlock(). printk() should be
+able to flush all pending logs eventually unless somebody continues
+appending to printk() buffer.
+
+Since warn_alloc() started appending to printk() buffer while waiting
+for oom_kill_process() to make forward progress when oom_kill_process()
+is processing pending logs, it became possible for warn_alloc() to force
+oom_kill_process() loop inside printk(). As a result, warn_alloc()
+significantly increased possibility of preventing oom_kill_process()
+from making forward progress.
+
+---------- Pseudo code start ----------
+Before warn_alloc() was introduced:
+
+ retry:
+ if (mutex_trylock(&oom_lock)) {
+ while (atomic_read(&printk_pending_logs) > 0) {
+ atomic_dec(&printk_pending_logs);
+ print_one_log();
+ }
+ // Send SIGKILL here.
+ mutex_unlock(&oom_lock)
+ }
+ goto retry;
+
+After warn_alloc() was introduced:
+
+ retry:
+ if (mutex_trylock(&oom_lock)) {
+ while (atomic_read(&printk_pending_logs) > 0) {
+ atomic_dec(&printk_pending_logs);
+ print_one_log();
+ }
+ // Send SIGKILL here.
+ mutex_unlock(&oom_lock)
+ } else if (waited_for_10seconds()) {
+ atomic_inc(&printk_pending_logs);
+ }
+ goto retry;
+---------- Pseudo code end ----------
+
+Although waited_for_10seconds() becomes true once per 10 seconds,
+unbounded number of threads can call waited_for_10seconds() at the same
+time. Also, since threads doing waited_for_10seconds() keep doing
+almost busy loop, the thread doing print_one_log() can use little CPU
+resource. Therefore, this situation can be simplified like
+
+---------- Pseudo code start ----------
+ retry:
+ if (mutex_trylock(&oom_lock)) {
+ while (atomic_read(&printk_pending_logs) > 0) {
+ atomic_dec(&printk_pending_logs);
+ print_one_log();
+ }
+ // Send SIGKILL here.
+ mutex_unlock(&oom_lock)
+ } else {
+ atomic_inc(&printk_pending_logs);
+ }
+ goto retry;
+---------- Pseudo code end ----------
+
+when printk() is called faster than print_one_log() can process a log.
+
+One of possible mitigation would be to introduce a new lock in order to
+make sure that no other series of printk() (either oom_kill_process() or
+warn_alloc()) can append to printk() buffer when one series of printk()
+(either oom_kill_process() or warn_alloc()) is already in progress.
+
+Such serialization will also help obtaining kernel messages in readable
+form.
+
+---------- Pseudo code start ----------
+ retry:
+ if (mutex_trylock(&oom_lock)) {
+ mutex_lock(&oom_printk_lock);
+ while (atomic_read(&printk_pending_logs) > 0) {
+ atomic_dec(&printk_pending_logs);
+ print_one_log();
+ }
+ // Send SIGKILL here.
+ mutex_unlock(&oom_printk_lock);
+ mutex_unlock(&oom_lock)
+ } else {
+ if (mutex_trylock(&oom_printk_lock)) {
+ atomic_inc(&printk_pending_logs);
+ mutex_unlock(&oom_printk_lock);
+ }
+ }
+ goto retry;
+---------- Pseudo code end ----------
+
+But this commit does not go that direction, for we don't want to
+introduce a new lock dependency, and we unlikely be able to obtain
+useful information even if we serialized oom_kill_process() and
+warn_alloc().
+
+Synchronous approach is prone to unexpected results (e.g. too late [1],
+too frequent [2], overlooked [3]). As far as I know, warn_alloc() never
+helped with providing information other than "something is going wrong".
+I want to consider asynchronous approach which can obtain information
+during stalls with possibly relevant threads (e.g. the owner of
+oom_lock and kswapd-like threads) and serve as a trigger for actions
+(e.g. turn on/off tracepoints, ask libvirt daemon to take a memory dump
+of stalling KVM guest for diagnostic purpose).
+
+This commit temporarily loses ability to report e.g. OOM lockup due to
+unable to invoke the OOM killer due to !__GFP_FS allocation request.
+But asynchronous approach will be able to detect such situation and emit
+warning. Thus, let's remove warn_alloc().
+
+[1] https://bugzilla.kernel.org/show_bug.cgi?id=192981
+[2] http://lkml.kernel.org/r/CAM_iQpWuPVGc2ky8M-9yukECtS+zKjiDasNymX7rMcBjBFyM_A@mail.gmail.com
+[3] commit db73ee0d46379922 ("mm, vmscan: do not loop on too_many_isolated for ever"))
+
+Link: http://lkml.kernel.org/r/1509017339-4802-1-git-send-email-penguin-kernel@I-love.SAKURA.ne.jp
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Reported-by: Cong Wang <xiyou.wangcong@gmail.com>
+Reported-by: yuwang.yuwang <yuwang.yuwang@alibaba-inc.com>
+Reported-by: Johannes Weiner <hannes@cmpxchg.org>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Acked-by: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: Dave Hansen <dave.hansen@intel.com>
+Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Cc: Petr Mladek <pmladek@suse.com>
+Cc: Steven Rostedt <rostedt@goodmis.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+
+[Resolved backport conflict due to missing 8225196, a8e9925, 9e80c71 and
+ 9a67f64 in 4.9 -- all of which modified this hunk being removed.]
+Signed-off-by: Amit Shah <amit@kernel.org>
+
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/page_alloc.c | 10 ----------
+ 1 file changed, 10 deletions(-)
+
+diff --git a/mm/page_alloc.c b/mm/page_alloc.c
+index 28240ce475d6..3af727d95c17 100644
+--- a/mm/page_alloc.c
++++ b/mm/page_alloc.c
+@@ -3530,8 +3530,6 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
+ enum compact_result compact_result;
+ int compaction_retries;
+ int no_progress_loops;
+- unsigned long alloc_start = jiffies;
+- unsigned int stall_timeout = 10 * HZ;
+ unsigned int cpuset_mems_cookie;
+
+ /*
+@@ -3704,14 +3702,6 @@ retry:
+ if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
+ goto nopage;
+
+- /* Make sure we know about allocations which stall for too long */
+- if (time_after(jiffies, alloc_start + stall_timeout)) {
+- warn_alloc(gfp_mask,
+- "page allocation stalls for %ums, order:%u",
+- jiffies_to_msecs(jiffies-alloc_start), order);
+- stall_timeout += 10 * HZ;
+- }
+-
+ if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
+ did_some_progress > 0, &no_progress_loops))
+ goto retry;
+--
+2.19.1
+
--- /dev/null
+From e1459b81229c3a07c59da1609a7aeb7ca9cd1da9 Mon Sep 17 00:00:00 2001
+From: Olof Johansson <olof@lixom.net>
+Date: Fri, 16 Nov 2018 19:43:27 -0800
+Subject: mtd: rawnand: qcom: Namespace prefix some commands
+
+[ Upstream commit 33bf5519ae5dd356b182a94e3622f42860274a38 ]
+
+PAGE_READ is used by RISC-V arch code included through mm headers,
+and it makes sense to bring in a prefix on these in the driver.
+
+drivers/mtd/nand/raw/qcom_nandc.c:153: warning: "PAGE_READ" redefined
+ #define PAGE_READ 0x2
+In file included from include/linux/memremap.h:7,
+ from include/linux/mm.h:27,
+ from include/linux/scatterlist.h:8,
+ from include/linux/dma-mapping.h:11,
+ from drivers/mtd/nand/raw/qcom_nandc.c:17:
+arch/riscv/include/asm/pgtable.h:48: note: this is the location of the previous definition
+
+Caught by riscv allmodconfig.
+
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
+Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mtd/nand/qcom_nandc.c | 32 ++++++++++++++++----------------
+ 1 file changed, 16 insertions(+), 16 deletions(-)
+
+diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
+index dc4943134649..9f6c9a34b9eb 100644
+--- a/drivers/mtd/nand/qcom_nandc.c
++++ b/drivers/mtd/nand/qcom_nandc.c
+@@ -142,15 +142,15 @@
+ #define NAND_VERSION_MINOR_SHIFT 16
+
+ /* NAND OP_CMDs */
+-#define PAGE_READ 0x2
+-#define PAGE_READ_WITH_ECC 0x3
+-#define PAGE_READ_WITH_ECC_SPARE 0x4
+-#define PROGRAM_PAGE 0x6
+-#define PAGE_PROGRAM_WITH_ECC 0x7
+-#define PROGRAM_PAGE_SPARE 0x9
+-#define BLOCK_ERASE 0xa
+-#define FETCH_ID 0xb
+-#define RESET_DEVICE 0xd
++#define OP_PAGE_READ 0x2
++#define OP_PAGE_READ_WITH_ECC 0x3
++#define OP_PAGE_READ_WITH_ECC_SPARE 0x4
++#define OP_PROGRAM_PAGE 0x6
++#define OP_PAGE_PROGRAM_WITH_ECC 0x7
++#define OP_PROGRAM_PAGE_SPARE 0x9
++#define OP_BLOCK_ERASE 0xa
++#define OP_FETCH_ID 0xb
++#define OP_RESET_DEVICE 0xd
+
+ /* Default Value for NAND_DEV_CMD_VLD */
+ #define NAND_DEV_CMD_VLD_VAL (READ_START_VLD | WRITE_START_VLD | \
+@@ -425,11 +425,11 @@ static void update_rw_regs(struct qcom_nand_host *host, int num_cw, bool read)
+
+ if (read) {
+ if (host->use_ecc)
+- cmd = PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
++ cmd = OP_PAGE_READ_WITH_ECC | PAGE_ACC | LAST_PAGE;
+ else
+- cmd = PAGE_READ | PAGE_ACC | LAST_PAGE;
++ cmd = OP_PAGE_READ | PAGE_ACC | LAST_PAGE;
+ } else {
+- cmd = PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
++ cmd = OP_PROGRAM_PAGE | PAGE_ACC | LAST_PAGE;
+ }
+
+ if (host->use_ecc) {
+@@ -662,7 +662,7 @@ static int nandc_param(struct qcom_nand_host *host)
+ * in use. we configure the controller to perform a raw read of 512
+ * bytes to read onfi params
+ */
+- nandc_set_reg(nandc, NAND_FLASH_CMD, PAGE_READ | PAGE_ACC | LAST_PAGE);
++ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_PAGE_READ | PAGE_ACC | LAST_PAGE);
+ nandc_set_reg(nandc, NAND_ADDR0, 0);
+ nandc_set_reg(nandc, NAND_ADDR1, 0);
+ nandc_set_reg(nandc, NAND_DEV0_CFG0, 0 << CW_PER_PAGE
+@@ -715,7 +715,7 @@ static int erase_block(struct qcom_nand_host *host, int page_addr)
+ struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
+
+ nandc_set_reg(nandc, NAND_FLASH_CMD,
+- BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
++ OP_BLOCK_ERASE | PAGE_ACC | LAST_PAGE);
+ nandc_set_reg(nandc, NAND_ADDR0, page_addr);
+ nandc_set_reg(nandc, NAND_ADDR1, 0);
+ nandc_set_reg(nandc, NAND_DEV0_CFG0,
+@@ -746,7 +746,7 @@ static int read_id(struct qcom_nand_host *host, int column)
+ if (column == -1)
+ return 0;
+
+- nandc_set_reg(nandc, NAND_FLASH_CMD, FETCH_ID);
++ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_FETCH_ID);
+ nandc_set_reg(nandc, NAND_ADDR0, column);
+ nandc_set_reg(nandc, NAND_ADDR1, 0);
+ nandc_set_reg(nandc, NAND_FLASH_CHIP_SELECT, DM_EN);
+@@ -766,7 +766,7 @@ static int reset(struct qcom_nand_host *host)
+ struct nand_chip *chip = &host->chip;
+ struct qcom_nand_controller *nandc = get_qcom_nand_controller(chip);
+
+- nandc_set_reg(nandc, NAND_FLASH_CMD, RESET_DEVICE);
++ nandc_set_reg(nandc, NAND_FLASH_CMD, OP_RESET_DEVICE);
+ nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
+
+ write_reg_dma(nandc, NAND_FLASH_CMD, 1);
+--
+2.19.1
+
--- /dev/null
+From 868a598f02d3681febd940c89e6d49ae5ca5a1e5 Mon Sep 17 00:00:00 2001
+From: Yangtao Li <tiny.windzz@gmail.com>
+Date: Thu, 22 Nov 2018 07:34:41 -0500
+Subject: net: amd: add missing of_node_put()
+
+[ Upstream commit c44c749d3b6fdfca39002e7e48e03fe9f9fe37a3 ]
+
+of_find_node_by_path() acquires a reference to the node
+returned by it and that reference needs to be dropped by its caller.
+This place doesn't do that, so fix it.
+
+Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/amd/sunlance.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/amd/sunlance.c b/drivers/net/ethernet/amd/sunlance.c
+index 9b56b40259dc..3153465d4d02 100644
+--- a/drivers/net/ethernet/amd/sunlance.c
++++ b/drivers/net/ethernet/amd/sunlance.c
+@@ -1419,7 +1419,7 @@ static int sparc_lance_probe_one(struct platform_device *op,
+
+ prop = of_get_property(nd, "tpe-link-test?", NULL);
+ if (!prop)
+- goto no_link_test;
++ goto node_put;
+
+ if (strcmp(prop, "true")) {
+ printk(KERN_NOTICE "SunLance: warning: overriding option "
+@@ -1428,6 +1428,8 @@ static int sparc_lance_probe_one(struct platform_device *op,
+ "to ecd@skynet.be\n");
+ auxio_set_lte(AUXIO_LTE_ON);
+ }
++node_put:
++ of_node_put(nd);
+ no_link_test:
+ lp->auto_select = 1;
+ lp->tpe = 0;
+--
+2.19.1
+
--- /dev/null
+From cc3b58550994d6b5f5fda863747578e5349e031b Mon Sep 17 00:00:00 2001
+From: Vincent Chen <vincentc@andestech.com>
+Date: Wed, 21 Nov 2018 09:38:11 +0800
+Subject: net: faraday: ftmac100: remove netif_running(netdev) check before
+ disabling interrupts
+
+[ Upstream commit 426a593e641ebf0d9288f0a2fcab644a86820220 ]
+
+In the original ftmac100_interrupt(), the interrupts are only disabled when
+the condition "netif_running(netdev)" is true. However, this condition
+causes kerenl hang in the following case. When the user requests to
+disable the network device, kernel will clear the bit __LINK_STATE_START
+from the dev->state and then call the driver's ndo_stop function. Network
+device interrupts are not blocked during this process. If an interrupt
+occurs between clearing __LINK_STATE_START and stopping network device,
+kernel cannot disable the interrupts due to the condition
+"netif_running(netdev)" in the ISR. Hence, kernel will hang due to the
+continuous interruption of the network device.
+
+In order to solve the above problem, the interrupts of the network device
+should always be disabled in the ISR without being restricted by the
+condition "netif_running(netdev)".
+
+[V2]
+Remove unnecessary curly braces.
+
+Signed-off-by: Vincent Chen <vincentc@andestech.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/faraday/ftmac100.c | 7 +++----
+ 1 file changed, 3 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/net/ethernet/faraday/ftmac100.c b/drivers/net/ethernet/faraday/ftmac100.c
+index dce5f7b7f772..05e1f923f49e 100644
+--- a/drivers/net/ethernet/faraday/ftmac100.c
++++ b/drivers/net/ethernet/faraday/ftmac100.c
+@@ -865,11 +865,10 @@ static irqreturn_t ftmac100_interrupt(int irq, void *dev_id)
+ struct net_device *netdev = dev_id;
+ struct ftmac100 *priv = netdev_priv(netdev);
+
+- if (likely(netif_running(netdev))) {
+- /* Disable interrupts for polling */
+- ftmac100_disable_all_int(priv);
++ /* Disable interrupts for polling */
++ ftmac100_disable_all_int(priv);
++ if (likely(netif_running(netdev)))
+ napi_schedule(&priv->napi);
+- }
+
+ return IRQ_HANDLED;
+ }
+--
+2.19.1
+
--- /dev/null
+From ea68da14fd3180b273f464d2621cb45b0b7818a0 Mon Sep 17 00:00:00 2001
+From: Aya Levin <ayal@mellanox.com>
+Date: Thu, 15 Nov 2018 18:05:15 +0200
+Subject: net/mlx4: Fix UBSAN warning of signed integer overflow
+
+[ Upstream commit a463146e67c848cbab5ce706d6528281b7cded08 ]
+
+UBSAN: Undefined behavior in
+drivers/net/ethernet/mellanox/mlx4/resource_tracker.c:626:29
+signed integer overflow: 1802201963 + 1802201963 cannot be represented
+in type 'int'
+
+The union of res_reserved and res_port_rsvd[MLX4_MAX_PORTS] monitors
+granting of reserved resources. The grant operation is calculated and
+protected, thus both members of the union cannot be negative. Changed
+type of res_reserved and of res_port_rsvd[MLX4_MAX_PORTS] from signed
+int to unsigned int, allowing large value.
+
+Fixes: 5a0d0a6161ae ("mlx4: Structures and init/teardown for VF resource quotas")
+Signed-off-by: Aya Levin <ayal@mellanox.com>
+Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx4/mlx4.h | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4.h b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+index 086920b615af..df5d86fa0a92 100644
+--- a/drivers/net/ethernet/mellanox/mlx4/mlx4.h
++++ b/drivers/net/ethernet/mellanox/mlx4/mlx4.h
+@@ -542,8 +542,8 @@ struct slave_list {
+ struct resource_allocator {
+ spinlock_t alloc_lock; /* protect quotas */
+ union {
+- int res_reserved;
+- int res_port_rsvd[MLX4_MAX_PORTS];
++ unsigned int res_reserved;
++ unsigned int res_port_rsvd[MLX4_MAX_PORTS];
+ };
+ union {
+ int res_free;
+--
+2.19.1
+
--- /dev/null
+From d4bcc4bf7cef884bebfd5f6533199cccb46fe510 Mon Sep 17 00:00:00 2001
+From: Tariq Toukan <tariqt@mellanox.com>
+Date: Thu, 15 Nov 2018 18:05:14 +0200
+Subject: net/mlx4_core: Fix uninitialized variable compilation warning
+
+[ Upstream commit 3ea7e7ea53c9f6ee41cb69a29c375fe9dd9a56a7 ]
+
+Initialize the uid variable to zero to avoid the compilation warning.
+
+Fixes: 7a89399ffad7 ("net/mlx4: Add mlx4_bitmap zone allocator")
+Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx4/alloc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx4/alloc.c b/drivers/net/ethernet/mellanox/mlx4/alloc.c
+index 249a4584401a..b89a34fa3601 100644
+--- a/drivers/net/ethernet/mellanox/mlx4/alloc.c
++++ b/drivers/net/ethernet/mellanox/mlx4/alloc.c
+@@ -339,7 +339,7 @@ void mlx4_zone_allocator_destroy(struct mlx4_zone_allocator *zone_alloc)
+ static u32 __mlx4_alloc_from_zone(struct mlx4_zone_entry *zone, int count,
+ int align, u32 skip_mask, u32 *puid)
+ {
+- u32 uid;
++ u32 uid = 0;
+ u32 res;
+ struct mlx4_zone_allocator *zone_alloc = zone->allocator;
+ struct mlx4_zone_entry *curr_node;
+--
+2.19.1
+
--- /dev/null
+From 537f61508556d4a9b45a2f65c33d14e3bd88effe Mon Sep 17 00:00:00 2001
+From: Jack Morgenstein <jackm@dev.mellanox.co.il>
+Date: Thu, 15 Nov 2018 18:05:13 +0200
+Subject: net/mlx4_core: Zero out lkey field in SW2HW_MPT fw command
+
+[ Upstream commit bd85fbc2038a1bbe84990b23ff69b6fc81a32b2c ]
+
+When re-registering a user mr, the mpt information for the
+existing mr when running SRIOV is obtained via the QUERY_MPT
+fw command. The returned information includes the mpt's lkey.
+
+This retrieved mpt information is used to move the mpt back
+to hardware ownership in the rereg flow (via the SW2HW_MPT
+fw command when running SRIOV).
+
+The fw API spec states that for SW2HW_MPT, the lkey field
+must be zero. Any ConnectX-3 PF driver which checks for strict spec
+adherence will return failure for SW2HW_MPT if the lkey field is not
+zero (although the fw in practice ignores this field for SW2HW_MPT).
+
+Thus, in order to conform to the fw API spec, set the lkey field to zero
+before invoking SW2HW_MPT when running SRIOV.
+
+Fixes: e630664c8383 ("mlx4_core: Add helper functions to support MR re-registration")
+Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
+Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx4/mr.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx4/mr.c b/drivers/net/ethernet/mellanox/mlx4/mr.c
+index 395b5463cfd9..3637474cab8a 100644
+--- a/drivers/net/ethernet/mellanox/mlx4/mr.c
++++ b/drivers/net/ethernet/mellanox/mlx4/mr.c
+@@ -366,6 +366,7 @@ int mlx4_mr_hw_write_mpt(struct mlx4_dev *dev, struct mlx4_mr *mmr,
+ container_of((void *)mpt_entry, struct mlx4_cmd_mailbox,
+ buf);
+
++ (*mpt_entry)->lkey = 0;
+ err = mlx4_SW2HW_MPT(dev, mailbox, key);
+ }
+
+--
+2.19.1
+
--- /dev/null
+From 39d080c97cc4f0c4598dbc23f00ee5a3ccfedb6b Mon Sep 17 00:00:00 2001
+From: Denis Bolotin <denis.bolotin@cavium.com>
+Date: Mon, 12 Nov 2018 12:50:20 +0200
+Subject: qed: Fix PTT leak in qed_drain()
+
+[ Upstream commit 9aaa4e8ba12972d674caeefbc5f88d83235dd697 ]
+
+Release PTT before entering error flow.
+
+Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
+Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qed/qed_main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
+index 1ed13a165e58..a769196628d9 100644
+--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
++++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
+@@ -1395,9 +1395,9 @@ static int qed_drain(struct qed_dev *cdev)
+ return -EBUSY;
+ }
+ rc = qed_mcp_drain(hwfn, ptt);
++ qed_ptt_release(hwfn, ptt);
+ if (rc)
+ return rc;
+- qed_ptt_release(hwfn, ptt);
+ }
+
+ return 0;
+--
+2.19.1
+
--- /dev/null
+From 1a819f3d831d3c105dfe23cb7442a19285f203c4 Mon Sep 17 00:00:00 2001
+From: Denis Bolotin <denis.bolotin@cavium.com>
+Date: Mon, 12 Nov 2018 12:50:23 +0200
+Subject: qed: Fix reading wrong value in loop condition
+
+[ Upstream commit ed4eac20dcffdad47709422e0cb925981b056668 ]
+
+The value of "sb_index" is written by the hardware. Reading its value and
+writing it to "index" must finish before checking the loop condition.
+
+Signed-off-by: Denis Bolotin <denis.bolotin@cavium.com>
+Signed-off-by: Michal Kalderon <michal.kalderon@cavium.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qed/qed_int.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/ethernet/qlogic/qed/qed_int.c b/drivers/net/ethernet/qlogic/qed/qed_int.c
+index 2adedc6fb6cf..fd19372db2f8 100644
+--- a/drivers/net/ethernet/qlogic/qed/qed_int.c
++++ b/drivers/net/ethernet/qlogic/qed/qed_int.c
+@@ -2135,6 +2135,8 @@ static int qed_int_attentions(struct qed_hwfn *p_hwfn)
+ */
+ do {
+ index = p_sb_attn->sb_index;
++ /* finish reading index before the loop condition */
++ dma_rmb();
+ attn_bits = le32_to_cpu(p_sb_attn->atten_bits);
+ attn_acks = le32_to_cpu(p_sb_attn->atten_ack);
+ } while (index != p_sb_attn->sb_index);
+--
+2.19.1
+
--- /dev/null
+media-omap3isp-unregister-media-device-as-first.patch
+iommu-vt-d-fix-null-pointer-dereference-in-prq_event.patch
+brcmutil-really-fix-decoding-channel-info-for-160-mh.patch
+iommu-ipmmu-vmsa-fix-crash-on-early-domain-free.patch
+can-rcar_can-fix-erroneous-registration.patch
+hid-input-ignore-battery-reported-by-symbol-ds4308.patch
+batman-adv-expand-merged-fragment-buffer-for-full-pa.patch
+bnx2x-assign-unique-dmae-channel-number-for-fw-dmae-.patch
+qed-fix-ptt-leak-in-qed_drain.patch
+qed-fix-reading-wrong-value-in-loop-condition.patch
+net-mlx4_core-zero-out-lkey-field-in-sw2hw_mpt-fw-co.patch
+net-mlx4_core-fix-uninitialized-variable-compilation.patch
+net-mlx4-fix-ubsan-warning-of-signed-integer-overflo.patch
+mtd-rawnand-qcom-namespace-prefix-some-commands.patch
+net-faraday-ftmac100-remove-netif_running-netdev-che.patch
+iommu-vt-d-use-memunmap-to-free-memremap.patch
+team-no-need-to-do-team_notify_peers-or-team_mcast_r.patch
+net-amd-add-missing-of_node_put.patch
+mm-don-t-warn-about-allocations-which-stall-for-too-.patch
--- /dev/null
+From ee2f688d393f60830f8b524d4efcdfba3eb873b2 Mon Sep 17 00:00:00 2001
+From: Hangbin Liu <liuhangbin@gmail.com>
+Date: Thu, 22 Nov 2018 16:15:28 +0800
+Subject: team: no need to do team_notify_peers or team_mcast_rejoin when
+ disabling port
+
+[ Upstream commit 5ed9dc99107144f83b6c1bb52a69b58875baf540 ]
+
+team_notify_peers() will send ARP and NA to notify peers. team_mcast_rejoin()
+will send multicast join group message to notify peers. We should do this when
+enabling/changed to a new port. But it doesn't make sense to do it when a port
+is disabled.
+
+On the other hand, when we set mcast_rejoin_count to 2, and do a failover,
+team_port_disable() will increase mcast_rejoin.count_pending to 2 and then
+team_port_enable() will increase mcast_rejoin.count_pending to 4. We will send
+4 mcast rejoin messages at latest, which will make user confused. The same
+with notify_peers.count.
+
+Fix it by deleting team_notify_peers() and team_mcast_rejoin() in
+team_port_disable().
+
+Reported-by: Liang Li <liali@redhat.com>
+Fixes: fc423ff00df3a ("team: add peer notification")
+Fixes: 492b200efdd20 ("team: add support for sending multicast rejoins")
+Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/team/team.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
+index 9670aa23ffb9..94b05dd827af 100644
+--- a/drivers/net/team/team.c
++++ b/drivers/net/team/team.c
+@@ -989,8 +989,6 @@ static void team_port_disable(struct team *team,
+ team->en_port_count--;
+ team_queue_override_port_del(team, port);
+ team_adjust_ops(team);
+- team_notify_peers(team);
+- team_mcast_rejoin(team);
+ team_lower_state_changed(port);
+ }
+
+--
+2.19.1
+