--- /dev/null
+From ee2f703e7986fa47d1fb3276d5f4ee914234989e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 9 Aug 2020 21:40:20 -0700
+Subject: clk: rockchip: Fix initialization of mux_pll_src_4plls_p
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Nathan Chancellor <natechancellor@gmail.com>
+
+[ Upstream commit e9c006bc782c488f485ffe50de20b44e1e3daa18 ]
+
+A new warning in Clang points out that the initialization of
+mux_pll_src_4plls_p appears incorrect:
+
+../drivers/clk/rockchip/clk-rk3228.c:140:58: warning: suspicious
+concatenation of string literals in an array initialization; did you
+mean to separate the elements with a comma? [-Wstring-concatenation]
+PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy" "usb480m" };
+ ^
+ ,
+../drivers/clk/rockchip/clk-rk3228.c:140:48: note: place parentheses
+around the string literal to silence warning
+PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy" "usb480m" };
+ ^
+1 warning generated.
+
+Given the name of the variable and the same variable name in rv1108, it
+seems that this should have been four distinct elements. Fix it up by
+adding the comma as suggested.
+
+Fixes: 307a2e9ac524 ("clk: rockchip: add clock controller for rk3228")
+Link: https://github.com/ClangBuiltLinux/linux/issues/1123
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Link: https://lore.kernel.org/r/20200810044020.2063350-1-natechancellor@gmail.com
+Reviewed-by: Heiko Stübner <heiko@sntech.de>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/clk/rockchip/clk-rk3228.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/clk/rockchip/clk-rk3228.c b/drivers/clk/rockchip/clk-rk3228.c
+index 04f4f3739e3be..8d11d76e1db7c 100644
+--- a/drivers/clk/rockchip/clk-rk3228.c
++++ b/drivers/clk/rockchip/clk-rk3228.c
+@@ -144,7 +144,7 @@ PNAME(mux_usb480m_p) = { "usb480m_phy", "xin24m" };
+ PNAME(mux_hdmiphy_p) = { "hdmiphy_phy", "xin24m" };
+ PNAME(mux_aclk_cpu_src_p) = { "cpll_aclk_cpu", "gpll_aclk_cpu", "hdmiphy_aclk_cpu" };
+
+-PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy" "usb480m" };
++PNAME(mux_pll_src_4plls_p) = { "cpll", "gpll", "hdmiphy", "usb480m" };
+ PNAME(mux_pll_src_3plls_p) = { "cpll", "gpll", "hdmiphy" };
+ PNAME(mux_pll_src_2plls_p) = { "cpll", "gpll" };
+ PNAME(mux_sclk_hdmi_cec_p) = { "cpll", "gpll", "xin24m" };
+--
+2.25.1
+
--- /dev/null
+From 0eefa0a28869efdd26b00dcd8b9f37343a4c7a9d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 13 Sep 2020 12:47:29 -0700
+Subject: Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload
+
+From: Michael Kelley <mikelley@microsoft.com>
+
+[ Upstream commit 911e1987efc8f3e6445955fbae7f54b428b92bd3 ]
+
+vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message
+coming from Hyper-V. But if the message isn't found for some reason,
+the panic path gets hung forever. Add a timeout of 10 seconds to prevent
+this.
+
+Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()")
+Signed-off-by: Michael Kelley <mikelley@microsoft.com>
+Reviewed-by: Dexuan Cui <decui@microsoft.com>
+Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Link: https://lore.kernel.org/r/1600026449-23651-1-git-send-email-mikelley@microsoft.com
+Signed-off-by: Wei Liu <wei.liu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hv/channel_mgmt.c | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
+index 462f7f363faab..5bf633c15cd4b 100644
+--- a/drivers/hv/channel_mgmt.c
++++ b/drivers/hv/channel_mgmt.c
+@@ -774,7 +774,7 @@ static void vmbus_wait_for_unload(void)
+ void *page_addr;
+ struct hv_message *msg;
+ struct vmbus_channel_message_header *hdr;
+- u32 message_type;
++ u32 message_type, i;
+
+ /*
+ * CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was
+@@ -784,8 +784,11 @@ static void vmbus_wait_for_unload(void)
+ * functional and vmbus_unload_response() will complete
+ * vmbus_connection.unload_event. If not, the last thing we can do is
+ * read message pages for all CPUs directly.
++ *
++ * Wait no more than 10 seconds so that the panic path can't get
++ * hung forever in case the response message isn't seen.
+ */
+- while (1) {
++ for (i = 0; i < 1000; i++) {
+ if (completion_done(&vmbus_connection.unload_event))
+ break;
+
+--
+2.25.1
+
--- /dev/null
+From 0ce2ed484b1df4b77a41d7b87d309d5b80468d9d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Sep 2020 16:49:42 +0800
+Subject: drm/mediatek: Add exception handing in mtk_drm_probe() if component
+ init fail
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit 64c194c00789889b0f9454f583712f079ba414ee ]
+
+mtk_ddp_comp_init() is called in a loop in mtk_drm_probe(), if it
+fail, previous successive init component is not proccessed.
+
+Thus uninitialize valid component and put their device if component
+init failed.
+
+Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+index 670662128edd2..f32645a33cc90 100644
+--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
++++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+@@ -538,8 +538,13 @@ err_pm:
+ pm_runtime_disable(dev);
+ err_node:
+ of_node_put(private->mutex_node);
+- for (i = 0; i < DDP_COMPONENT_ID_MAX; i++)
++ for (i = 0; i < DDP_COMPONENT_ID_MAX; i++) {
+ of_node_put(private->comp_node[i]);
++ if (private->ddp_comp[i]) {
++ put_device(private->ddp_comp[i]->larb_dev);
++ private->ddp_comp[i] = NULL;
++ }
++ }
+ return ret;
+ }
+
+--
+2.25.1
+
--- /dev/null
+From c77760bcf6454f3690739fd5a0c435cc1658dbc5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 19:21:51 +0800
+Subject: drm/mediatek: Add missing put_device() call in
+ mtk_hdmi_dt_parse_pdata()
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit 0680a622318b8d657323b94082f4b9a44038dfee ]
+
+if of_find_device_by_node() succeed, mtk_drm_kms_init() doesn't have
+a corresponding put_device(). Thus add jump target to fix the exception
+handling for this function implementation.
+
+Fixes: 8f83f26891e1 ("drm/mediatek: Add HDMI support")
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/mediatek/mtk_hdmi.c | 26 ++++++++++++++++++--------
+ 1 file changed, 18 insertions(+), 8 deletions(-)
+
+diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c b/drivers/gpu/drm/mediatek/mtk_hdmi.c
+index 3c69c73fbd473..f1a376c34e713 100644
+--- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
++++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
+@@ -1476,25 +1476,30 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
+ dev_err(dev,
+ "Failed to get system configuration registers: %d\n",
+ ret);
+- return ret;
++ goto put_device;
+ }
+ hdmi->sys_regmap = regmap;
+
+ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ hdmi->regs = devm_ioremap_resource(dev, mem);
+- if (IS_ERR(hdmi->regs))
+- return PTR_ERR(hdmi->regs);
++ if (IS_ERR(hdmi->regs)) {
++ ret = PTR_ERR(hdmi->regs);
++ goto put_device;
++ }
+
+ remote = of_graph_get_remote_node(np, 1, 0);
+- if (!remote)
+- return -EINVAL;
++ if (!remote) {
++ ret = -EINVAL;
++ goto put_device;
++ }
+
+ if (!of_device_is_compatible(remote, "hdmi-connector")) {
+ hdmi->next_bridge = of_drm_find_bridge(remote);
+ if (!hdmi->next_bridge) {
+ dev_err(dev, "Waiting for external bridge\n");
+ of_node_put(remote);
+- return -EPROBE_DEFER;
++ ret = -EPROBE_DEFER;
++ goto put_device;
+ }
+ }
+
+@@ -1503,7 +1508,8 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
+ dev_err(dev, "Failed to find ddc-i2c-bus node in %pOF\n",
+ remote);
+ of_node_put(remote);
+- return -EINVAL;
++ ret = -EINVAL;
++ goto put_device;
+ }
+ of_node_put(remote);
+
+@@ -1511,10 +1517,14 @@ static int mtk_hdmi_dt_parse_pdata(struct mtk_hdmi *hdmi,
+ of_node_put(i2c_np);
+ if (!hdmi->ddc_adpt) {
+ dev_err(dev, "Failed to get ddc i2c adapter by node\n");
+- return -EINVAL;
++ ret = -EINVAL;
++ goto put_device;
+ }
+
+ return 0;
++put_device:
++ put_device(hdmi->cec_dev);
++ return ret;
+ }
+
+ /*
+--
+2.25.1
+
--- /dev/null
+From a9a109eeb4ec2e09f3ece6b1d5427310d25caf21 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 18 Aug 2020 15:40:14 +0530
+Subject: f2fs: fix indefinite loop scanning for free nid
+
+From: Sahitya Tummala <stummala@codeaurora.org>
+
+[ Upstream commit e2cab031ba7b5003cd12185b3ef38f1a75e3dae8 ]
+
+If the sbi->ckpt->next_free_nid is not NAT block aligned and if there
+are free nids in that NAT block between the start of the block and
+next_free_nid, then those free nids will not be scanned in scan_nat_page().
+This results into mismatch between nm_i->available_nids and the sum of
+nm_i->free_nid_count of all NAT blocks scanned. And nm_i->available_nids
+will always be greater than the sum of free nids in all the blocks.
+Under this condition, if we use all the currently scanned free nids,
+then it will loop forever in f2fs_alloc_nid() as nm_i->available_nids
+is still not zero but nm_i->free_nid_count of that partially scanned
+NAT block is zero.
+
+Fix this to align the nm_i->next_scan_nid to the first nid of the
+corresponding NAT block.
+
+Signed-off-by: Sahitya Tummala <stummala@codeaurora.org>
+Reviewed-by: Chao Yu <yuchao0@huawei.com>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/f2fs/node.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
+index e7b8e2b35e226..f8006f62c5467 100644
+--- a/fs/f2fs/node.c
++++ b/fs/f2fs/node.c
+@@ -2011,6 +2011,9 @@ static void __build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount)
+ if (unlikely(nid >= nm_i->max_nid))
+ nid = 0;
+
++ if (unlikely(nid % NAT_ENTRY_PER_BLOCK))
++ nid = NAT_BLOCK_OFFSET(nid) * NAT_ENTRY_PER_BLOCK;
++
+ /* Enough entries */
+ if (nm_i->nid_cnt[FREE_NID_LIST] >= NAT_ENTRY_PER_BLOCK)
+ return;
+--
+2.25.1
+
--- /dev/null
+From 39d736003ac995634f8b37f57fafc6582af214fb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 11 Sep 2020 07:57:06 +0900
+Subject: fbcon: Fix user font detection test at fbcon_resize().
+
+From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+
+[ Upstream commit ec0972adecb391a8d8650832263a4790f3bfb4df ]
+
+syzbot is reporting OOB read at fbcon_resize() [1], for
+commit 39b3cffb8cf31117 ("fbcon: prevent user font height or width change
+ from causing potential out-of-bounds access") is by error using
+registered_fb[con2fb_map[vc->vc_num]]->fbcon_par->p->userfont (which was
+set to non-zero) instead of fb_display[vc->vc_num].userfont (which remains
+zero for that display).
+
+We could remove tricky userfont flag [2], for we can determine it by
+comparing address of the font data and addresses of built-in font data.
+But since that commit is failing to fix the original OOB read [3], this
+patch keeps the change minimal in case we decide to revert altogether.
+
+[1] https://syzkaller.appspot.com/bug?id=ebcbbb6576958a496500fee9cf7aa83ea00b5920
+[2] https://syzkaller.appspot.com/text?tag=Patch&x=14030853900000
+[3] https://syzkaller.appspot.com/bug?id=6fba8c186d97cf1011ab17660e633b1cc4e080c9
+
+Reported-by: syzbot <syzbot+b38b1ef6edf0c74a8d97@syzkaller.appspotmail.com>
+Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
+Fixes: 39b3cffb8cf31117 ("fbcon: prevent user font height or width change from causing potential out-of-bounds access")
+Cc: George Kennedy <george.kennedy@oracle.com>
+Link: https://lore.kernel.org/r/f6e3e611-8704-1263-d163-f52c906a4f06@I-love.SAKURA.ne.jp
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/video/fbdev/core/fbcon.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
+index 9f12d8e512aa3..5825f057fb4b1 100644
+--- a/drivers/video/fbdev/core/fbcon.c
++++ b/drivers/video/fbdev/core/fbcon.c
+@@ -1957,7 +1957,7 @@ static int fbcon_resize(struct vc_data *vc, unsigned int width,
+ struct fb_var_screeninfo var = info->var;
+ int x_diff, y_diff, virt_w, virt_h, virt_fw, virt_fh;
+
+- if (ops->p && ops->p->userfont && FNTSIZE(vc->vc_font.data)) {
++ if (p->userfont && FNTSIZE(vc->vc_font.data)) {
+ int size;
+ int pitch = PITCH(vc->vc_font.width);
+
+--
+2.25.1
+
--- /dev/null
+From 1eb035d1833448ae9f0aa88ea5258180af31bbae Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Sep 2020 08:32:47 +1200
+Subject: i2c: algo: pca: Reapply i2c bus settings after reset
+
+From: Evan Nimmo <evan.nimmo@alliedtelesis.co.nz>
+
+[ Upstream commit 0a355aeb24081e4538d4d424cd189f16c0bbd983 ]
+
+If something goes wrong (such as the SCL being stuck low) then we need
+to reset the PCA chip. The issue with this is that on reset we lose all
+config settings and the chip ends up in a disabled state which results
+in a lock up/high CPU usage. We need to re-apply any configuration that
+had previously been set and re-enable the chip.
+
+Signed-off-by: Evan Nimmo <evan.nimmo@alliedtelesis.co.nz>
+Reviewed-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/algos/i2c-algo-pca.c | 35 +++++++++++++++++++++-----------
+ include/linux/i2c-algo-pca.h | 15 ++++++++++++++
+ 2 files changed, 38 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/i2c/algos/i2c-algo-pca.c b/drivers/i2c/algos/i2c-algo-pca.c
+index 3a9db4626cb60..1886588b9ea3e 100644
+--- a/drivers/i2c/algos/i2c-algo-pca.c
++++ b/drivers/i2c/algos/i2c-algo-pca.c
+@@ -50,8 +50,22 @@ static void pca_reset(struct i2c_algo_pca_data *adap)
+ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_IPRESET);
+ pca_outw(adap, I2C_PCA_IND, 0xA5);
+ pca_outw(adap, I2C_PCA_IND, 0x5A);
++
++ /*
++ * After a reset we need to re-apply any configuration
++ * (calculated in pca_init) to get the bus in a working state.
++ */
++ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_IMODE);
++ pca_outw(adap, I2C_PCA_IND, adap->bus_settings.mode);
++ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_ISCLL);
++ pca_outw(adap, I2C_PCA_IND, adap->bus_settings.tlow);
++ pca_outw(adap, I2C_PCA_INDPTR, I2C_PCA_ISCLH);
++ pca_outw(adap, I2C_PCA_IND, adap->bus_settings.thi);
++
++ pca_set_con(adap, I2C_PCA_CON_ENSIO);
+ } else {
+ adap->reset_chip(adap->data);
++ pca_set_con(adap, I2C_PCA_CON_ENSIO | adap->bus_settings.clock_freq);
+ }
+ }
+
+@@ -435,13 +449,14 @@ static int pca_init(struct i2c_adapter *adap)
+ " Use the nominal frequency.\n", adap->name);
+ }
+
+- pca_reset(pca_data);
+-
+ clock = pca_clock(pca_data);
+ printk(KERN_INFO "%s: Clock frequency is %dkHz\n",
+ adap->name, freqs[clock]);
+
+- pca_set_con(pca_data, I2C_PCA_CON_ENSIO | clock);
++ /* Store settings as these will be needed when the PCA chip is reset */
++ pca_data->bus_settings.clock_freq = clock;
++
++ pca_reset(pca_data);
+ } else {
+ int clock;
+ int mode;
+@@ -508,19 +523,15 @@ static int pca_init(struct i2c_adapter *adap)
+ thi = tlow * min_thi / min_tlow;
+ }
+
++ /* Store settings as these will be needed when the PCA chip is reset */
++ pca_data->bus_settings.mode = mode;
++ pca_data->bus_settings.tlow = tlow;
++ pca_data->bus_settings.thi = thi;
++
+ pca_reset(pca_data);
+
+ printk(KERN_INFO
+ "%s: Clock frequency is %dHz\n", adap->name, clock * 100);
+-
+- pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_IMODE);
+- pca_outw(pca_data, I2C_PCA_IND, mode);
+- pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ISCLL);
+- pca_outw(pca_data, I2C_PCA_IND, tlow);
+- pca_outw(pca_data, I2C_PCA_INDPTR, I2C_PCA_ISCLH);
+- pca_outw(pca_data, I2C_PCA_IND, thi);
+-
+- pca_set_con(pca_data, I2C_PCA_CON_ENSIO);
+ }
+ udelay(500); /* 500 us for oscillator to stabilise */
+
+diff --git a/include/linux/i2c-algo-pca.h b/include/linux/i2c-algo-pca.h
+index d03071732db4a..7c522fdd9ea73 100644
+--- a/include/linux/i2c-algo-pca.h
++++ b/include/linux/i2c-algo-pca.h
+@@ -53,6 +53,20 @@
+ #define I2C_PCA_CON_SI 0x08 /* Serial Interrupt */
+ #define I2C_PCA_CON_CR 0x07 /* Clock Rate (MASK) */
+
++/**
++ * struct pca_i2c_bus_settings - The configured PCA i2c bus settings
++ * @mode: Configured i2c bus mode
++ * @tlow: Configured SCL LOW period
++ * @thi: Configured SCL HIGH period
++ * @clock_freq: The configured clock frequency
++ */
++struct pca_i2c_bus_settings {
++ int mode;
++ int tlow;
++ int thi;
++ int clock_freq;
++};
++
+ struct i2c_algo_pca_data {
+ void *data; /* private low level data */
+ void (*write_byte) (void *data, int reg, int val);
+@@ -64,6 +78,7 @@ struct i2c_algo_pca_data {
+ * For PCA9665, use the frequency you want here. */
+ unsigned int i2c_clock;
+ unsigned int chip;
++ struct pca_i2c_bus_settings bus_settings;
+ };
+
+ int i2c_pca_add_bus(struct i2c_adapter *);
+--
+2.25.1
+
--- /dev/null
+From 2a9848e63bbdc511c8d09bc8dd923abcf513e634 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Sep 2020 18:33:51 +0800
+Subject: KVM: MIPS: Change the definition of kvm type
+
+From: Huacai Chen <chenhc@lemote.com>
+
+[ Upstream commit 15e9e35cd1dec2bc138464de6bf8ef828df19235 ]
+
+MIPS defines two kvm types:
+
+ #define KVM_VM_MIPS_TE 0
+ #define KVM_VM_MIPS_VZ 1
+
+In Documentation/virt/kvm/api.rst it is said that "You probably want to
+use 0 as machine type", which implies that type 0 be the "automatic" or
+"default" type. And, in user-space libvirt use the null-machine (with
+type 0) to detect the kvm capability, which returns "KVM not supported"
+on a VZ platform.
+
+I try to fix it in QEMU but it is ugly:
+https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg05629.html
+
+And Thomas Huth suggests me to change the definition of kvm type:
+https://lists.nongnu.org/archive/html/qemu-devel/2020-09/msg03281.html
+
+So I define like this:
+
+ #define KVM_VM_MIPS_AUTO 0
+ #define KVM_VM_MIPS_VZ 1
+ #define KVM_VM_MIPS_TE 2
+
+Since VZ and TE cannot co-exists, using type 0 on a TE platform will
+still return success (so old user-space tools have no problems on new
+kernels); the advantage is that using type 0 on a VZ platform will not
+return failure. So, the only problem is "new user-space tools use type
+2 on old kernels", but if we treat this as a kernel bug, we can backport
+this patch to old stable kernels.
+
+Signed-off-by: Huacai Chen <chenhc@lemote.com>
+Message-Id: <1599734031-28746-1-git-send-email-chenhc@lemote.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/kvm/mips.c | 2 ++
+ include/uapi/linux/kvm.h | 5 +++--
+ 2 files changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
+index aa6c365f25591..8614225e92eb5 100644
+--- a/arch/mips/kvm/mips.c
++++ b/arch/mips/kvm/mips.c
+@@ -131,6 +131,8 @@ void kvm_arch_check_processor_compat(void *rtn)
+ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
+ {
+ switch (type) {
++ case KVM_VM_MIPS_AUTO:
++ break;
+ #ifdef CONFIG_KVM_MIPS_VZ
+ case KVM_VM_MIPS_VZ:
+ #else
+diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
+index efe8873943f66..62f5e47aed160 100644
+--- a/include/uapi/linux/kvm.h
++++ b/include/uapi/linux/kvm.h
+@@ -735,9 +735,10 @@ struct kvm_ppc_resize_hpt {
+ #define KVM_VM_PPC_HV 1
+ #define KVM_VM_PPC_PR 2
+
+-/* on MIPS, 0 forces trap & emulate, 1 forces VZ ASE */
+-#define KVM_VM_MIPS_TE 0
++/* on MIPS, 0 indicates auto, 1 forces VZ ASE, 2 forces trap & emulate */
++#define KVM_VM_MIPS_AUTO 0
+ #define KVM_VM_MIPS_VZ 1
++#define KVM_VM_MIPS_TE 2
+
+ #define KVM_S390_SIE_PAGE_OFFSET 1
+
+--
+2.25.1
+
--- /dev/null
+From 57c094b05b0350290d08dd9f395b81dd2a4ec934 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Sep 2020 18:05:00 +0200
+Subject: MIPS: SNI: Fix MIPS_L1_CACHE_SHIFT
+
+From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+[ Upstream commit 564c836fd945a94b5dd46597d6b7adb464092650 ]
+
+Commit 930beb5ac09a ("MIPS: introduce MIPS_L1_CACHE_SHIFT_<N>") forgot
+to select the correct MIPS_L1_CACHE_SHIFT for SNI RM. This breaks non
+coherent DMA because of a wrong allocation alignment.
+
+Fixes: 930beb5ac09a ("MIPS: introduce MIPS_L1_CACHE_SHIFT_<N>")
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/Kconfig | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
+index 7e267d657c561..49c540790fd2d 100644
+--- a/arch/mips/Kconfig
++++ b/arch/mips/Kconfig
+@@ -856,6 +856,7 @@ config SNI_RM
+ select I8253
+ select I8259
+ select ISA
++ select MIPS_L1_CACHE_SHIFT_6
+ select SWAP_IO_SPACE if CPU_BIG_ENDIAN
+ select SYS_HAS_CPU_R4X00
+ select SYS_HAS_CPU_R5000
+--
+2.25.1
+
--- /dev/null
+From eee7c8c2bf99a1f4a1e8b72665d758eaca6d04d8 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Sep 2020 15:54:37 +0200
+Subject: MIPS: SNI: Fix spurious interrupts
+
+From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]
+
+On A20R machines the interrupt pending bits in cause register need to be
+updated by requesting the chipset to do it. This needs to be done to
+find the interrupt cause and after interrupt service. In
+commit 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the
+function to do after service update got lost, which caused spurious
+interrupts.
+
+Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions")
+Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/mips/sni/a20r.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
+index f9407e1704762..c6af7047eb0d2 100644
+--- a/arch/mips/sni/a20r.c
++++ b/arch/mips/sni/a20r.c
+@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
+ },
+ };
+
+-static u32 a20r_ack_hwint(void)
++/*
++ * Trigger chipset to update CPU's CAUSE IP field
++ */
++static u32 a20r_update_cause_ip(void)
+ {
+ u32 status = read_c0_status();
+
+@@ -205,12 +208,14 @@ static void a20r_hwint(void)
+ int irq;
+
+ clear_c0_status(IE_IRQ0);
+- status = a20r_ack_hwint();
++ status = a20r_update_cause_ip();
+ cause = read_c0_cause();
+
+ irq = ffs(((cause & status) >> 8) & 0xf8);
+ if (likely(irq > 0))
+ do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
++
++ a20r_update_cause_ip();
+ set_c0_status(IE_IRQ0);
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 4fd0200d24b7ed4704b99b19dd9f72fafa8e8428 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 20 Aug 2020 18:52:43 -0400
+Subject: NFSv4.1 handle ERR_DELAY error reclaiming locking state on delegation
+ recall
+
+From: Olga Kornievskaia <kolga@netapp.com>
+
+[ Upstream commit 3d7a9520f0c3e6a68b6de8c5812fc8b6d7a52626 ]
+
+A client should be able to handle getting an ERR_DELAY error
+while doing a LOCK call to reclaim state due to delegation being
+recalled. This is a transient error that can happen due to server
+moving its volumes and invalidating its file location cache and
+upon reference to it during the LOCK call needing to do an
+expensive lookup (leading to an ERR_DELAY error on a PUTFH).
+
+Signed-off-by: Olga Kornievskaia <kolga@netapp.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4proc.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
+index 4cfb84119e017..997b731ee19ab 100644
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -6687,7 +6687,12 @@ int nfs4_lock_delegation_recall(struct file_lock *fl, struct nfs4_state *state,
+ err = nfs4_set_lock_state(state, fl);
+ if (err != 0)
+ return err;
+- err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
++ do {
++ err = _nfs4_do_setlk(state, F_SETLK, fl, NFS_LOCK_NEW);
++ if (err != -NFS4ERR_DELAY)
++ break;
++ ssleep(1);
++ } while (err == -NFS4ERR_DELAY);
+ return nfs4_handle_delegation_recall_error(server, state, stateid, fl, err);
+ }
+
+--
+2.25.1
+
--- /dev/null
+From 1603d987e8897893dd41230c75eee77da77b5263 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 17:42:54 -0500
+Subject: nvme-fc: cancel async events before freeing event struct
+
+From: David Milburn <dmilburn@redhat.com>
+
+[ Upstream commit e126e8210e950bb83414c4f57b3120ddb8450742 ]
+
+Cancel async event work in case async event has been queued up, and
+nvme_fc_submit_async_event() runs after event has been freed.
+
+Signed-off-by: David Milburn <dmilburn@redhat.com>
+Reviewed-by: Keith Busch <kbusch@kernel.org>
+Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/fc.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/nvme/host/fc.c b/drivers/nvme/host/fc.c
+index 13c89cc9d10cf..e95d2f75713e1 100644
+--- a/drivers/nvme/host/fc.c
++++ b/drivers/nvme/host/fc.c
+@@ -1566,6 +1566,7 @@ nvme_fc_term_aen_ops(struct nvme_fc_ctrl *ctrl)
+ struct nvme_fc_fcp_op *aen_op;
+ int i;
+
++ cancel_work_sync(&ctrl->ctrl.async_event_work);
+ aen_op = ctrl->aen_ops;
+ for (i = 0; i < NVME_FC_NR_AEN_COMMANDS; i++, aen_op++) {
+ if (!aen_op->fcp_req.private)
+--
+2.25.1
+
--- /dev/null
+From 29fbb887186f03c49c08ad6282f9c2d8079f3540 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Sep 2020 12:18:19 +0900
+Subject: perf test: Free formats for perf pmu parse test
+
+From: Namhyung Kim <namhyung@kernel.org>
+
+[ Upstream commit d26383dcb2b4b8629fde05270b4e3633be9e3d4b ]
+
+The following leaks were detected by ASAN:
+
+ Indirect leak of 360 byte(s) in 9 object(s) allocated from:
+ #0 0x7fecc305180e in calloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10780e)
+ #1 0x560578f6dce5 in perf_pmu__new_format util/pmu.c:1333
+ #2 0x560578f752fc in perf_pmu_parse util/pmu.y:59
+ #3 0x560578f6a8b7 in perf_pmu__format_parse util/pmu.c:73
+ #4 0x560578e07045 in test__pmu tests/pmu.c:155
+ #5 0x560578de109b in run_test tests/builtin-test.c:410
+ #6 0x560578de109b in test_and_print tests/builtin-test.c:440
+ #7 0x560578de401a in __cmd_test tests/builtin-test.c:661
+ #8 0x560578de401a in cmd_test tests/builtin-test.c:807
+ #9 0x560578e49354 in run_builtin /home/namhyung/project/linux/tools/perf/perf.c:312
+ #10 0x560578ce71a8 in handle_internal_command /home/namhyung/project/linux/tools/perf/perf.c:364
+ #11 0x560578ce71a8 in run_argv /home/namhyung/project/linux/tools/perf/perf.c:408
+ #12 0x560578ce71a8 in main /home/namhyung/project/linux/tools/perf/perf.c:538
+ #13 0x7fecc2b7acc9 in __libc_start_main ../csu/libc-start.c:308
+
+Fixes: cff7f956ec4a1 ("perf tests: Move pmu tests into separate object")
+Signed-off-by: Namhyung Kim <namhyung@kernel.org>
+Acked-by: Jiri Olsa <jolsa@redhat.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Andi Kleen <ak@linux.intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Mark Rutland <mark.rutland@arm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Link: http://lore.kernel.org/lkml/20200915031819.386559-12-namhyung@kernel.org
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/tests/pmu.c | 1 +
+ tools/perf/util/pmu.c | 11 +++++++++++
+ tools/perf/util/pmu.h | 1 +
+ 3 files changed, 13 insertions(+)
+
+diff --git a/tools/perf/tests/pmu.c b/tools/perf/tests/pmu.c
+index 7bedf8608fdde..3e183eef6f857 100644
+--- a/tools/perf/tests/pmu.c
++++ b/tools/perf/tests/pmu.c
+@@ -172,6 +172,7 @@ int test__pmu(struct test *test __maybe_unused, int subtest __maybe_unused)
+ ret = 0;
+ } while (0);
+
++ perf_pmu__del_formats(&formats);
+ test_format_dir_put(format);
+ return ret;
+ }
+diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
+index 2deffc2349324..ca00b4104bc09 100644
+--- a/tools/perf/util/pmu.c
++++ b/tools/perf/util/pmu.c
+@@ -1100,6 +1100,17 @@ void perf_pmu__set_format(unsigned long *bits, long from, long to)
+ set_bit(b, bits);
+ }
+
++void perf_pmu__del_formats(struct list_head *formats)
++{
++ struct perf_pmu_format *fmt, *tmp;
++
++ list_for_each_entry_safe(fmt, tmp, formats, list) {
++ list_del(&fmt->list);
++ free(fmt->name);
++ free(fmt);
++ }
++}
++
+ static int sub_non_neg(int a, int b)
+ {
+ if (b > a)
+diff --git a/tools/perf/util/pmu.h b/tools/perf/util/pmu.h
+index eca99435f4a0b..59ad5de6601a7 100644
+--- a/tools/perf/util/pmu.h
++++ b/tools/perf/util/pmu.h
+@@ -79,6 +79,7 @@ int perf_pmu__new_format(struct list_head *list, char *name,
+ int config, unsigned long *bits);
+ void perf_pmu__set_format(unsigned long *bits, long from, long to);
+ int perf_pmu__format_parse(char *dir, struct list_head *head);
++void perf_pmu__del_formats(struct list_head *formats);
+
+ struct perf_pmu *perf_pmu__scan(struct perf_pmu *pmu);
+
+--
+2.25.1
+
--- /dev/null
+From d8d6952ba28981f9c5d56f1ee2ff2520e4c21e5b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 29 Jul 2020 01:19:40 +0300
+Subject: rapidio: Replace 'select' DMAENGINES 'with depends on'
+
+From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+
+[ Upstream commit d2b86100245080cfdf1e95e9e07477474c1be2bd ]
+
+Enabling a whole subsystem from a single driver 'select' is frowned
+upon and won't be accepted in new drivers, that need to use 'depends on'
+instead. Existing selection of DMAENGINES will then cause circular
+dependencies. Replace them with a dependency.
+
+Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Acked-by: Randy Dunlap <rdunlap@infradead.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/rapidio/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/rapidio/Kconfig b/drivers/rapidio/Kconfig
+index d6d2f20c45977..21df2816def76 100644
+--- a/drivers/rapidio/Kconfig
++++ b/drivers/rapidio/Kconfig
+@@ -25,7 +25,7 @@ config RAPIDIO_ENABLE_RX_TX_PORTS
+ config RAPIDIO_DMA_ENGINE
+ bool "DMA Engine support for RapidIO"
+ depends on RAPIDIO
+- select DMADEVICES
++ depends on DMADEVICES
+ select DMA_ENGINE
+ help
+ Say Y here if you want to use DMA Engine frameork for RapidIO data
+--
+2.25.1
+
--- /dev/null
+From a36873dec93299e2c7efe23de7506d699e535623 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 25 Aug 2020 02:39:40 -0700
+Subject: scsi: libfc: Fix for double free()
+
+From: Javed Hasan <jhasan@marvell.com>
+
+[ Upstream commit 5a5b80f98534416b3b253859897e2ba1dc241e70 ]
+
+Fix for '&fp->skb' double free.
+
+Link:
+https://lore.kernel.org/r/20200825093940.19612-1-jhasan@marvell.com
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Javed Hasan <jhasan@marvell.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/libfc/fc_disc.c | 2 --
+ 1 file changed, 2 deletions(-)
+
+diff --git a/drivers/scsi/libfc/fc_disc.c b/drivers/scsi/libfc/fc_disc.c
+index 62f83cc151b22..0db0d0ad9f966 100644
+--- a/drivers/scsi/libfc/fc_disc.c
++++ b/drivers/scsi/libfc/fc_disc.c
+@@ -658,8 +658,6 @@ free_fp:
+ fc_frame_free(fp);
+ out:
+ kref_put(&rdata->kref, fc_rport_destroy);
+- if (!IS_ERR(fp))
+- fc_frame_free(fp);
+ }
+
+ /**
+--
+2.25.1
+
--- /dev/null
+From 973e828f49991c443cac860caa47fb3c81370e11 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 28 Aug 2020 10:53:30 -0700
+Subject: scsi: lpfc: Fix FLOGI/PLOGI receive race condition in pt2pt discovery
+
+From: James Smart <james.smart@broadcom.com>
+
+[ Upstream commit 7b08e89f98cee9907895fabb64cf437bc505ce9a ]
+
+The driver is unable to successfully login with remote device. During pt2pt
+login, the driver completes its FLOGI request with the remote device having
+WWN precedence. The remote device issues its own (delayed) FLOGI after
+accepting the driver's and, upon transmitting the FLOGI, immediately
+recognizes it has already processed the driver's FLOGI thus it transitions
+to sending a PLOGI before waiting for an ACC to its FLOGI.
+
+In the driver, the FLOGI is received and an ACC sent, followed by the PLOGI
+being received and an ACC sent. The issue is that the PLOGI reception
+occurs before the response from the adapter from the FLOGI ACC is
+received. Processing of the PLOGI sets state flags to perform the REG_RPI
+mailbox command and proceed with the rest of discovery on the port. The
+same completion routine used by both FLOGI and PLOGI is generic in
+nature. One of the things it does is clear flags, and those flags happen to
+drive the rest of discovery. So what happened was the PLOGI processing set
+the flags, the FLOGI ACC completion cleared them, thus when the PLOGI ACC
+completes it doesn't see the flags and stops.
+
+Fix by modifying the generic completion routine to not clear the rest of
+discovery flag (NLP_ACC_REGLOGIN) unless the completion is also associated
+with performing a mailbox command as part of its handling. For things such
+as FLOGI ACC, there isn't a subsequent action to perform with the adapter,
+thus there is no mailbox cmd ptr. PLOGI ACC though will perform REG_RPI
+upon completion, thus there is a mailbox cmd ptr.
+
+Link: https://lore.kernel.org/r/20200828175332.130300-3-james.smart@broadcom.com
+Co-developed-by: Dick Kennedy <dick.kennedy@broadcom.com>
+Signed-off-by: Dick Kennedy <dick.kennedy@broadcom.com>
+Signed-off-by: James Smart <james.smart@broadcom.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/lpfc/lpfc_els.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/lpfc/lpfc_els.c b/drivers/scsi/lpfc/lpfc_els.c
+index db1111f7e85ae..566e8d07cb058 100644
+--- a/drivers/scsi/lpfc/lpfc_els.c
++++ b/drivers/scsi/lpfc/lpfc_els.c
+@@ -4104,7 +4104,9 @@ lpfc_cmpl_els_rsp(struct lpfc_hba *phba, struct lpfc_iocbq *cmdiocb,
+ out:
+ if (ndlp && NLP_CHK_NODE_ACT(ndlp) && shost) {
+ spin_lock_irq(shost->host_lock);
+- ndlp->nlp_flag &= ~(NLP_ACC_REGLOGIN | NLP_RM_DFLT_RPI);
++ if (mbox)
++ ndlp->nlp_flag &= ~NLP_ACC_REGLOGIN;
++ ndlp->nlp_flag &= ~NLP_RM_DFLT_RPI;
+ spin_unlock_irq(shost->host_lock);
+
+ /* If the node is not being used by another discovery thread,
+--
+2.25.1
+
--- /dev/null
+From 80f8a241278c23dbbc2f23b760906d6bd65d669b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 23 Aug 2020 17:14:53 +0800
+Subject: scsi: pm8001: Fix memleak in pm8001_exec_internal_task_abort
+
+From: Dinghao Liu <dinghao.liu@zju.edu.cn>
+
+[ Upstream commit ea403fde7552bd61bad6ea45e3feb99db77cb31e ]
+
+When pm8001_tag_alloc() fails, task should be freed just like it is done in
+the subsequent error paths.
+
+Link: https://lore.kernel.org/r/20200823091453.4782-1-dinghao.liu@zju.edu.cn
+Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>
+Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/pm8001/pm8001_sas.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/scsi/pm8001/pm8001_sas.c b/drivers/scsi/pm8001/pm8001_sas.c
+index e64a13f0bce17..61a2da30f94b7 100644
+--- a/drivers/scsi/pm8001/pm8001_sas.c
++++ b/drivers/scsi/pm8001/pm8001_sas.c
+@@ -795,7 +795,7 @@ pm8001_exec_internal_task_abort(struct pm8001_hba_info *pm8001_ha,
+
+ res = pm8001_tag_alloc(pm8001_ha, &ccb_tag);
+ if (res)
+- return res;
++ goto ex_err;
+ ccb = &pm8001_ha->ccb_info[ccb_tag];
+ ccb->device = pm8001_dev;
+ ccb->ccb_tag = ccb_tag;
+--
+2.25.1
+
gfs2-initialize-transaction-tr_ailx_lists-earlier.patch
net-handle-the-return-value-of-pskb_carve_frag_list-correctly.patch
hv_netvsc-remove-unlikely-from-netvsc_select_queue.patch
+nfsv4.1-handle-err_delay-error-reclaiming-locking-st.patch
+scsi-pm8001-fix-memleak-in-pm8001_exec_internal_task.patch
+scsi-libfc-fix-for-double-free.patch
+scsi-lpfc-fix-flogi-plogi-receive-race-condition-in-.patch
+spi-spi-loopback-test-fix-out-of-bounds-read.patch
+sunrpc-stop-printk-reading-past-end-of-string.patch
+rapidio-replace-select-dmaengines-with-depends-on.patch
+nvme-fc-cancel-async-events-before-freeing-event-str.patch
+f2fs-fix-indefinite-loop-scanning-for-free-nid.patch
+i2c-algo-pca-reapply-i2c-bus-settings-after-reset.patch
+spi-fix-memory-leak-on-splited-transfers.patch
+kvm-mips-change-the-definition-of-kvm-type.patch
+clk-rockchip-fix-initialization-of-mux_pll_src_4plls.patch
+drivers-hv-vmbus-add-timeout-to-vmbus_wait_for_unloa.patch
+mips-sni-fix-mips_l1_cache_shift.patch
+perf-test-free-formats-for-perf-pmu-parse-test.patch
+fbcon-fix-user-font-detection-test-at-fbcon_resize.patch
+mips-sni-fix-spurious-interrupts.patch
+drm-mediatek-add-exception-handing-in-mtk_drm_probe-.patch
+drm-mediatek-add-missing-put_device-call-in-mtk_hdmi.patch
--- /dev/null
+From 2b050d209378e3876e9729d941c0a037cdaca00a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Sep 2020 17:11:29 +0200
+Subject: spi: Fix memory leak on splited transfers
+
+From: Gustav Wiklander <gustavwi@axis.com>
+
+[ Upstream commit b59a7ca15464c78ea1ba3b280cfc5ac5ece11ade ]
+
+In the prepare_message callback the bus driver has the
+opportunity to split a transfer into smaller chunks.
+spi_map_msg is done after prepare_message.
+
+Function spi_res_release releases the splited transfers
+in the message. Therefore spi_res_release should be called
+after spi_map_msg.
+
+The previous try at this was commit c9ba7a16d0f1
+which released the splited transfers after
+spi_finalize_current_message had been called.
+This introduced a race since the message struct could be
+out of scope because the spi_sync call got completed.
+
+Fixes this leak on spi bus driver spi-bcm2835.c when transfer
+size is greater than 65532:
+
+Kmemleak:
+sg_alloc_table+0x28/0xc8
+spi_map_buf+0xa4/0x300
+__spi_pump_messages+0x370/0x748
+__spi_sync+0x1d4/0x270
+spi_sync+0x34/0x58
+spi_test_execute_msg+0x60/0x340 [spi_loopback_test]
+spi_test_run_iter+0x548/0x578 [spi_loopback_test]
+spi_test_run_test+0x94/0x140 [spi_loopback_test]
+spi_test_run_tests+0x150/0x180 [spi_loopback_test]
+spi_loopback_test_probe+0x50/0xd0 [spi_loopback_test]
+spi_drv_probe+0x84/0xe0
+
+Signed-off-by: Gustav Wiklander <gustavwi@axis.com>
+Link: https://lore.kernel.org/r/20200908151129.15915-1-gustav.wiklander@axis.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
+index ab6a4f85bcde7..acc8eeed73f07 100644
+--- a/drivers/spi/spi.c
++++ b/drivers/spi/spi.c
+@@ -1125,8 +1125,6 @@ out:
+ if (msg->status && ctlr->handle_err)
+ ctlr->handle_err(ctlr, msg);
+
+- spi_res_release(ctlr, msg);
+-
+ spi_finalize_current_message(ctlr);
+
+ return ret;
+@@ -1384,6 +1382,13 @@ void spi_finalize_current_message(struct spi_controller *ctlr)
+
+ spi_unmap_msg(ctlr, mesg);
+
++ /* In the prepare_messages callback the spi bus has the opportunity to
++ * split a transfer to smaller chunks.
++ * Release splited transfers here since spi_map_msg is done on the
++ * splited transfers.
++ */
++ spi_res_release(ctlr, mesg);
++
+ if (ctlr->cur_msg_prepared && ctlr->unprepare_message) {
+ ret = ctlr->unprepare_message(ctlr, mesg);
+ if (ret) {
+--
+2.25.1
+
--- /dev/null
+From e63b8b506934e1c913837acb67428f0aff673e7b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Sep 2020 15:23:41 +0200
+Subject: spi: spi-loopback-test: Fix out-of-bounds read
+
+From: Vincent Whitchurch <vincent.whitchurch@axis.com>
+
+[ Upstream commit 837ba18dfcd4db21ad58107c65bfe89753aa56d7 ]
+
+The "tx/rx-transfer - crossing PAGE_SIZE" test always fails when
+len=131071 and rx_offset >= 5:
+
+ spi-loopback-test spi0.0: Running test tx/rx-transfer - crossing PAGE_SIZE
+ ...
+ with iteration values: len = 131071, tx_off = 0, rx_off = 3
+ with iteration values: len = 131071, tx_off = 0, rx_off = 4
+ with iteration values: len = 131071, tx_off = 0, rx_off = 5
+ loopback strangeness - rx changed outside of allowed range at: ...a4321000
+ spi_msg@ffffffd5a4157690
+ frame_length: 131071
+ actual_length: 131071
+ spi_transfer@ffffffd5a41576f8
+ len: 131071
+ tx_buf: ffffffd5a4340ffc
+
+Note that rx_offset > 3 can only occur if the SPI controller driver sets
+->dma_alignment to a higher value than 4, so most SPI controller drivers
+are not affect.
+
+The allocated Rx buffer is of size SPI_TEST_MAX_SIZE_PLUS, which is 132
+KiB (assuming 4 KiB pages). This test uses an initial offset into the
+rx_buf of PAGE_SIZE - 4, and a len of 131071, so the range expected to
+be written in this transfer ends at (4096 - 4) + 5 + 131071 == 132 KiB,
+which is also the end of the allocated buffer. But the code which
+verifies the content of the buffer reads a byte beyond the allocated
+buffer and spuriously fails because this out-of-bounds read doesn't
+return the expected value.
+
+Fix this by using ITERATE_LEN instead of ITERATE_MAX_LEN to avoid
+testing sizes which cause out-of-bounds reads.
+
+Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
+Link: https://lore.kernel.org/r/20200902132341.7079-1-vincent.whitchurch@axis.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/spi/spi-loopback-test.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
+index bed7403bb6b3a..b9a7117b6dce3 100644
+--- a/drivers/spi/spi-loopback-test.c
++++ b/drivers/spi/spi-loopback-test.c
+@@ -99,7 +99,7 @@ static struct spi_test spi_tests[] = {
+ {
+ .description = "tx/rx-transfer - crossing PAGE_SIZE",
+ .fill_option = FILL_COUNT_8,
+- .iterate_len = { ITERATE_MAX_LEN },
++ .iterate_len = { ITERATE_LEN },
+ .iterate_tx_align = ITERATE_ALIGN,
+ .iterate_rx_align = ITERATE_ALIGN,
+ .transfer_count = 1,
+--
+2.25.1
+
--- /dev/null
+From c8a875ec4f78510e03da35274e9dcc253a65420d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 5 Sep 2020 10:03:26 -0400
+Subject: SUNRPC: stop printk reading past end of string
+
+From: J. Bruce Fields <bfields@redhat.com>
+
+[ Upstream commit 8c6b6c793ed32b8f9770ebcdf1ba99af423c303b ]
+
+Since p points at raw xdr data, there's no guarantee that it's NULL
+terminated, so we should give a length. And probably escape any special
+characters too.
+
+Reported-by: Zhi Li <yieli@redhat.com>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/sunrpc/rpcb_clnt.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/net/sunrpc/rpcb_clnt.c b/net/sunrpc/rpcb_clnt.c
+index da21efac80f4a..7c0b1feb36299 100644
+--- a/net/sunrpc/rpcb_clnt.c
++++ b/net/sunrpc/rpcb_clnt.c
+@@ -981,8 +981,8 @@ static int rpcb_dec_getaddr(struct rpc_rqst *req, struct xdr_stream *xdr,
+ p = xdr_inline_decode(xdr, len);
+ if (unlikely(p == NULL))
+ goto out_fail;
+- dprintk("RPC: %5u RPCB_%s reply: %s\n", req->rq_task->tk_pid,
+- req->rq_task->tk_msg.rpc_proc->p_name, (char *)p);
++ dprintk("RPC: %5u RPCB_%s reply: %*pE\n", req->rq_task->tk_pid,
++ req->rq_task->tk_msg.rpc_proc->p_name, len, (char *)p);
+
+ if (rpc_uaddr2sockaddr(req->rq_xprt->xprt_net, (char *)p, len,
+ sap, sizeof(address)) == 0)
+--
+2.25.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
