--- /dev/null
+From 70f7a1a3f0e917b0e7ee9b5bb331e2dc0de19f2b Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig <hch@lst.de>
+Date: Thu, 11 Jul 2019 20:55:26 -0700
+Subject: 9p: pass the correct prototype to read_cache_page
+
+[ Upstream commit f053cbd4366051d7eb6ba1b8d529d20f719c2963 ]
+
+Fix the callback 9p passes to read_cache_page to actually have the
+proper type expected. Casting around function pointers can easily
+hide typing bugs, and defeats control flow protection.
+
+Link: http://lkml.kernel.org/r/20190520055731.24538-5-hch@lst.de
+Signed-off-by: Christoph Hellwig <hch@lst.de>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Cc: Sami Tolvanen <samitolvanen@google.com>
+Cc: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/9p/vfs_addr.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
+index 6181ad79e1a5..e45b1a0dd513 100644
+--- a/fs/9p/vfs_addr.c
++++ b/fs/9p/vfs_addr.c
+@@ -49,8 +49,9 @@
+ * @page: structure to page
+ *
+ */
+-static int v9fs_fid_readpage(struct p9_fid *fid, struct page *page)
++static int v9fs_fid_readpage(void *data, struct page *page)
+ {
++ struct p9_fid *fid = data;
+ struct inode *inode = page->mapping->host;
+ struct bio_vec bvec = {.bv_page = page, .bv_len = PAGE_SIZE};
+ struct iov_iter to;
+@@ -121,7 +122,8 @@ static int v9fs_vfs_readpages(struct file *filp, struct address_space *mapping,
+ if (ret == 0)
+ return ret;
+
+- ret = read_cache_pages(mapping, pages, (void *)v9fs_vfs_readpage, filp);
++ ret = read_cache_pages(mapping, pages, v9fs_fid_readpage,
++ filp->private_data);
+ p9_debug(P9_DEBUG_VFS, " = %d\n", ret);
+ return ret;
+ }
+--
+2.20.1
+
--- /dev/null
+From 8015f0151b64946db3a6c5bfb20611ebfcd95a5d Mon Sep 17 00:00:00 2001
+From: Jyri Sarha <jsarha@ti.com>
+Date: Mon, 27 May 2019 16:47:54 +0300
+Subject: drm/bridge: sii902x: pixel clock unit is 10kHz instead of 1kHz
+
+[ Upstream commit 8dbfc5b65023b67397aca28e8adb25c819f6398c ]
+
+The pixel clock unit in the first two registers (0x00 and 0x01) of
+sii9022 is 10kHz, not 1kHz as in struct drm_display_mode. Division by
+10 fixes the issue.
+
+Signed-off-by: Jyri Sarha <jsarha@ti.com>
+Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/1a2a8eae0b9d6333e7a5841026bf7fd65c9ccd09.1558964241.git.jsarha@ti.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/bridge/sii902x.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/gpu/drm/bridge/sii902x.c b/drivers/gpu/drm/bridge/sii902x.c
+index 9126d0306ab5..51e2d03995a1 100644
+--- a/drivers/gpu/drm/bridge/sii902x.c
++++ b/drivers/gpu/drm/bridge/sii902x.c
+@@ -250,10 +250,11 @@ static void sii902x_bridge_mode_set(struct drm_bridge *bridge,
+ struct regmap *regmap = sii902x->regmap;
+ u8 buf[HDMI_INFOFRAME_SIZE(AVI)];
+ struct hdmi_avi_infoframe frame;
++ u16 pixel_clock_10kHz = adj->clock / 10;
+ int ret;
+
+- buf[0] = adj->clock;
+- buf[1] = adj->clock >> 8;
++ buf[0] = pixel_clock_10kHz & 0xff;
++ buf[1] = pixel_clock_10kHz >> 8;
+ buf[2] = adj->vrefresh;
+ buf[3] = 0x00;
+ buf[4] = adj->hdisplay;
+--
+2.20.1
+
--- /dev/null
+From b46a5b5dd208f2faa6b0315f6898ae9c08d0aa7b Mon Sep 17 00:00:00 2001
+From: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Date: Tue, 28 May 2019 11:27:44 +0300
+Subject: drm/bridge: tc358767: read display_props in get_modes()
+
+[ Upstream commit 3231573065ad4f4ecc5c9147b24f29f846dc0c2f ]
+
+We need to know the link bandwidth to filter out modes we cannot
+support, so we need to have read the display props before doing the
+filtering.
+
+To ensure we have up to date display props, call tc_get_display_props()
+in the beginning of tc_connector_get_modes().
+
+Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
+Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
+Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190528082747.3631-22-tomi.valkeinen@ti.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/bridge/tc358767.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c
+index fa3f2f039a74..80993a8734e0 100644
+--- a/drivers/gpu/drm/bridge/tc358767.c
++++ b/drivers/gpu/drm/bridge/tc358767.c
+@@ -1153,6 +1153,13 @@ static int tc_connector_get_modes(struct drm_connector *connector)
+ struct tc_data *tc = connector_to_tc(connector);
+ struct edid *edid;
+ unsigned int count;
++ int ret;
++
++ ret = tc_get_display_props(tc);
++ if (ret < 0) {
++ dev_err(tc->dev, "failed to read display props: %d\n", ret);
++ return 0;
++ }
+
+ if (tc->panel && tc->panel->funcs && tc->panel->funcs->get_modes) {
+ count = tc->panel->funcs->get_modes(tc->panel);
+--
+2.20.1
+
--- /dev/null
+From f350650f49cec08881646ff7d72fd594bc3a8b61 Mon Sep 17 00:00:00 2001
+From: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Date: Tue, 26 Feb 2019 10:11:53 +0200
+Subject: drm/panel: simple: Fix panel_simple_dsi_probe
+
+[ Upstream commit 7ad9db66fafb0f0ad53fd2a66217105da5ddeffe ]
+
+In case mipi_dsi_attach() fails remove the registered panel to avoid added
+panel without corresponding device.
+
+Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
+Signed-off-by: Thierry Reding <treding@nvidia.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190226081153.31334-1-peter.ujfalusi@ti.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/panel/panel-simple.c | 9 ++++++++-
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
+index 5b2a9f97ff04..68a2b25deb50 100644
+--- a/drivers/gpu/drm/panel/panel-simple.c
++++ b/drivers/gpu/drm/panel/panel-simple.c
+@@ -1944,7 +1944,14 @@ static int panel_simple_dsi_probe(struct mipi_dsi_device *dsi)
+ dsi->format = desc->format;
+ dsi->lanes = desc->lanes;
+
+- return mipi_dsi_attach(dsi);
++ err = mipi_dsi_attach(dsi);
++ if (err) {
++ struct panel_simple *panel = dev_get_drvdata(&dsi->dev);
++
++ drm_panel_remove(&panel->base);
++ }
++
++ return err;
+ }
+
+ static int panel_simple_dsi_remove(struct mipi_dsi_device *dsi)
+--
+2.20.1
+
--- /dev/null
+From 70fb97aaa5906ddf3309661adc1ee60aecc5a892 Mon Sep 17 00:00:00 2001
+From: Douglas Anderson <dianders@chromium.org>
+Date: Fri, 14 Jun 2019 15:47:29 -0700
+Subject: drm/rockchip: Properly adjust to a true clock in adjusted_mode
+
+[ Upstream commit 99b9683f2142b20bad78e61f7f829e8714e45685 ]
+
+When fixing up the clock in vop_crtc_mode_fixup() we're not doing it
+quite correctly. Specifically if we've got the true clock 266666667 Hz,
+we'll perform this calculation:
+ 266666667 / 1000 => 266666
+
+Later when we try to set the clock we'll do clk_set_rate(266666 *
+1000). The common clock framework won't actually pick the proper clock
+in this case since it always wants clocks <= the specified one.
+
+Let's solve this by using DIV_ROUND_UP.
+
+Fixes: b59b8de31497 ("drm/rockchip: return a true clock rate to adjusted_mode")
+Signed-off-by: Douglas Anderson <dianders@chromium.org>
+Signed-off-by: Sean Paul <seanpaul@chromium.org>
+Reviewed-by: Yakir Yang <ykk@rock-chips.com>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Link: https://patchwork.freedesktop.org/patch/msgid/20190614224730.98622-1-dianders@chromium.org
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+index 32d87c6035c9..5bed63eee5f0 100644
+--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
++++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+@@ -865,7 +865,8 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
+ struct vop *vop = to_vop(crtc);
+
+ adjusted_mode->clock =
+- clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
++ DIV_ROUND_UP(clk_round_rate(vop->dclk, mode->clock * 1000),
++ 1000);
+
+ return true;
+ }
+--
+2.20.1
+
--- /dev/null
+From 6620a8120bcf51b3fc366ec5239c6e1f5e61ce97 Mon Sep 17 00:00:00 2001
+From: David Riley <davidriley@chromium.org>
+Date: Mon, 10 Jun 2019 14:18:10 -0700
+Subject: drm/virtio: Add memory barriers for capset cache.
+
+[ Upstream commit 9ff3a5c88e1f1ab17a31402b96d45abe14aab9d7 ]
+
+After data is copied to the cache entry, atomic_set is used indicate
+that the data is the entry is valid without appropriate memory barriers.
+Similarly the read side was missing the corresponding memory barriers.
+
+Signed-off-by: David Riley <davidriley@chromium.org>
+Link: http://patchwork.freedesktop.org/patch/msgid/20190610211810.253227-5-davidriley@chromium.org
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 3 +++
+ drivers/gpu/drm/virtio/virtgpu_vq.c | 2 ++
+ 2 files changed, 5 insertions(+)
+
+diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+index 54639395aba0..a3559b1a3a0f 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
++++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c
+@@ -521,6 +521,9 @@ static int virtio_gpu_get_caps_ioctl(struct drm_device *dev,
+ ret = wait_event_timeout(vgdev->resp_wq,
+ atomic_read(&cache_ent->is_valid), 5 * HZ);
+
++ /* is_valid check must proceed before copy of the cache entry. */
++ smp_rmb();
++
+ ptr = cache_ent->caps_cache;
+
+ copy_exit:
+diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c
+index 52436b3c01bb..a1b3ea1ccb65 100644
+--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
++++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
+@@ -618,6 +618,8 @@ static void virtio_gpu_cmd_capset_cb(struct virtio_gpu_device *vgdev,
+ cache_ent->id == le32_to_cpu(cmd->capset_id)) {
+ memcpy(cache_ent->caps_cache, resp->capset_data,
+ cache_ent->size);
++ /* Copy must occur before is_valid is signalled. */
++ smp_wmb();
+ atomic_set(&cache_ent->is_valid, 1);
+ break;
+ }
+--
+2.20.1
+
--- /dev/null
+From 00d483e6c84d8caf418680fe8b5d32eed3238913 Mon Sep 17 00:00:00 2001
+From: Ocean Chen <oceanchen@google.com>
+Date: Mon, 8 Jul 2019 12:34:56 +0800
+Subject: f2fs: avoid out-of-range memory access
+
+[ Upstream commit 56f3ce675103e3fb9e631cfb4131fc768bc23e9a ]
+
+blkoff_off might over 512 due to fs corrupt or security
+vulnerability. That should be checked before being using.
+
+Use ENTRIES_IN_SUM to protect invalid value in cur_data_blkoff.
+
+Signed-off-by: Ocean Chen <oceanchen@google.com>
+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/segment.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
+index 2fb99a081de8..c983f7d28f03 100644
+--- a/fs/f2fs/segment.c
++++ b/fs/f2fs/segment.c
+@@ -1709,6 +1709,11 @@ static int read_compacted_summaries(struct f2fs_sb_info *sbi)
+ seg_i = CURSEG_I(sbi, i);
+ segno = le32_to_cpu(ckpt->cur_data_segno[i]);
+ blk_off = le16_to_cpu(ckpt->cur_data_blkoff[i]);
++ if (blk_off > ENTRIES_IN_SUM) {
++ f2fs_bug_on(sbi, 1);
++ f2fs_put_page(page, 1);
++ return -EFAULT;
++ }
+ seg_i->next_segno = segno;
+ reset_curseg(sbi, i, 0);
+ seg_i->alloc_type = ckpt->alloc_type[i];
+--
+2.20.1
+
--- /dev/null
+From f50e563d343ddfd04c296ff40b1a4c4d016bffab Mon Sep 17 00:00:00 2001
+From: Bastien Nocera <hadess@hadess.net>
+Date: Thu, 27 Jun 2019 09:20:45 +0200
+Subject: iio: iio-utils: Fix possible incorrect mask calculation
+
+[ Upstream commit 208a68c8393d6041a90862992222f3d7943d44d6 ]
+
+On some machines, iio-sensor-proxy was returning all 0's for IIO sensor
+values. It turns out that the bits_used for this sensor is 32, which makes
+the mask calculation:
+
+*mask = (1 << 32) - 1;
+
+If the compiler interprets the 1 literals as 32-bit ints, it generates
+undefined behavior depending on compiler version and optimization level.
+On my system, it optimizes out the shift, so the mask value becomes
+
+*mask = (1) - 1;
+
+With a mask value of 0, iio-sensor-proxy will always return 0 for every axis.
+
+Avoid incorrect 0 values caused by compiler optimization.
+
+See original fix by Brett Dutro <brett.dutro@gmail.com> in
+iio-sensor-proxy:
+https://github.com/hadess/iio-sensor-proxy/commit/9615ceac7c134d838660e209726cd86aa2064fd3
+
+Signed-off-by: Bastien Nocera <hadess@hadess.net>
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/iio/iio_utils.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
+index 7a6d61c6c012..55272fef3b50 100644
+--- a/tools/iio/iio_utils.c
++++ b/tools/iio/iio_utils.c
+@@ -159,9 +159,9 @@ int iioutils_get_type(unsigned *is_signed, unsigned *bytes, unsigned *bits_used,
+ *be = (endianchar == 'b');
+ *bytes = padint / 8;
+ if (*bits_used == 64)
+- *mask = ~0;
++ *mask = ~(0ULL);
+ else
+- *mask = (1ULL << *bits_used) - 1;
++ *mask = (1ULL << *bits_used) - 1ULL;
+
+ *is_signed = (signchar == 's');
+ if (fclose(sysfsfp)) {
+--
+2.20.1
+
--- /dev/null
+From d064536a50a20168a90c57a5a96abd4d02bc93e9 Mon Sep 17 00:00:00 2001
+From: Vasily Gorbik <gor@linux.ibm.com>
+Date: Fri, 28 Jun 2019 19:22:47 +0200
+Subject: kallsyms: exclude kasan local symbols on s390
+
+[ Upstream commit 33177f01ca3fe550146bb9001bec2fd806b2f40c ]
+
+gcc asan instrumentation emits the following sequence to store frame pc
+when the kernel is built with CONFIG_RELOCATABLE:
+debug/vsprintf.s:
+ .section .data.rel.ro.local,"aw"
+ .align 8
+.LC3:
+ .quad .LASANPC4826@GOTOFF
+.text
+ .align 8
+ .type number, @function
+number:
+.LASANPC4826:
+
+and in case reloc is issued for LASANPC label it also gets into .symtab
+with the same address as actual function symbol:
+$ nm -n vmlinux | grep 0000000001397150
+0000000001397150 t .LASANPC4826
+0000000001397150 t number
+
+In the end kernel backtraces are almost unreadable:
+[ 143.748476] Call Trace:
+[ 143.748484] ([<000000002da3e62c>] .LASANPC2671+0x114/0x190)
+[ 143.748492] [<000000002eca1a58>] .LASANPC2612+0x110/0x160
+[ 143.748502] [<000000002de9d830>] print_address_description+0x80/0x3b0
+[ 143.748511] [<000000002de9dd64>] __kasan_report+0x15c/0x1c8
+[ 143.748521] [<000000002ecb56d4>] strrchr+0x34/0x60
+[ 143.748534] [<000003ff800a9a40>] kasan_strings+0xb0/0x148 [test_kasan]
+[ 143.748547] [<000003ff800a9bba>] kmalloc_tests_init+0xe2/0x528 [test_kasan]
+[ 143.748555] [<000000002da2117c>] .LASANPC4069+0x354/0x748
+[ 143.748563] [<000000002dbfbb16>] do_init_module+0x136/0x3b0
+[ 143.748571] [<000000002dbff3f4>] .LASANPC3191+0x2164/0x25d0
+[ 143.748580] [<000000002dbffc4c>] .LASANPC3196+0x184/0x1b8
+[ 143.748587] [<000000002ecdf2ec>] system_call+0xd8/0x2d8
+
+Since LASANPC labels are not even unique and get into .symtab only due
+to relocs filter them out in kallsyms.
+
+Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/kallsyms.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/scripts/kallsyms.c b/scripts/kallsyms.c
+index 1f22a186c18c..2c8b8c662da5 100644
+--- a/scripts/kallsyms.c
++++ b/scripts/kallsyms.c
+@@ -161,6 +161,9 @@ static int read_symbol(FILE *in, struct sym_entry *s)
+ /* exclude debugging symbols */
+ else if (stype == 'N')
+ return -1;
++ /* exclude s390 kasan local symbols */
++ else if (!strncmp(sym, ".LASANPC", 8))
++ return -1;
+
+ /* include the type field in the symbol name, so that it gets
+ * compressed together */
+--
+2.20.1
+
--- /dev/null
+From 05124a543e40f59bb3ff35cfb82ff7a426db2c44 Mon Sep 17 00:00:00 2001
+From: Nathan Chancellor <natechancellor@gmail.com>
+Date: Tue, 11 Jun 2019 11:43:31 -0700
+Subject: kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS
+
+[ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ]
+
+In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI
+drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
+a GCC only option so clang rightfully complains:
+
+warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
+
+https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
+
+However, by default, this is merely a warning so the build happily goes
+on with a slew of these warnings in the process.
+
+Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to
+support clang") worked around this behavior in cc-option by adding
+-Werror so that unknown flags cause an error. However, this all happens
+silently and when an unknown flag is added to the build unconditionally
+like -Wno-psabi, cc-option will always fail because there is always an
+unknown flag in the list of flags. This manifested as link time failures
+in the arm64 libstub because -fno-stack-protector didn't get added to
+KBUILD_CFLAGS.
+
+To avoid these weird cryptic failures in the future, make clang behave
+like gcc and immediately error when it encounters an unknown flag by
+adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
+unconditionally for clang because it is supported by at least 3.0.0,
+according to godbolt [1] and 4.0.0, according to its documentation [2],
+which is far earlier than we typically support.
+
+[1]: https://godbolt.org/z/7F7rm3
+[2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/511
+Link: https://github.com/ClangBuiltLinux/linux/issues/517
+Suggested-by: Peter Smith <peter.smith@linaro.org>
+Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
+Tested-by: Nick Desaulniers <ndesaulniers@google.com>
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ Makefile | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Makefile b/Makefile
+index 1ab22a85118f..03ff09d789b4 100644
+--- a/Makefile
++++ b/Makefile
+@@ -515,6 +515,7 @@ ifneq ($(GCC_TOOLCHAIN),)
+ CLANG_FLAGS += --gcc-toolchain=$(GCC_TOOLCHAIN)
+ endif
+ CLANG_FLAGS += -no-integrated-as
++CLANG_FLAGS += -Werror=unknown-warning-option
+ KBUILD_CFLAGS += $(CLANG_FLAGS)
+ KBUILD_AFLAGS += $(CLANG_FLAGS)
+ endif
+--
+2.20.1
+
--- /dev/null
+From 5d8f043dae9f212a2a9f321b33427c36b7c6f826 Mon Sep 17 00:00:00 2001
+From: Yuyang Du <duyuyang@gmail.com>
+Date: Tue, 9 Jul 2019 18:15:22 +0800
+Subject: locking/lockdep: Fix lock used or unused stats error
+
+[ Upstream commit 68d41d8c94a31dfb8233ab90b9baf41a2ed2da68 ]
+
+The stats variable nr_unused_locks is incremented every time a new lock
+class is register and decremented when the lock is first used in
+__lock_acquire(). And after all, it is shown and checked in lockdep_stats.
+
+However, under configurations that either CONFIG_TRACE_IRQFLAGS or
+CONFIG_PROVE_LOCKING is not defined:
+
+The commit:
+
+ 091806515124b20 ("locking/lockdep: Consolidate lock usage bit initialization")
+
+missed marking the LOCK_USED flag at IRQ usage initialization because
+as mark_usage() is not called. And the commit:
+
+ 886532aee3cd42d ("locking/lockdep: Move mark_lock() inside CONFIG_TRACE_IRQFLAGS && CONFIG_PROVE_LOCKING")
+
+further made mark_lock() not defined such that the LOCK_USED cannot be
+marked at all when the lock is first acquired.
+
+As a result, we fix this by not showing and checking the stats under such
+configurations for lockdep_stats.
+
+Reported-by: Qian Cai <cai@lca.pw>
+Signed-off-by: Yuyang Du <duyuyang@gmail.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: arnd@arndb.de
+Cc: frederic@kernel.org
+Link: https://lkml.kernel.org/r/20190709101522.9117-1-duyuyang@gmail.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/locking/lockdep_proc.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
+index a0f61effad25..c482de6f5262 100644
+--- a/kernel/locking/lockdep_proc.c
++++ b/kernel/locking/lockdep_proc.c
+@@ -229,6 +229,7 @@ static int lockdep_stats_show(struct seq_file *m, void *v)
+ nr_hardirq_read_safe = 0, nr_hardirq_read_unsafe = 0,
+ sum_forward_deps = 0;
+
++#ifdef CONFIG_PROVE_LOCKING
+ list_for_each_entry(class, &all_lock_classes, lock_entry) {
+
+ if (class->usage_mask == 0)
+@@ -260,12 +261,12 @@ static int lockdep_stats_show(struct seq_file *m, void *v)
+ if (class->usage_mask & LOCKF_ENABLED_HARDIRQ_READ)
+ nr_hardirq_read_unsafe++;
+
+-#ifdef CONFIG_PROVE_LOCKING
+ sum_forward_deps += lockdep_count_forward_deps(class);
+-#endif
+ }
+ #ifdef CONFIG_DEBUG_LOCKDEP
+ DEBUG_LOCKS_WARN_ON(debug_atomic_read(nr_unused_locks) != nr_unused);
++#endif
++
+ #endif
+ seq_printf(m, " lock-classes: %11lu [max: %lu]\n",
+ nr_lock_classes, MAX_LOCKDEP_KEYS);
+--
+2.20.1
+
--- /dev/null
+From 617b6a14b38c942370b7fcf7b0511cc9cadb4dd5 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 15 Jul 2019 11:27:49 +0200
+Subject: locking/lockdep: Hide unused 'class' variable
+
+[ Upstream commit 68037aa78208f34bda4e5cd76c357f718b838cbb ]
+
+The usage is now hidden in an #ifdef, so we need to move
+the variable itself in there as well to avoid this warning:
+
+ kernel/locking/lockdep_proc.c:203:21: error: unused variable 'class' [-Werror,-Wunused-variable]
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Bart Van Assche <bvanassche@acm.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Qian Cai <cai@lca.pw>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Waiman Long <longman@redhat.com>
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: Will Deacon <will@kernel.org>
+Cc: Yuyang Du <duyuyang@gmail.com>
+Cc: frederic@kernel.org
+Fixes: 68d41d8c94a3 ("locking/lockdep: Fix lock used or unused stats error")
+Link: https://lkml.kernel.org/r/20190715092809.736834-1-arnd@arndb.de
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/locking/lockdep_proc.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/kernel/locking/lockdep_proc.c b/kernel/locking/lockdep_proc.c
+index c482de6f5262..75d80809c48c 100644
+--- a/kernel/locking/lockdep_proc.c
++++ b/kernel/locking/lockdep_proc.c
+@@ -219,7 +219,6 @@ static void lockdep_stats_debug_show(struct seq_file *m)
+
+ static int lockdep_stats_show(struct seq_file *m, void *v)
+ {
+- struct lock_class *class;
+ unsigned long nr_unused = 0, nr_uncategorized = 0,
+ nr_irq_safe = 0, nr_irq_unsafe = 0,
+ nr_softirq_safe = 0, nr_softirq_unsafe = 0,
+@@ -230,6 +229,8 @@ static int lockdep_stats_show(struct seq_file *m, void *v)
+ sum_forward_deps = 0;
+
+ #ifdef CONFIG_PROVE_LOCKING
++ struct lock_class *class;
++
+ list_for_each_entry(class, &all_lock_classes, lock_entry) {
+
+ if (class->usage_mask == 0)
+--
+2.20.1
+
--- /dev/null
+From c602116d772e1119373485fd86bed812aab7c465 Mon Sep 17 00:00:00 2001
+From: morten petersen <morten_bp@live.dk>
+Date: Mon, 8 Jul 2019 11:41:54 +0000
+Subject: mailbox: handle failed named mailbox channel request
+
+[ Upstream commit 25777e5784a7b417967460d4fcf9660d05a0c320 ]
+
+Previously, if mbox_request_channel_byname was used with a name
+which did not exist in the "mbox-names" property of a mailbox
+client, the mailbox corresponding to the last entry in the
+"mbox-names" list would be incorrectly selected.
+With this patch, -EINVAL is returned if the named mailbox is
+not found.
+
+Signed-off-by: Morten Borup Petersen <morten_bp@live.dk>
+Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mailbox/mailbox.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
+index 87ef465c6947..c1c43800c4aa 100644
+--- a/drivers/mailbox/mailbox.c
++++ b/drivers/mailbox/mailbox.c
+@@ -389,11 +389,13 @@ struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,
+
+ of_property_for_each_string(np, "mbox-names", prop, mbox_name) {
+ if (!strncmp(name, mbox_name, strlen(name)))
+- break;
++ return mbox_request_channel(cl, index);
+ index++;
+ }
+
+- return mbox_request_channel(cl, index);
++ dev_err(cl->dev, "%s() could not locate channel named \"%s\"\n",
++ __func__, name);
++ return ERR_PTR(-EINVAL);
+ }
+ EXPORT_SYMBOL_GPL(mbox_request_channel_byname);
+
+--
+2.20.1
+
--- /dev/null
+From d637a71b98f87393261ead38421adc911c096745 Mon Sep 17 00:00:00 2001
+From: Wang Hai <wanghai26@huawei.com>
+Date: Wed, 15 May 2019 22:37:25 +0800
+Subject: memstick: Fix error cleanup path of memstick_init
+
+[ Upstream commit 65f1a0d39c289bb6fc85635528cd36c4b07f560e ]
+
+If bus_register fails. On its error handling path, it has cleaned up
+what it has done. There is no need to call bus_unregister again.
+Otherwise, if bus_unregister is called, issues such as null-ptr-deref
+will arise.
+
+Syzkaller report this:
+
+kobject_add_internal failed for memstick (error: -12 parent: bus)
+BUG: KASAN: null-ptr-deref in sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467
+Read of size 8 at addr 0000000000000078 by task syz-executor.0/4460
+
+Call Trace:
+ __dump_stack lib/dump_stack.c:77 [inline]
+ dump_stack+0xa9/0x10e lib/dump_stack.c:113
+ __kasan_report+0x171/0x18d mm/kasan/report.c:321
+ kasan_report+0xe/0x20 mm/kasan/common.c:614
+ sysfs_remove_file_ns+0x1b/0x40 fs/sysfs/file.c:467
+ sysfs_remove_file include/linux/sysfs.h:519 [inline]
+ bus_remove_file+0x6c/0x90 drivers/base/bus.c:145
+ remove_probe_files drivers/base/bus.c:599 [inline]
+ bus_unregister+0x6e/0x100 drivers/base/bus.c:916 ? 0xffffffffc1590000
+ memstick_init+0x7a/0x1000 [memstick]
+ do_one_initcall+0xb9/0x3b5 init/main.c:914
+ do_init_module+0xe0/0x330 kernel/module.c:3468
+ load_module+0x38eb/0x4270 kernel/module.c:3819
+ __do_sys_finit_module+0x162/0x190 kernel/module.c:3909
+ do_syscall_64+0x72/0x2a0 arch/x86/entry/common.c:298
+ entry_SYSCALL_64_after_hwframe+0x49/0xbe
+
+Fixes: baf8532a147d ("memstick: initial commit for Sony MemoryStick support")
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Wang Hai <wanghai26@huawei.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/memstick/core/memstick.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/memstick/core/memstick.c b/drivers/memstick/core/memstick.c
+index 4d673a626db4..1041eb7a6167 100644
+--- a/drivers/memstick/core/memstick.c
++++ b/drivers/memstick/core/memstick.c
+@@ -629,13 +629,18 @@ static int __init memstick_init(void)
+ return -ENOMEM;
+
+ rc = bus_register(&memstick_bus_type);
+- if (!rc)
+- rc = class_register(&memstick_host_class);
++ if (rc)
++ goto error_destroy_workqueue;
+
+- if (!rc)
+- return 0;
++ rc = class_register(&memstick_host_class);
++ if (rc)
++ goto error_bus_unregister;
++
++ return 0;
+
++error_bus_unregister:
+ bus_unregister(&memstick_bus_type);
++error_destroy_workqueue:
+ destroy_workqueue(workqueue);
+
+ return rc;
+--
+2.20.1
+
--- /dev/null
+From 1fd8891e90538a5691a7cb26450af84e029c795e Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Mon, 20 May 2019 10:06:25 +0100
+Subject: mfd: arizona: Fix undefined behavior
+
+[ Upstream commit 5da6cbcd2f395981aa9bfc571ace99f1c786c985 ]
+
+When the driver is used with a subdevice that is disabled in the
+kernel configuration, clang gets a little confused about the
+control flow and fails to notice that n_subdevs is only
+uninitialized when subdevs is NULL, and we check for that,
+leading to a false-positive warning:
+
+drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is uninitialized when used here
+ [-Werror,-Wuninitialized]
+ subdevs, n_subdevs, NULL, 0, NULL);
+ ^~~~~~~~~
+drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' to silence this warning
+ int n_subdevs, ret, i;
+ ^
+ = 0
+
+Ideally, we would rearrange the code to avoid all those early
+initializations and have an explicit exit in each disabled case,
+but it's much easier to chicken out and add one more initialization
+here to shut up the warning.
+
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
+Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/arizona-core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
+index 41767f7239bb..0556a9749dbe 100644
+--- a/drivers/mfd/arizona-core.c
++++ b/drivers/mfd/arizona-core.c
+@@ -1038,7 +1038,7 @@ int arizona_dev_init(struct arizona *arizona)
+ unsigned int reg, val, mask;
+ int (*apply_patch)(struct arizona *) = NULL;
+ const struct mfd_cell *subdevs = NULL;
+- int n_subdevs, ret, i;
++ int n_subdevs = 0, ret, i;
+
+ dev_set_drvdata(arizona->dev, arizona);
+ mutex_init(&arizona->clk_lock);
+--
+2.20.1
+
--- /dev/null
+From c2bf923300a459fddde60c7a0053f9e41a3b6998 Mon Sep 17 00:00:00 2001
+From: Robert Hancock <hancock@sedsystems.ca>
+Date: Tue, 4 Jun 2019 16:35:43 -0600
+Subject: mfd: core: Set fwnode for created devices
+
+[ Upstream commit c176c6d7e932662668bcaec2d763657096589d85 ]
+
+The logic for setting the of_node on devices created by mfd did not set
+the fwnode pointer to match, which caused fwnode-based APIs to
+malfunction on these devices since the fwnode pointer was null. Fix
+this.
+
+Signed-off-by: Robert Hancock <hancock@sedsystems.ca>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/mfd-core.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
+index c57e407020f1..5c8ed2150c8b 100644
+--- a/drivers/mfd/mfd-core.c
++++ b/drivers/mfd/mfd-core.c
+@@ -179,6 +179,7 @@ static int mfd_add_device(struct device *parent, int id,
+ for_each_child_of_node(parent->of_node, np) {
+ if (of_device_is_compatible(np, cell->of_compatible)) {
+ pdev->dev.of_node = np;
++ pdev->dev.fwnode = &np->fwnode;
+ break;
+ }
+ }
+--
+2.20.1
+
--- /dev/null
+From 0890a61b509d2136e6686ef4dfd27229a26b808f Mon Sep 17 00:00:00 2001
+From: Axel Lin <axel.lin@ingics.com>
+Date: Wed, 26 Jun 2019 21:30:07 +0800
+Subject: mfd: hi655x-pmic: Fix missing return value check for
+ devm_regmap_init_mmio_clk
+
+[ Upstream commit 7efd105c27fd2323789b41b64763a0e33ed79c08 ]
+
+Since devm_regmap_init_mmio_clk can fail, add return value checking.
+
+Signed-off-by: Axel Lin <axel.lin@ingics.com>
+Acked-by: Chen Feng <puck.chen@hisilicon.com>
+Signed-off-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/mfd/hi655x-pmic.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
+index 11347a3e6d40..c311b869be38 100644
+--- a/drivers/mfd/hi655x-pmic.c
++++ b/drivers/mfd/hi655x-pmic.c
+@@ -111,6 +111,8 @@ static int hi655x_pmic_probe(struct platform_device *pdev)
+
+ pmic->regmap = devm_regmap_init_mmio_clk(dev, NULL, base,
+ &hi655x_regmap_config);
++ if (IS_ERR(pmic->regmap))
++ return PTR_ERR(pmic->regmap);
+
+ regmap_read(pmic->regmap, HI655X_BUS_ADDR(HI655X_VER_REG), &pmic->ver);
+ if ((pmic->ver < PMU_VER_START) || (pmic->ver > PMU_VER_END)) {
+--
+2.20.1
+
--- /dev/null
+From df9c9e15a6d20edaaaab369f562c920e9e627b38 Mon Sep 17 00:00:00 2001
+From: Dmitry Vyukov <dvyukov@google.com>
+Date: Thu, 11 Jul 2019 20:53:39 -0700
+Subject: mm/kmemleak.c: fix check for softirq context
+
+[ Upstream commit 6ef9056952532c3b746de46aa10d45b4d7797bd8 ]
+
+in_softirq() is a wrong predicate to check if we are in a softirq
+context. It also returns true if we have BH disabled, so objects are
+falsely stamped with "softirq" comm. The correct predicate is
+in_serving_softirq().
+
+If user does cat from /sys/kernel/debug/kmemleak previously they would
+see this, which is clearly wrong, this is system call context (see the
+comm):
+
+unreferenced object 0xffff88805bd661c0 (size 64):
+ comm "softirq", pid 0, jiffies 4294942959 (age 12.400s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 ff ff ff ff 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<0000000007dcb30c>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
+ [<0000000007dcb30c>] slab_post_alloc_hook mm/slab.h:439 [inline]
+ [<0000000007dcb30c>] slab_alloc mm/slab.c:3326 [inline]
+ [<0000000007dcb30c>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
+ [<00000000969722b7>] kmalloc include/linux/slab.h:547 [inline]
+ [<00000000969722b7>] kzalloc include/linux/slab.h:742 [inline]
+ [<00000000969722b7>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
+ [<00000000969722b7>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
+ [<00000000a4134b5f>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
+ [<00000000d20248ad>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957
+ [<000000003d367be7>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
+ [<000000003c7c76af>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
+ [<000000000c1aeb23>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130
+ [<000000000157b92b>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078
+ [<00000000a9f3d058>] __do_sys_setsockopt net/socket.c:2089 [inline]
+ [<00000000a9f3d058>] __se_sys_setsockopt net/socket.c:2086 [inline]
+ [<00000000a9f3d058>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
+ [<000000001b8da885>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301
+ [<00000000ba770c62>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+now they will see this:
+
+unreferenced object 0xffff88805413c800 (size 64):
+ comm "syz-executor.4", pid 8960, jiffies 4294994003 (age 14.350s)
+ hex dump (first 32 bytes):
+ 00 7a 8a 57 80 88 ff ff e0 00 00 01 00 00 00 00 .z.W............
+ 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<00000000c5d3be64>] kmemleak_alloc_recursive include/linux/kmemleak.h:55 [inline]
+ [<00000000c5d3be64>] slab_post_alloc_hook mm/slab.h:439 [inline]
+ [<00000000c5d3be64>] slab_alloc mm/slab.c:3326 [inline]
+ [<00000000c5d3be64>] kmem_cache_alloc_trace+0x13d/0x280 mm/slab.c:3553
+ [<0000000023865be2>] kmalloc include/linux/slab.h:547 [inline]
+ [<0000000023865be2>] kzalloc include/linux/slab.h:742 [inline]
+ [<0000000023865be2>] ip_mc_add1_src net/ipv4/igmp.c:1961 [inline]
+ [<0000000023865be2>] ip_mc_add_src+0x36b/0x400 net/ipv4/igmp.c:2085
+ [<000000003029a9d4>] ip_mc_msfilter+0x22d/0x310 net/ipv4/igmp.c:2475
+ [<00000000ccd0a87c>] do_ip_setsockopt.isra.0+0x19fe/0x1c00 net/ipv4/ip_sockglue.c:957
+ [<00000000a85a3785>] ip_setsockopt+0x3b/0xb0 net/ipv4/ip_sockglue.c:1246
+ [<00000000ec13c18d>] udp_setsockopt+0x4e/0x90 net/ipv4/udp.c:2616
+ [<0000000052d748e3>] sock_common_setsockopt+0x3e/0x50 net/core/sock.c:3130
+ [<00000000512f1014>] __sys_setsockopt+0x9e/0x120 net/socket.c:2078
+ [<00000000181758bc>] __do_sys_setsockopt net/socket.c:2089 [inline]
+ [<00000000181758bc>] __se_sys_setsockopt net/socket.c:2086 [inline]
+ [<00000000181758bc>] __x64_sys_setsockopt+0x26/0x30 net/socket.c:2086
+ [<00000000d4b73623>] do_syscall_64+0x7c/0x1a0 arch/x86/entry/common.c:301
+ [<00000000c1098bec>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
+
+Link: http://lkml.kernel.org/r/20190517171507.96046-1-dvyukov@gmail.com
+Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
+Acked-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/kmemleak.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/kmemleak.c b/mm/kmemleak.c
+index 9e66449ed91f..d05133b37b17 100644
+--- a/mm/kmemleak.c
++++ b/mm/kmemleak.c
+@@ -569,7 +569,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
+ if (in_irq()) {
+ object->pid = 0;
+ strncpy(object->comm, "hardirq", sizeof(object->comm));
+- } else if (in_softirq()) {
++ } else if (in_serving_softirq()) {
+ object->pid = 0;
+ strncpy(object->comm, "softirq", sizeof(object->comm));
+ } else {
+--
+2.20.1
+
--- /dev/null
+From 342cc6ff9c5262c2c124162b7027cb1fe3d4902b Mon Sep 17 00:00:00 2001
+From: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
+Date: Thu, 11 Jul 2019 20:58:50 -0700
+Subject: mm/mmu_notifier: use hlist_add_head_rcu()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 543bdb2d825fe2400d6e951f1786d92139a16931 ]
+
+Make mmu_notifier_register() safer by issuing a memory barrier before
+registering a new notifier. This fixes a theoretical bug on weakly
+ordered CPUs. For example, take this simplified use of notifiers by a
+driver:
+
+ my_struct->mn.ops = &my_ops; /* (1) */
+ mmu_notifier_register(&my_struct->mn, mm)
+ ...
+ hlist_add_head(&mn->hlist, &mm->mmu_notifiers); /* (2) */
+ ...
+
+Once mmu_notifier_register() releases the mm locks, another thread can
+invalidate a range:
+
+ mmu_notifier_invalidate_range()
+ ...
+ hlist_for_each_entry_rcu(mn, &mm->mmu_notifiers, hlist) {
+ if (mn->ops->invalidate_range)
+
+The read side relies on the data dependency between mn and ops to ensure
+that the pointer is properly initialized. But the write side doesn't have
+any dependency between (1) and (2), so they could be reordered and the
+readers could dereference an invalid mn->ops. mmu_notifier_register()
+does take all the mm locks before adding to the hlist, but those have
+acquire semantics which isn't sufficient.
+
+By calling hlist_add_head_rcu() instead of hlist_add_head() we update the
+hlist using a store-release, ensuring that readers see prior
+initialization of my_struct. This situation is better illustated by
+litmus test MP+onceassign+derefonce.
+
+Link: http://lkml.kernel.org/r/20190502133532.24981-1-jean-philippe.brucker@arm.com
+Fixes: cddb8a5c14aa ("mmu-notifiers: core")
+Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
+Cc: Jérôme Glisse <jglisse@redhat.com>
+Cc: Michal Hocko <mhocko@suse.com>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ mm/mmu_notifier.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
+index f4259e496f83..7a66e37efb4d 100644
+--- a/mm/mmu_notifier.c
++++ b/mm/mmu_notifier.c
+@@ -286,7 +286,7 @@ static int do_mmu_notifier_register(struct mmu_notifier *mn,
+ * thanks to mm_take_all_locks().
+ */
+ spin_lock(&mm->mmu_notifier_mm->lock);
+- hlist_add_head(&mn->hlist, &mm->mmu_notifier_mm->list);
++ hlist_add_head_rcu(&mn->hlist, &mm->mmu_notifier_mm->list);
+ spin_unlock(&mm->mmu_notifier_mm->lock);
+
+ mm_drop_all_locks(mm);
+--
+2.20.1
+
--- /dev/null
+From 129c52608e9a1d9bd720bc799e4bb7dc705995a2 Mon Sep 17 00:00:00 2001
+From: Paul Menzel <pmenzel@molgen.mpg.de>
+Date: Wed, 3 Jul 2019 13:28:15 +0200
+Subject: nfsd: Fix overflow causing non-working mounts on 1 TB machines
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+[ Upstream commit 3b2d4dcf71c4a91b420f835e52ddea8192300a3b ]
+
+Since commit 10a68cdf10 (nfsd: fix performance-limiting session
+calculation) (Linux 5.1-rc1 and 4.19.31), shares from NFS servers with
+1 TB of memory cannot be mounted anymore. The mount just hangs on the
+client.
+
+The gist of commit 10a68cdf10 is the change below.
+
+ -avail = clamp_t(int, avail, slotsize, avail/3);
+ +avail = clamp_t(int, avail, slotsize, total_avail/3);
+
+Here are the macros.
+
+ #define min_t(type, x, y) __careful_cmp((type)(x), (type)(y), <)
+ #define clamp_t(type, val, lo, hi) min_t(type, max_t(type, val, lo), hi)
+
+`total_avail` is 8,434,659,328 on the 1 TB machine. `clamp_t()` casts
+the values to `int`, which for 32-bit integers can only hold values
+−2,147,483,648 (−2^31) through 2,147,483,647 (2^31 − 1).
+
+`avail` (in the function signature) is just 65536, so that no overflow
+was happening. Before the commit the assignment would result in 21845,
+and `num = 4`.
+
+When using `total_avail`, it is causing the assignment to be
+18446744072226137429 (printed as %lu), and `num` is then 4164608182.
+
+My next guess is, that `nfsd_drc_mem_used` is then exceeded, and the
+server thinks there is no memory available any more for this client.
+
+Updating the arguments of `clamp_t()` and `min_t()` to `unsigned long`
+fixes the issue.
+
+Now, `avail = 65536` (before commit 10a68cdf10 `avail = 21845`), but
+`num = 4` remains the same.
+
+Fixes: c54f24e338ed (nfsd: fix performance-limiting session calculation)
+Cc: stable@vger.kernel.org
+Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/nfs4state.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
+index c4762d8aa9f8..032fcae3a94f 100644
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -1511,7 +1511,7 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca)
+ * Never use more than a third of the remaining memory,
+ * unless it's the only way to give this client a slot:
+ */
+- avail = clamp_t(int, avail, slotsize, total_avail/3);
++ avail = clamp_t(unsigned long, avail, slotsize, total_avail/3);
+ num = min_t(int, num, avail / slotsize);
+ nfsd_drc_mem_used += num * slotsize;
+ spin_unlock(&nfsd_drc_lock);
+--
+2.20.1
+
--- /dev/null
+From 804ef8c6b886a2e837c7fdb03817ee1d0e90d2e3 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Thu, 21 Feb 2019 10:47:00 -0500
+Subject: nfsd: fix performance-limiting session calculation
+
+[ Upstream commit c54f24e338ed2a35218f117a4a1afb5f9e2b4e64 ]
+
+We're unintentionally limiting the number of slots per nfsv4.1 session
+to 10. Often more than 10 simultaneous RPCs are needed for the best
+performance.
+
+This calculation was meant to prevent any one client from using up more
+than a third of the limit we set for total memory use across all clients
+and sessions. Instead, it's limiting the client to a third of the
+maximum for a single session.
+
+Fix this.
+
+Reported-by: Chris Tracy <ctracy@engr.scu.edu>
+Cc: stable@vger.kernel.org
+Fixes: de766e570413 "nfsd: give out fewer session slots as limit approaches"
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/nfs4state.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
+index 0aacd1c850c3..c4762d8aa9f8 100644
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -1502,16 +1502,16 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca)
+ {
+ u32 slotsize = slot_bytes(ca);
+ u32 num = ca->maxreqs;
+- int avail;
++ unsigned long avail, total_avail;
+
+ spin_lock(&nfsd_drc_lock);
+- avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION,
+- nfsd_drc_max_mem - nfsd_drc_mem_used);
++ total_avail = nfsd_drc_max_mem - nfsd_drc_mem_used;
++ avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION, total_avail);
+ /*
+ * Never use more than a third of the remaining memory,
+ * unless it's the only way to give this client a slot:
+ */
+- avail = clamp_t(int, avail, slotsize, avail/3);
++ avail = clamp_t(int, avail, slotsize, total_avail/3);
+ num = min_t(int, num, avail / slotsize);
+ nfsd_drc_mem_used += num * slotsize;
+ spin_unlock(&nfsd_drc_lock);
+--
+2.20.1
+
--- /dev/null
+From 4e4b95833cf41c547f0f0428f06492096456a2f4 Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Tue, 19 Sep 2017 19:25:41 -0400
+Subject: nfsd: give out fewer session slots as limit approaches
+
+[ Upstream commit de766e570413bd0484af0b580299b495ada625c3 ]
+
+Instead of granting client's full requests until we hit our DRC size
+limit and then failing CREATE_SESSIONs (and hence mounts) completely,
+start granting clients smaller slot tables as we approach the limit.
+
+The factor chosen here is pretty much arbitrary.
+
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/nfs4state.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
+index 3656f87d11e3..0aacd1c850c3 100644
+--- a/fs/nfsd/nfs4state.c
++++ b/fs/nfsd/nfs4state.c
+@@ -1507,6 +1507,11 @@ static u32 nfsd4_get_drc_mem(struct nfsd4_channel_attrs *ca)
+ spin_lock(&nfsd_drc_lock);
+ avail = min((unsigned long)NFSD_MAX_MEM_PER_SESSION,
+ nfsd_drc_max_mem - nfsd_drc_mem_used);
++ /*
++ * Never use more than a third of the remaining memory,
++ * unless it's the only way to give this client a slot:
++ */
++ avail = clamp_t(int, avail, slotsize, avail/3);
+ num = min_t(int, num, avail / slotsize);
+ nfsd_drc_mem_used += num * slotsize;
+ spin_unlock(&nfsd_drc_lock);
+--
+2.20.1
+
--- /dev/null
+From 1b9e93afcd2f0e0679b128e5a2a4b732e34a1c8c Mon Sep 17 00:00:00 2001
+From: "J. Bruce Fields" <bfields@redhat.com>
+Date: Tue, 19 Sep 2017 20:51:31 -0400
+Subject: nfsd: increase DRC cache limit
+
+[ Upstream commit 44d8660d3bb0a1c8363ebcb906af2343ea8e15f6 ]
+
+An NFSv4.1+ client negotiates the size of its duplicate reply cache size
+in the initial CREATE_SESSION request. The server preallocates the
+memory for the duplicate reply cache to ensure that we'll never fail to
+record the response to a nonidempotent operation.
+
+To prevent a few CREATE_SESSIONs from consuming all of memory we set an
+upper limit based on nr_free_buffer_pages(). 1/2^10 has been too
+limiting in practice; 1/2^7 is still less than one percent.
+
+Signed-off-by: J. Bruce Fields <bfields@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfsd/nfssvc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/fs/nfsd/nfssvc.c b/fs/nfsd/nfssvc.c
+index 5c4800626f13..60291d10f8e4 100644
+--- a/fs/nfsd/nfssvc.c
++++ b/fs/nfsd/nfssvc.c
+@@ -430,7 +430,7 @@ void nfsd_reset_versions(void)
+ */
+ static void set_max_drc(void)
+ {
+- #define NFSD_DRC_SIZE_SHIFT 10
++ #define NFSD_DRC_SIZE_SHIFT 7
+ nfsd_drc_max_mem = (nr_free_buffer_pages()
+ >> NFSD_DRC_SIZE_SHIFT) * PAGE_SIZE;
+ nfsd_drc_mem_used = 0;
+--
+2.20.1
+
--- /dev/null
+From 447856868cc93f270aab3bf3ab668e766a835280 Mon Sep 17 00:00:00 2001
+From: Trond Myklebust <trond.myklebust@primarydata.com>
+Date: Mon, 6 Nov 2017 15:28:03 -0500
+Subject: NFSv4: Fix open create exclusive when the server reboots
+
+[ Upstream commit 8fd1ab747d2b1ec7ec663ad0b41a32eaa35117a8 ]
+
+If the server that does not implement NFSv4.1 persistent session
+semantics reboots while we are performing an exclusive create,
+then the return value of NFS4ERR_DELAY when we replay the open
+during the grace period causes us to lose the verifier.
+When the grace period expires, and we present a new verifier,
+the server will then correctly reply NFS4ERR_EXIST.
+
+This commit ensures that we always present the same verifier when
+replaying the OPEN.
+
+Reported-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
+Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
+Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ fs/nfs/nfs4proc.c | 41 ++++++++++++++++++++++++++---------------
+ 1 file changed, 26 insertions(+), 15 deletions(-)
+
+diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
+index 6d0d94fc243d..ea29c608be89 100644
+--- a/fs/nfs/nfs4proc.c
++++ b/fs/nfs/nfs4proc.c
+@@ -1121,6 +1121,12 @@ struct nfs4_opendata {
+ int cancelled;
+ };
+
++struct nfs4_open_createattrs {
++ struct nfs4_label *label;
++ struct iattr *sattr;
++ const __u32 verf[2];
++};
++
+ static bool nfs4_clear_cap_atomic_open_v1(struct nfs_server *server,
+ int err, struct nfs4_exception *exception)
+ {
+@@ -1190,8 +1196,7 @@ static void nfs4_init_opendata_res(struct nfs4_opendata *p)
+
+ static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry,
+ struct nfs4_state_owner *sp, fmode_t fmode, int flags,
+- const struct iattr *attrs,
+- struct nfs4_label *label,
++ const struct nfs4_open_createattrs *c,
+ enum open_claim_type4 claim,
+ gfp_t gfp_mask)
+ {
+@@ -1199,6 +1204,7 @@ static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry,
+ struct inode *dir = d_inode(parent);
+ struct nfs_server *server = NFS_SERVER(dir);
+ struct nfs_seqid *(*alloc_seqid)(struct nfs_seqid_counter *, gfp_t);
++ struct nfs4_label *label = (c != NULL) ? c->label : NULL;
+ struct nfs4_opendata *p;
+
+ p = kzalloc(sizeof(*p), gfp_mask);
+@@ -1255,15 +1261,11 @@ static struct nfs4_opendata *nfs4_opendata_alloc(struct dentry *dentry,
+ case NFS4_OPEN_CLAIM_DELEG_PREV_FH:
+ p->o_arg.fh = NFS_FH(d_inode(dentry));
+ }
+- if (attrs != NULL && attrs->ia_valid != 0) {
+- __u32 verf[2];
+-
++ if (c != NULL && c->sattr != NULL && c->sattr->ia_valid != 0) {
+ p->o_arg.u.attrs = &p->attrs;
+- memcpy(&p->attrs, attrs, sizeof(p->attrs));
++ memcpy(&p->attrs, c->sattr, sizeof(p->attrs));
+
+- verf[0] = jiffies;
+- verf[1] = current->pid;
+- memcpy(p->o_arg.u.verifier.data, verf,
++ memcpy(p->o_arg.u.verifier.data, c->verf,
+ sizeof(p->o_arg.u.verifier.data));
+ }
+ p->c_arg.fh = &p->o_res.fh;
+@@ -1814,7 +1816,7 @@ static struct nfs4_opendata *nfs4_open_recoverdata_alloc(struct nfs_open_context
+ struct nfs4_opendata *opendata;
+
+ opendata = nfs4_opendata_alloc(ctx->dentry, state->owner, 0, 0,
+- NULL, NULL, claim, GFP_NOFS);
++ NULL, claim, GFP_NOFS);
+ if (opendata == NULL)
+ return ERR_PTR(-ENOMEM);
+ opendata->state = state;
+@@ -2759,8 +2761,7 @@ static int _nfs4_open_and_get_state(struct nfs4_opendata *opendata,
+ static int _nfs4_do_open(struct inode *dir,
+ struct nfs_open_context *ctx,
+ int flags,
+- struct iattr *sattr,
+- struct nfs4_label *label,
++ const struct nfs4_open_createattrs *c,
+ int *opened)
+ {
+ struct nfs4_state_owner *sp;
+@@ -2772,6 +2773,8 @@ static int _nfs4_do_open(struct inode *dir,
+ struct nfs4_threshold **ctx_th = &ctx->mdsthreshold;
+ fmode_t fmode = ctx->mode & (FMODE_READ|FMODE_WRITE|FMODE_EXEC);
+ enum open_claim_type4 claim = NFS4_OPEN_CLAIM_NULL;
++ struct iattr *sattr = c->sattr;
++ struct nfs4_label *label = c->label;
+ struct nfs4_label *olabel = NULL;
+ int status;
+
+@@ -2790,8 +2793,8 @@ static int _nfs4_do_open(struct inode *dir,
+ status = -ENOMEM;
+ if (d_really_is_positive(dentry))
+ claim = NFS4_OPEN_CLAIM_FH;
+- opendata = nfs4_opendata_alloc(dentry, sp, fmode, flags, sattr,
+- label, claim, GFP_KERNEL);
++ opendata = nfs4_opendata_alloc(dentry, sp, fmode, flags,
++ c, claim, GFP_KERNEL);
+ if (opendata == NULL)
+ goto err_put_state_owner;
+
+@@ -2872,10 +2875,18 @@ static struct nfs4_state *nfs4_do_open(struct inode *dir,
+ struct nfs_server *server = NFS_SERVER(dir);
+ struct nfs4_exception exception = { };
+ struct nfs4_state *res;
++ struct nfs4_open_createattrs c = {
++ .label = label,
++ .sattr = sattr,
++ .verf = {
++ [0] = (__u32)jiffies,
++ [1] = (__u32)current->pid,
++ },
++ };
+ int status;
+
+ do {
+- status = _nfs4_do_open(dir, ctx, flags, sattr, label, opened);
++ status = _nfs4_do_open(dir, ctx, flags, &c, opened);
+ res = ctx->state;
+ trace_nfs4_open_file(ctx, flags, status);
+ if (status == 0)
+--
+2.20.1
+
--- /dev/null
+From 2b780c4644fa33bb25dd4a2483d11c7d2aa9ae40 Mon Sep 17 00:00:00 2001
+From: Marek Vasut <marek.vasut+renesas@gmail.com>
+Date: Mon, 27 May 2019 00:51:51 +0200
+Subject: PCI: sysfs: Ignore lockdep for remove attribute
+
+[ Upstream commit dc6b698a86fe40a50525433eb8e92a267847f6f9 ]
+
+With CONFIG_PROVE_LOCKING=y, using sysfs to remove a bridge with a device
+below it causes a lockdep warning, e.g.,
+
+ # echo 1 > /sys/class/pci_bus/0000:00/device/0000:00:00.0/remove
+ ============================================
+ WARNING: possible recursive locking detected
+ ...
+ pci_bus 0000:01: busn_res: [bus 01] is released
+
+The remove recursively removes the subtree below the bridge. Each call
+uses a different lock so there's no deadlock, but the locks were all
+created with the same lockdep key so the lockdep checker can't tell them
+apart.
+
+Mark the "remove" sysfs attribute with __ATTR_IGNORE_LOCKDEP() as it is
+safe to ignore the lockdep check between different "remove" kernfs
+instances.
+
+There's discussion about a similar issue in USB at [1], which resulted in
+356c05d58af0 ("sysfs: get rid of some lockdep false positives") and
+e9b526fe7048 ("i2c: suppress lockdep warning on delete_device"), which do
+basically the same thing for USB "remove" and i2c "delete_device" files.
+
+[1] https://lore.kernel.org/r/Pine.LNX.4.44L0.1204251436140.1206-100000@iolanthe.rowland.org
+Link: https://lore.kernel.org/r/20190526225151.3865-1-marek.vasut@gmail.com
+Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
+[bhelgaas: trim commit log, details at above links]
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Cc: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: Phil Edworthy <phil.edworthy@renesas.com>
+Cc: Simon Horman <horms+renesas@verge.net.au>
+Cc: Tejun Heo <tj@kernel.org>
+Cc: Wolfram Sang <wsa@the-dreams.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/pci-sysfs.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
+index e5d8e2e2bd30..717540161223 100644
+--- a/drivers/pci/pci-sysfs.c
++++ b/drivers/pci/pci-sysfs.c
+@@ -371,7 +371,7 @@ static ssize_t remove_store(struct device *dev, struct device_attribute *attr,
+ pci_stop_and_remove_bus_device_locked(to_pci_dev(dev));
+ return count;
+ }
+-static struct device_attribute dev_remove_attr = __ATTR(remove,
++static struct device_attribute dev_remove_attr = __ATTR_IGNORE_LOCKDEP(remove,
+ (S_IWUSR|S_IWGRP),
+ NULL, remove_store);
+
+--
+2.20.1
+
--- /dev/null
+From 8cb9d1bce269ad7dcfed3435f20a842e16a115af Mon Sep 17 00:00:00 2001
+From: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
+Date: Wed, 12 Jun 2019 15:47:59 +0530
+Subject: PCI: xilinx-nwl: Fix Multi MSI data programming
+
+[ Upstream commit 181fa434d0514e40ebf6e9721f2b72700287b6e2 ]
+
+According to the PCI Local Bus specification Revision 3.0,
+section 6.8.1.3 (Message Control for MSI), endpoints that
+are Multiple Message Capable as defined by bits [3:1] in
+the Message Control for MSI can request a number of vectors
+that is power of two aligned.
+
+As specified in section 6.8.1.6 "Message data for MSI", the Multiple
+Message Enable field (bits [6:4] of the Message Control register)
+defines the number of low order message data bits the function is
+permitted to modify to generate its system software allocated
+vectors.
+
+The MSI controller in the Xilinx NWL PCIe controller supports a number
+of MSI vectors specified through a bitmap and the hwirq number for an
+MSI, that is the value written in the MSI data TLP is determined by
+the bitmap allocation.
+
+For instance, in a situation where two endpoints sitting on
+the PCI bus request the following MSI configuration, with
+the current PCI Xilinx bitmap allocation code (that does not
+align MSI vector allocation on a power of two boundary):
+
+Endpoint #1: Requesting 1 MSI vector - allocated bitmap bits 0
+Endpoint #2: Requesting 2 MSI vectors - allocated bitmap bits [1,2]
+
+The bitmap value(s) corresponds to the hwirq number that is programmed
+into the Message Data for MSI field in the endpoint MSI capability
+and is detected by the root complex to fire the corresponding
+MSI irqs. The value written in Message Data for MSI field corresponds
+to the first bit allocated in the bitmap for Multi MSI vectors.
+
+The current Xilinx NWL MSI allocation code allows a bitmap allocation
+that is not a power of two boundaries, so endpoint #2, is allowed to
+toggle Message Data bit[0] to differentiate between its two vectors
+(meaning that the MSI data will be respectively 0x0 and 0x1 for the two
+vectors allocated to endpoint #2).
+
+This clearly aliases with the Endpoint #1 vector allocation, resulting
+in a broken Multi MSI implementation.
+
+Update the code to allocate MSI bitmap ranges with a power of two
+alignment, fixing the bug.
+
+Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller")
+Suggested-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com>
+[lorenzo.pieralisi@arm.com: updated commit log]
+Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
+Acked-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pci/host/pcie-xilinx-nwl.c | 11 +++++------
+ 1 file changed, 5 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/pci/host/pcie-xilinx-nwl.c b/drivers/pci/host/pcie-xilinx-nwl.c
+index 94fdd295aae2..3bba87af0b6b 100644
+--- a/drivers/pci/host/pcie-xilinx-nwl.c
++++ b/drivers/pci/host/pcie-xilinx-nwl.c
+@@ -456,15 +456,13 @@ static int nwl_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ int i;
+
+ mutex_lock(&msi->lock);
+- bit = bitmap_find_next_zero_area(msi->bitmap, INT_PCI_MSI_NR, 0,
+- nr_irqs, 0);
+- if (bit >= INT_PCI_MSI_NR) {
++ bit = bitmap_find_free_region(msi->bitmap, INT_PCI_MSI_NR,
++ get_count_order(nr_irqs));
++ if (bit < 0) {
+ mutex_unlock(&msi->lock);
+ return -ENOSPC;
+ }
+
+- bitmap_set(msi->bitmap, bit, nr_irqs);
+-
+ for (i = 0; i < nr_irqs; i++) {
+ irq_domain_set_info(domain, virq + i, bit + i, &nwl_irq_chip,
+ domain->host_data, handle_simple_irq,
+@@ -482,7 +480,8 @@ static void nwl_irq_domain_free(struct irq_domain *domain, unsigned int virq,
+ struct nwl_msi *msi = &pcie->msi;
+
+ mutex_lock(&msi->lock);
+- bitmap_clear(msi->bitmap, data->hwirq, nr_irqs);
++ bitmap_release_region(msi->bitmap, data->hwirq,
++ get_count_order(nr_irqs));
+ mutex_unlock(&msi->lock);
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 54eb13f80f081114cde6cb9f07a276fcfc8fc31b Mon Sep 17 00:00:00 2001
+From: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Date: Fri, 27 Apr 2018 16:34:35 -0500
+Subject: perf/events/amd/uncore: Fix amd_uncore_llc ID to use pre-defined
+ cpu_llc_id
+
+Current logic iterates over CPUID Fn8000001d leafs (Cache Properties)
+to detect the last level cache, and derive the last-level cache ID.
+However, this information is already available in the cpu_llc_id.
+Therefore, make use of it instead.
+
+Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
+Cc: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Link: http://lkml.kernel.org/r/1524864877-111962-3-git-send-email-suravee.suthikulpanit@amd.com
+---
+ arch/x86/events/amd/uncore.c | 21 ++-------------------
+ 1 file changed, 2 insertions(+), 19 deletions(-)
+
+diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
+index 10f023799f11..c16c99bc2a10 100644
+--- a/arch/x86/events/amd/uncore.c
++++ b/arch/x86/events/amd/uncore.c
+@@ -19,6 +19,7 @@
+ #include <asm/cpufeature.h>
+ #include <asm/perf_event.h>
+ #include <asm/msr.h>
++#include <asm/smp.h>
+
+ #define NUM_COUNTERS_NB 4
+ #define NUM_COUNTERS_L2 4
+@@ -377,26 +378,8 @@ static int amd_uncore_cpu_starting(unsigned int cpu)
+ }
+
+ if (amd_uncore_llc) {
+- unsigned int apicid = cpu_data(cpu).apicid;
+- unsigned int nshared, subleaf, prev_eax = 0;
+-
+ uncore = *per_cpu_ptr(amd_uncore_llc, cpu);
+- /*
+- * Iterate over Cache Topology Definition leaves until no
+- * more cache descriptions are available.
+- */
+- for (subleaf = 0; subleaf < 5; subleaf++) {
+- cpuid_count(0x8000001d, subleaf, &eax, &ebx, &ecx, &edx);
+-
+- /* EAX[0:4] gives type of cache */
+- if (!(eax & 0x1f))
+- break;
+-
+- prev_eax = eax;
+- }
+- nshared = ((prev_eax >> 14) & 0xfff) + 1;
+-
+- uncore->id = apicid - (apicid % nshared);
++ uncore->id = per_cpu(cpu_llc_id, cpu);
+
+ uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_llc);
+ *per_cpu_ptr(amd_uncore_llc, cpu) = uncore;
+--
+2.20.1
+
--- /dev/null
+From 238373b6c2393288186999ae7664e173cbb90cbe Mon Sep 17 00:00:00 2001
+From: Numfor Mbiziwo-Tiapo <nums@google.com>
+Date: Tue, 2 Jul 2019 10:37:15 -0700
+Subject: perf test mmap-thread-lookup: Initialize variable to suppress memory
+ sanitizer warning
+
+[ Upstream commit 4e4cf62b37da5ff45c904a3acf242ab29ed5881d ]
+
+Running the 'perf test' command after building perf with a memory
+sanitizer causes a warning that says:
+
+ WARNING: MemorySanitizer: use-of-uninitialized-value... in mmap-thread-lookup.c
+
+Initializing the go variable to 0 silences this harmless warning.
+
+Committer warning:
+
+This was harmless, just a simple test writing whatever was at that
+sizeof(int) memory area just to signal another thread blocked reading
+that file created with pipe(). Initialize it tho so that we don't get
+this warning.
+
+Signed-off-by: Numfor Mbiziwo-Tiapo <nums@google.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Ian Rogers <irogers@google.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Mark Drayton <mbd@fb.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Song Liu <songliubraving@fb.com>
+Cc: Stephane Eranian <eranian@google.com>
+Link: http://lkml.kernel.org/r/20190702173716.181223-1-nums@google.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ tools/perf/tests/mmap-thread-lookup.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/tools/perf/tests/mmap-thread-lookup.c b/tools/perf/tests/mmap-thread-lookup.c
+index 0c5ce44f723f..e5d6e6584001 100644
+--- a/tools/perf/tests/mmap-thread-lookup.c
++++ b/tools/perf/tests/mmap-thread-lookup.c
+@@ -49,7 +49,7 @@ static void *thread_fn(void *arg)
+ {
+ struct thread_data *td = arg;
+ ssize_t ret;
+- int go;
++ int go = 0;
+
+ if (thread_init(td))
+ return NULL;
+--
+2.20.1
+
--- /dev/null
+From 2addb0150dbe9fba766df4311eb38c886b017f98 Mon Sep 17 00:00:00 2001
+From: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Date: Wed, 14 Jun 2017 11:26:58 -0500
+Subject: perf/x86/amd/uncore: Get correct number of cores sharing last level
+ cache
+
+In Family 17h, the number of cores sharing a cache level is obtained
+from the Cache Properties CPUID leaf (0x8000001d) by passing in the
+cache level in ECX. In prior families, a cache level of 2 was used to
+determine this information.
+
+To get the right information, irrespective of Family, iterate over
+the cache levels using CPUID 0x8000001d. The last level cache is the
+last value to return a non-zero value in EAX.
+
+Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Borislav Petkov <bp@suse.de>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/5ab569025b39cdfaeca55b571d78c0fc800bdb69.1497452002.git.Janakarajan.Natarajan@amd.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+---
+ arch/x86/events/amd/uncore.c | 19 ++++++++++++++++---
+ 1 file changed, 16 insertions(+), 3 deletions(-)
+
+diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
+index 094973313037..10f023799f11 100644
+--- a/arch/x86/events/amd/uncore.c
++++ b/arch/x86/events/amd/uncore.c
+@@ -378,11 +378,24 @@ static int amd_uncore_cpu_starting(unsigned int cpu)
+
+ if (amd_uncore_llc) {
+ unsigned int apicid = cpu_data(cpu).apicid;
+- unsigned int nshared;
++ unsigned int nshared, subleaf, prev_eax = 0;
+
+ uncore = *per_cpu_ptr(amd_uncore_llc, cpu);
+- cpuid_count(0x8000001d, 2, &eax, &ebx, &ecx, &edx);
+- nshared = ((eax >> 14) & 0xfff) + 1;
++ /*
++ * Iterate over Cache Topology Definition leaves until no
++ * more cache descriptions are available.
++ */
++ for (subleaf = 0; subleaf < 5; subleaf++) {
++ cpuid_count(0x8000001d, subleaf, &eax, &ebx, &ecx, &edx);
++
++ /* EAX[0:4] gives type of cache */
++ if (!(eax & 0x1f))
++ break;
++
++ prev_eax = eax;
++ }
++ nshared = ((prev_eax >> 14) & 0xfff) + 1;
++
+ uncore->id = apicid - (apicid % nshared);
+
+ uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_llc);
+--
+2.20.1
+
--- /dev/null
+From 1e14c77a0593553e7246f1d73949dc266bee7b9a Mon Sep 17 00:00:00 2001
+From: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Date: Mon, 16 Jan 2017 17:36:21 -0600
+Subject: perf/x86/amd/uncore: Rename 'L2' to 'LLC'
+
+This patch renames L2 counters to LLC counters. In AMD Family17h
+processors, L3 cache counter is supported.
+
+Since older families have at most L2 counters, last level cache (LLC)
+indicates L2/L3 based on the family.
+
+Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Stephane Eranian <eranian@google.com>
+Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vince Weaver <vincent.weaver@maine.edu>
+Link: http://lkml.kernel.org/r/5d8cd8736d8d578354597a548e64ff16210c319b.1484598705.git.Janakarajan.Natarajan@amd.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+---
+ arch/x86/events/amd/uncore.c | 98 ++++++++++++++++++------------------
+ 1 file changed, 49 insertions(+), 49 deletions(-)
+
+diff --git a/arch/x86/events/amd/uncore.c b/arch/x86/events/amd/uncore.c
+index 65577f081d07..094973313037 100644
+--- a/arch/x86/events/amd/uncore.c
++++ b/arch/x86/events/amd/uncore.c
+@@ -25,7 +25,7 @@
+ #define MAX_COUNTERS NUM_COUNTERS_NB
+
+ #define RDPMC_BASE_NB 6
+-#define RDPMC_BASE_L2 10
++#define RDPMC_BASE_LLC 10
+
+ #define COUNTER_SHIFT 16
+
+@@ -45,30 +45,30 @@ struct amd_uncore {
+ };
+
+ static struct amd_uncore * __percpu *amd_uncore_nb;
+-static struct amd_uncore * __percpu *amd_uncore_l2;
++static struct amd_uncore * __percpu *amd_uncore_llc;
+
+ static struct pmu amd_nb_pmu;
+-static struct pmu amd_l2_pmu;
++static struct pmu amd_llc_pmu;
+
+ static cpumask_t amd_nb_active_mask;
+-static cpumask_t amd_l2_active_mask;
++static cpumask_t amd_llc_active_mask;
+
+ static bool is_nb_event(struct perf_event *event)
+ {
+ return event->pmu->type == amd_nb_pmu.type;
+ }
+
+-static bool is_l2_event(struct perf_event *event)
++static bool is_llc_event(struct perf_event *event)
+ {
+- return event->pmu->type == amd_l2_pmu.type;
++ return event->pmu->type == amd_llc_pmu.type;
+ }
+
+ static struct amd_uncore *event_to_amd_uncore(struct perf_event *event)
+ {
+ if (is_nb_event(event) && amd_uncore_nb)
+ return *per_cpu_ptr(amd_uncore_nb, event->cpu);
+- else if (is_l2_event(event) && amd_uncore_l2)
+- return *per_cpu_ptr(amd_uncore_l2, event->cpu);
++ else if (is_llc_event(event) && amd_uncore_llc)
++ return *per_cpu_ptr(amd_uncore_llc, event->cpu);
+
+ return NULL;
+ }
+@@ -183,16 +183,16 @@ static int amd_uncore_event_init(struct perf_event *event)
+ return -ENOENT;
+
+ /*
+- * NB and L2 counters (MSRs) are shared across all cores that share the
+- * same NB / L2 cache. Interrupts can be directed to a single target
+- * core, however, event counts generated by processes running on other
+- * cores cannot be masked out. So we do not support sampling and
+- * per-thread events.
++ * NB and Last level cache counters (MSRs) are shared across all cores
++ * that share the same NB / Last level cache. Interrupts can be directed
++ * to a single target core, however, event counts generated by processes
++ * running on other cores cannot be masked out. So we do not support
++ * sampling and per-thread events.
+ */
+ if (is_sampling_event(event) || event->attach_state & PERF_ATTACH_TASK)
+ return -EINVAL;
+
+- /* NB and L2 counters do not have usr/os/guest/host bits */
++ /* NB and Last level cache counters do not have usr/os/guest/host bits */
+ if (event->attr.exclude_user || event->attr.exclude_kernel ||
+ event->attr.exclude_host || event->attr.exclude_guest)
+ return -EINVAL;
+@@ -226,8 +226,8 @@ static ssize_t amd_uncore_attr_show_cpumask(struct device *dev,
+
+ if (pmu->type == amd_nb_pmu.type)
+ active_mask = &amd_nb_active_mask;
+- else if (pmu->type == amd_l2_pmu.type)
+- active_mask = &amd_l2_active_mask;
++ else if (pmu->type == amd_llc_pmu.type)
++ active_mask = &amd_llc_active_mask;
+ else
+ return 0;
+
+@@ -276,7 +276,7 @@ static struct pmu amd_nb_pmu = {
+ .read = amd_uncore_read,
+ };
+
+-static struct pmu amd_l2_pmu = {
++static struct pmu amd_llc_pmu = {
+ .task_ctx_nr = perf_invalid_context,
+ .attr_groups = amd_uncore_attr_groups,
+ .name = "amd_l2",
+@@ -296,7 +296,7 @@ static struct amd_uncore *amd_uncore_alloc(unsigned int cpu)
+
+ static int amd_uncore_cpu_up_prepare(unsigned int cpu)
+ {
+- struct amd_uncore *uncore_nb = NULL, *uncore_l2;
++ struct amd_uncore *uncore_nb = NULL, *uncore_llc;
+
+ if (amd_uncore_nb) {
+ uncore_nb = amd_uncore_alloc(cpu);
+@@ -312,18 +312,18 @@ static int amd_uncore_cpu_up_prepare(unsigned int cpu)
+ *per_cpu_ptr(amd_uncore_nb, cpu) = uncore_nb;
+ }
+
+- if (amd_uncore_l2) {
+- uncore_l2 = amd_uncore_alloc(cpu);
+- if (!uncore_l2)
++ if (amd_uncore_llc) {
++ uncore_llc = amd_uncore_alloc(cpu);
++ if (!uncore_llc)
+ goto fail;
+- uncore_l2->cpu = cpu;
+- uncore_l2->num_counters = NUM_COUNTERS_L2;
+- uncore_l2->rdpmc_base = RDPMC_BASE_L2;
+- uncore_l2->msr_base = MSR_F16H_L2I_PERF_CTL;
+- uncore_l2->active_mask = &amd_l2_active_mask;
+- uncore_l2->pmu = &amd_l2_pmu;
+- uncore_l2->id = -1;
+- *per_cpu_ptr(amd_uncore_l2, cpu) = uncore_l2;
++ uncore_llc->cpu = cpu;
++ uncore_llc->num_counters = NUM_COUNTERS_L2;
++ uncore_llc->rdpmc_base = RDPMC_BASE_LLC;
++ uncore_llc->msr_base = MSR_F16H_L2I_PERF_CTL;
++ uncore_llc->active_mask = &amd_llc_active_mask;
++ uncore_llc->pmu = &amd_llc_pmu;
++ uncore_llc->id = -1;
++ *per_cpu_ptr(amd_uncore_llc, cpu) = uncore_llc;
+ }
+
+ return 0;
+@@ -376,17 +376,17 @@ static int amd_uncore_cpu_starting(unsigned int cpu)
+ *per_cpu_ptr(amd_uncore_nb, cpu) = uncore;
+ }
+
+- if (amd_uncore_l2) {
++ if (amd_uncore_llc) {
+ unsigned int apicid = cpu_data(cpu).apicid;
+ unsigned int nshared;
+
+- uncore = *per_cpu_ptr(amd_uncore_l2, cpu);
++ uncore = *per_cpu_ptr(amd_uncore_llc, cpu);
+ cpuid_count(0x8000001d, 2, &eax, &ebx, &ecx, &edx);
+ nshared = ((eax >> 14) & 0xfff) + 1;
+ uncore->id = apicid - (apicid % nshared);
+
+- uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_l2);
+- *per_cpu_ptr(amd_uncore_l2, cpu) = uncore;
++ uncore = amd_uncore_find_online_sibling(uncore, amd_uncore_llc);
++ *per_cpu_ptr(amd_uncore_llc, cpu) = uncore;
+ }
+
+ return 0;
+@@ -419,8 +419,8 @@ static int amd_uncore_cpu_online(unsigned int cpu)
+ if (amd_uncore_nb)
+ uncore_online(cpu, amd_uncore_nb);
+
+- if (amd_uncore_l2)
+- uncore_online(cpu, amd_uncore_l2);
++ if (amd_uncore_llc)
++ uncore_online(cpu, amd_uncore_llc);
+
+ return 0;
+ }
+@@ -456,8 +456,8 @@ static int amd_uncore_cpu_down_prepare(unsigned int cpu)
+ if (amd_uncore_nb)
+ uncore_down_prepare(cpu, amd_uncore_nb);
+
+- if (amd_uncore_l2)
+- uncore_down_prepare(cpu, amd_uncore_l2);
++ if (amd_uncore_llc)
++ uncore_down_prepare(cpu, amd_uncore_llc);
+
+ return 0;
+ }
+@@ -479,8 +479,8 @@ static int amd_uncore_cpu_dead(unsigned int cpu)
+ if (amd_uncore_nb)
+ uncore_dead(cpu, amd_uncore_nb);
+
+- if (amd_uncore_l2)
+- uncore_dead(cpu, amd_uncore_l2);
++ if (amd_uncore_llc)
++ uncore_dead(cpu, amd_uncore_llc);
+
+ return 0;
+ }
+@@ -510,16 +510,16 @@ static int __init amd_uncore_init(void)
+ }
+
+ if (boot_cpu_has(X86_FEATURE_PERFCTR_L2)) {
+- amd_uncore_l2 = alloc_percpu(struct amd_uncore *);
+- if (!amd_uncore_l2) {
++ amd_uncore_llc = alloc_percpu(struct amd_uncore *);
++ if (!amd_uncore_llc) {
+ ret = -ENOMEM;
+- goto fail_l2;
++ goto fail_llc;
+ }
+- ret = perf_pmu_register(&amd_l2_pmu, amd_l2_pmu.name, -1);
++ ret = perf_pmu_register(&amd_llc_pmu, amd_llc_pmu.name, -1);
+ if (ret)
+- goto fail_l2;
++ goto fail_llc;
+
+- pr_info("perf: AMD L2I counters detected\n");
++ pr_info("perf: AMD LLC counters detected\n");
+ ret = 0;
+ }
+
+@@ -529,7 +529,7 @@ static int __init amd_uncore_init(void)
+ if (cpuhp_setup_state(CPUHP_PERF_X86_AMD_UNCORE_PREP,
+ "PERF_X86_AMD_UNCORE_PREP",
+ amd_uncore_cpu_up_prepare, amd_uncore_cpu_dead))
+- goto fail_l2;
++ goto fail_llc;
+
+ if (cpuhp_setup_state(CPUHP_AP_PERF_X86_AMD_UNCORE_STARTING,
+ "AP_PERF_X86_AMD_UNCORE_STARTING",
+@@ -546,11 +546,11 @@ static int __init amd_uncore_init(void)
+ cpuhp_remove_state(CPUHP_AP_PERF_X86_AMD_UNCORE_STARTING);
+ fail_prep:
+ cpuhp_remove_state(CPUHP_PERF_X86_AMD_UNCORE_PREP);
+-fail_l2:
++fail_llc:
+ if (boot_cpu_has(X86_FEATURE_PERFCTR_NB))
+ perf_pmu_unregister(&amd_nb_pmu);
+- if (amd_uncore_l2)
+- free_percpu(amd_uncore_l2);
++ if (amd_uncore_llc)
++ free_percpu(amd_uncore_llc);
+ fail_nb:
+ if (amd_uncore_nb)
+ free_percpu(amd_uncore_nb);
+--
+2.20.1
+
--- /dev/null
+From 9d92752f990af54d105d0eb6b9e65e2286472c38 Mon Sep 17 00:00:00 2001
+From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Date: Tue, 28 May 2019 14:04:02 +0900
+Subject: phy: renesas: rcar-gen2: Fix memory leak at error paths
+
+[ Upstream commit d4a36e82924d3305a17ac987a510f3902df5a4b2 ]
+
+This patch fixes memory leak at error paths of the probe function.
+In for_each_child_of_node, if the loop returns, the driver should
+call of_put_node() before returns.
+
+Reported-by: Julia Lawall <julia.lawall@lip6.fr>
+Fixes: 1233f59f745b237 ("phy: Renesas R-Car Gen2 PHY driver")
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/phy/phy-rcar-gen2.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/phy/phy-rcar-gen2.c b/drivers/phy/phy-rcar-gen2.c
+index 97d4dd6ea924..aa02b19b7e0e 100644
+--- a/drivers/phy/phy-rcar-gen2.c
++++ b/drivers/phy/phy-rcar-gen2.c
+@@ -288,6 +288,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
+ error = of_property_read_u32(np, "reg", &channel_num);
+ if (error || channel_num > 2) {
+ dev_err(dev, "Invalid \"reg\" property\n");
++ of_node_put(np);
+ return error;
+ }
+ channel->select_mask = select_mask[channel_num];
+@@ -303,6 +304,7 @@ static int rcar_gen2_phy_probe(struct platform_device *pdev)
+ &rcar_gen2_phy_ops);
+ if (IS_ERR(phy->phy)) {
+ dev_err(dev, "Failed to create PHY\n");
++ of_node_put(np);
+ return PTR_ERR(phy->phy);
+ }
+ phy_set_drvdata(phy->phy, phy);
+--
+2.20.1
+
--- /dev/null
+From 45204a21a70bc3bc69c7a025e60f5b8b59d4a5aa Mon Sep 17 00:00:00 2001
+From: Wen Yang <wen.yang99@zte.com.cn>
+Date: Mon, 15 Apr 2019 14:24:02 +0800
+Subject: pinctrl: rockchip: fix leaked of_node references
+
+[ Upstream commit 3c89c70634bb0b6f48512de873e7a45c7e1fbaa5 ]
+
+The call to of_parse_phandle returns a node pointer with refcount
+incremented thus it must be explicitly decremented after the last
+usage.
+
+Detected by coccinelle with the following warnings:
+./drivers/pinctrl/pinctrl-rockchip.c:3221:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function.
+./drivers/pinctrl/pinctrl-rockchip.c:3223:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 3196, but without a corresponding object release within this function.
+
+Signed-off-by: Wen Yang <wen.yang99@zte.com.cn>
+Cc: Linus Walleij <linus.walleij@linaro.org>
+Cc: Heiko Stuebner <heiko@sntech.de>
+Cc: linux-gpio@vger.kernel.org
+Cc: linux-rockchip@lists.infradead.org
+Cc: linux-kernel@vger.kernel.org
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/pinctrl/pinctrl-rockchip.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/pinctrl/pinctrl-rockchip.c b/drivers/pinctrl/pinctrl-rockchip.c
+index f826793e972c..417cd3bd7e0c 100644
+--- a/drivers/pinctrl/pinctrl-rockchip.c
++++ b/drivers/pinctrl/pinctrl-rockchip.c
+@@ -2208,6 +2208,7 @@ static int rockchip_get_bank_data(struct rockchip_pin_bank *bank,
+ base,
+ &rockchip_regmap_config);
+ }
++ of_node_put(node);
+ }
+
+ bank->irq = irq_of_parse_and_map(bank->of_node, 0);
+--
+2.20.1
+
--- /dev/null
+From 86c073b6ef1e9302fec3cfb527007907cb244456 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter <chunkeey@gmail.com>
+Date: Sat, 15 Jun 2019 17:23:13 +0200
+Subject: powerpc/4xx/uic: clear pending interrupt after irq type/pol change
+
+[ Upstream commit 3ab3a0689e74e6aa5b41360bc18861040ddef5b1 ]
+
+When testing out gpio-keys with a button, a spurious
+interrupt (and therefore a key press or release event)
+gets triggered as soon as the driver enables the irq
+line for the first time.
+
+This patch clears any potential bogus generated interrupt
+that was caused by the switching of the associated irq's
+type and polarity.
+
+Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/sysdev/uic.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/powerpc/sysdev/uic.c b/arch/powerpc/sysdev/uic.c
+index a00949f3e378..a8ebc96dfed2 100644
+--- a/arch/powerpc/sysdev/uic.c
++++ b/arch/powerpc/sysdev/uic.c
+@@ -158,6 +158,7 @@ static int uic_set_irq_type(struct irq_data *d, unsigned int flow_type)
+
+ mtdcr(uic->dcrbase + UIC_PR, pr);
+ mtdcr(uic->dcrbase + UIC_TR, tr);
++ mtdcr(uic->dcrbase + UIC_SR, ~mask);
+
+ raw_spin_unlock_irqrestore(&uic->lock, flags);
+
+--
+2.20.1
+
--- /dev/null
+From 6c2fc13ed85203f1bc419b60b6926a1c3c85eda5 Mon Sep 17 00:00:00 2001
+From: Masahiro Yamada <yamada.masahiro@socionext.com>
+Date: Fri, 5 Jul 2019 19:01:43 +0900
+Subject: powerpc/boot: add {get, put}_unaligned_be32 to xz_config.h
+
+[ Upstream commit 9e005b761e7ad153dcf40a6cba1d681fe0830ac6 ]
+
+The next commit will make the way of passing CONFIG options more robust.
+Unfortunately, it would uncover another hidden issue; without this
+commit, skiroot_defconfig would be broken like this:
+
+| WRAP arch/powerpc/boot/zImage.pseries
+| arch/powerpc/boot/wrapper.a(decompress.o): In function `bcj_powerpc.isra.10':
+| decompress.c:(.text+0x720): undefined reference to `get_unaligned_be32'
+| decompress.c:(.text+0x7a8): undefined reference to `put_unaligned_be32'
+| make[1]: *** [arch/powerpc/boot/Makefile;383: arch/powerpc/boot/zImage.pseries] Error 1
+| make: *** [arch/powerpc/Makefile;295: zImage] Error 2
+
+skiroot_defconfig is the only defconfig that enables CONFIG_KERNEL_XZ
+for ppc, which has never been correctly built before.
+
+I figured out the root cause in lib/decompress_unxz.c:
+
+| #ifdef CONFIG_PPC
+| # define XZ_DEC_POWERPC
+| #endif
+
+CONFIG_PPC is undefined here in the ppc bootwrapper because autoconf.h
+is not included except by arch/powerpc/boot/serial.c
+
+XZ_DEC_POWERPC is not defined, therefore, bcj_powerpc() is not compiled
+for the bootwrapper.
+
+With the next commit passing CONFIG_PPC correctly, we would realize that
+{get,put}_unaligned_be32 was missing.
+
+Unlike the other decompressors, the ppc bootwrapper duplicates all the
+necessary helpers in arch/powerpc/boot/.
+
+The other architectures define __KERNEL__ and pull in helpers for
+building the decompressors.
+
+If ppc bootwrapper had defined __KERNEL__, lib/xz/xz_private.h would
+have included <asm/unaligned.h>:
+
+| #ifdef __KERNEL__
+| # include <linux/xz.h>
+| # include <linux/kernel.h>
+| # include <asm/unaligned.h>
+
+However, doing so would cause tons of definition conflicts since the
+bootwrapper has duplicated everything.
+
+I just added copies of {get,put}_unaligned_be32, following the
+bootwrapper coding convention.
+
+Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190705100144.28785-1-yamada.masahiro@socionext.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/boot/xz_config.h | 20 ++++++++++++++++++++
+ 1 file changed, 20 insertions(+)
+
+diff --git a/arch/powerpc/boot/xz_config.h b/arch/powerpc/boot/xz_config.h
+index 5c6afdbca642..21b52c15aafc 100644
+--- a/arch/powerpc/boot/xz_config.h
++++ b/arch/powerpc/boot/xz_config.h
+@@ -19,10 +19,30 @@ static inline uint32_t swab32p(void *p)
+
+ #ifdef __LITTLE_ENDIAN__
+ #define get_le32(p) (*((uint32_t *) (p)))
++#define cpu_to_be32(x) swab32(x)
++static inline u32 be32_to_cpup(const u32 *p)
++{
++ return swab32p((u32 *)p);
++}
+ #else
+ #define get_le32(p) swab32p(p)
++#define cpu_to_be32(x) (x)
++static inline u32 be32_to_cpup(const u32 *p)
++{
++ return *p;
++}
+ #endif
+
++static inline uint32_t get_unaligned_be32(const void *p)
++{
++ return be32_to_cpup(p);
++}
++
++static inline void put_unaligned_be32(u32 val, void *p)
++{
++ *((u32 *)p) = cpu_to_be32(val);
++}
++
+ #define memeq(a, b, size) (memcmp(a, b, size) == 0)
+ #define memzero(buf, size) memset(buf, 0, size)
+
+--
+2.20.1
+
--- /dev/null
+From 8298a92b3c25abfa4fb386c0aa7906b5bf5d5115 Mon Sep 17 00:00:00 2001
+From: Oliver O'Halloran <oohall@gmail.com>
+Date: Thu, 11 Jul 2019 01:05:17 +1000
+Subject: powerpc/eeh: Handle hugepages in ioremap space
+
+[ Upstream commit 33439620680be5225c1b8806579a291e0d761ca0 ]
+
+In commit 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap
+space") support for using hugepages in the vmalloc and ioremap areas was
+enabled for radix. Unfortunately this broke EEH MMIO error checking.
+
+Detection works by inserting a hook which checks the results of the
+ioreadXX() set of functions. When a read returns a 0xFFs response we
+need to check for an error which we do by mapping the (virtual) MMIO
+address back to a physical address, then mapping physical address to a
+PCI device via an interval tree.
+
+When translating virt -> phys we currently assume the ioremap space is
+only populated by PAGE_SIZE mappings. If a hugepage mapping is found we
+emit a WARN_ON(), but otherwise handles the check as though a normal
+page was found. In pathalogical cases such as copying a buffer
+containing a lot of 0xFFs from BAR memory this can result in the system
+not booting because it's too busy printing WARN_ON()s.
+
+There's no real reason to assume huge pages can't be present and we're
+prefectly capable of handling them, so do that.
+
+Fixes: 4a7b06c157a2 ("powerpc/eeh: Handle hugepages in ioremap space")
+Reported-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
+Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
+Tested-by: Sachin Sant <sachinp@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://lore.kernel.org/r/20190710150517.27114-1-oohall@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kernel/eeh.c | 15 ++++++++++++---
+ 1 file changed, 12 insertions(+), 3 deletions(-)
+
+diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
+index 8336b9016ca9..a7f229e59892 100644
+--- a/arch/powerpc/kernel/eeh.c
++++ b/arch/powerpc/kernel/eeh.c
+@@ -362,10 +362,19 @@ static inline unsigned long eeh_token_to_phys(unsigned long token)
+ NULL, &hugepage_shift);
+ if (!ptep)
+ return token;
+- WARN_ON(hugepage_shift);
+- pa = pte_pfn(*ptep) << PAGE_SHIFT;
+
+- return pa | (token & (PAGE_SIZE-1));
++ pa = pte_pfn(*ptep);
++
++ /* On radix we can do hugepage mappings for io, so handle that */
++ if (hugepage_shift) {
++ pa <<= hugepage_shift;
++ pa |= token & ((1ul << hugepage_shift) - 1);
++ } else {
++ pa <<= PAGE_SHIFT;
++ pa |= token & (PAGE_SIZE - 1);
++ }
++
++ return pa;
+ }
+
+ /*
+--
+2.20.1
+
--- /dev/null
+From 492d412809cefcd0a52cb20f232ebd3563be63b4 Mon Sep 17 00:00:00 2001
+From: Alexey Kardashevskiy <aik@ozlabs.ru>
+Date: Wed, 5 Jun 2019 13:38:14 +1000
+Subject: powerpc/pci/of: Fix OF flags parsing for 64bit BARs
+
+[ Upstream commit df5be5be8735ef2ae80d5ae1f2453cd81a035c4b ]
+
+When the firmware does PCI BAR resource allocation, it passes the assigned
+addresses and flags (prefetch/64bit/...) via the "reg" property of
+a PCI device device tree node so the kernel does not need to do
+resource allocation.
+
+The flags are stored in resource::flags - the lower byte stores
+PCI_BASE_ADDRESS_SPACE/etc bits and the other bytes are IORESOURCE_IO/etc.
+Some flags from PCI_BASE_ADDRESS_xxx and IORESOURCE_xxx are duplicated,
+such as PCI_BASE_ADDRESS_MEM_PREFETCH/PCI_BASE_ADDRESS_MEM_TYPE_64/etc.
+When parsing the "reg" property, we copy the prefetch flag but we skip
+on PCI_BASE_ADDRESS_MEM_TYPE_64 which leaves the flags out of sync.
+
+The missing IORESOURCE_MEM_64 flag comes into play under 2 conditions:
+1. we remove PCI_PROBE_ONLY for pseries (by hacking pSeries_setup_arch()
+or by passing "/chosen/linux,pci-probe-only");
+2. we request resource alignment (by passing pci=resource_alignment=
+via the kernel cmd line to request PAGE_SIZE alignment or defining
+ppc_md.pcibios_default_alignment which returns anything but 0). Note that
+the alignment requests are ignored if PCI_PROBE_ONLY is enabled.
+
+With 1) and 2), the generic PCI code in the kernel unconditionally
+decides to:
+- reassign the BARs in pci_specified_resource_alignment() (works fine)
+- write new BARs to the device - this fails for 64bit BARs as the generic
+code looks at IORESOURCE_MEM_64 (not set) and writes only lower 32bits
+of the BAR and leaves the upper 32bit unmodified which breaks BAR mapping
+in the hypervisor.
+
+This fixes the issue by copying the flag. This is useful if we want to
+enforce certain BAR alignment per platform as handling subpage sized BARs
+is proven to cause problems with hotplug (SLOF already aligns BARs to 64k).
+
+Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
+Reviewed-by: Sam Bobroff <sbobroff@linux.ibm.com>
+Reviewed-by: Oliver O'Halloran <oohall@gmail.com>
+Reviewed-by: Shawn Anastasio <shawn@anastas.io>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/kernel/pci_of_scan.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
+index ea3d98115b88..e0648a09d9c8 100644
+--- a/arch/powerpc/kernel/pci_of_scan.c
++++ b/arch/powerpc/kernel/pci_of_scan.c
+@@ -45,6 +45,8 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
+ if (addr0 & 0x02000000) {
+ flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
+ flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
++ if (flags & PCI_BASE_ADDRESS_MEM_TYPE_64)
++ flags |= IORESOURCE_MEM_64;
+ flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+ if (addr0 & 0x40000000)
+ flags |= IORESOURCE_PREFETCH
+--
+2.20.1
+
--- /dev/null
+From 7647474b66472a921031954b170d84472d286599 Mon Sep 17 00:00:00 2001
+From: "Liu, Changcheng" <changcheng.liu@intel.com>
+Date: Fri, 28 Jun 2019 14:16:13 +0800
+Subject: RDMA/i40iw: Set queue pair state when being queried
+
+[ Upstream commit 2e67e775845373905d2c2aecb9062c2c4352a535 ]
+
+The API for ib_query_qp requires the driver to set qp_state and
+cur_qp_state on return, add the missing sets.
+
+Fixes: d37498417947 ("i40iw: add files for iwarp interface")
+Signed-off-by: Changcheng Liu <changcheng.liu@aliyun.com>
+Acked-by: Shiraz Saleem <shiraz.saleem@intel.com>
+Reviewed-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/hw/i40iw/i40iw_verbs.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/infiniband/hw/i40iw/i40iw_verbs.c b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+index 095912fb3201..c3d2400e36b9 100644
+--- a/drivers/infiniband/hw/i40iw/i40iw_verbs.c
++++ b/drivers/infiniband/hw/i40iw/i40iw_verbs.c
+@@ -812,6 +812,8 @@ static int i40iw_query_qp(struct ib_qp *ibqp,
+ struct i40iw_qp *iwqp = to_iwqp(ibqp);
+ struct i40iw_sc_qp *qp = &iwqp->sc_qp;
+
++ attr->qp_state = iwqp->ibqp_state;
++ attr->cur_qp_state = attr->qp_state;
+ attr->qp_access_flags = 0;
+ attr->cap.max_send_wr = qp->qp_uk.sq_size;
+ attr->cap.max_recv_wr = qp->qp_uk.rq_size;
+--
+2.20.1
+
--- /dev/null
+From 07ad79d46087bb13ddfde87f199d51c82427c76d Mon Sep 17 00:00:00 2001
+From: Konstantin Taranov <konstantin.taranov@inf.ethz.ch>
+Date: Thu, 27 Jun 2019 16:06:43 +0200
+Subject: RDMA/rxe: Fill in wc byte_len with IB_WC_RECV_RDMA_WITH_IMM
+
+[ Upstream commit bdce1290493caa3f8119f24b5dacc3fb7ca27389 ]
+
+Calculate the correct byte_len on the receiving side when a work
+completion is generated with IB_WC_RECV_RDMA_WITH_IMM opcode.
+
+According to the IBA byte_len must indicate the number of written bytes,
+whereas it was always equal to zero for the IB_WC_RECV_RDMA_WITH_IMM
+opcode, even though data was transferred.
+
+Fixes: 8700e3e7c485 ("Soft RoCE driver")
+Signed-off-by: Konstantin Taranov <konstantin.taranov@inf.ethz.ch>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/infiniband/sw/rxe/rxe_resp.c | 5 ++++-
+ drivers/infiniband/sw/rxe/rxe_verbs.h | 1 +
+ 2 files changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c
+index 297653ab4004..5bfea23f3b60 100644
+--- a/drivers/infiniband/sw/rxe/rxe_resp.c
++++ b/drivers/infiniband/sw/rxe/rxe_resp.c
+@@ -432,6 +432,7 @@ static enum resp_states check_rkey(struct rxe_qp *qp,
+ qp->resp.va = reth_va(pkt);
+ qp->resp.rkey = reth_rkey(pkt);
+ qp->resp.resid = reth_len(pkt);
++ qp->resp.length = reth_len(pkt);
+ }
+ access = (pkt->mask & RXE_READ_MASK) ? IB_ACCESS_REMOTE_READ
+ : IB_ACCESS_REMOTE_WRITE;
+@@ -841,7 +842,9 @@ static enum resp_states do_complete(struct rxe_qp *qp,
+ pkt->mask & RXE_WRITE_MASK) ?
+ IB_WC_RECV_RDMA_WITH_IMM : IB_WC_RECV;
+ wc->vendor_err = 0;
+- wc->byte_len = wqe->dma.length - wqe->dma.resid;
++ wc->byte_len = (pkt->mask & RXE_IMMDT_MASK &&
++ pkt->mask & RXE_WRITE_MASK) ?
++ qp->resp.length : wqe->dma.length - wqe->dma.resid;
+
+ /* fields after byte_len are different between kernel and user
+ * space
+diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.h b/drivers/infiniband/sw/rxe/rxe_verbs.h
+index cac1d52a08f0..47003d2a4a46 100644
+--- a/drivers/infiniband/sw/rxe/rxe_verbs.h
++++ b/drivers/infiniband/sw/rxe/rxe_verbs.h
+@@ -209,6 +209,7 @@ struct rxe_resp_info {
+ struct rxe_mem *mr;
+ u32 resid;
+ u32 rkey;
++ u32 length;
+ u64 atomic_orig;
+
+ /* SRQ only */
+--
+2.20.1
+
--- /dev/null
+From 63e9e692ad23a50f750020d2ff530bb1b47f7c33 Mon Sep 17 00:00:00 2001
+From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
+Date: Thu, 27 Jun 2019 00:08:01 +0530
+Subject: recordmcount: Fix spurious mcount entries on powerpc
+
+[ Upstream commit 80e5302e4bc85a6b685b7668c36c6487b5f90e9a ]
+
+An impending change to enable HAVE_C_RECORDMCOUNT on powerpc leads to
+warnings such as the following:
+
+ # modprobe kprobe_example
+ ftrace-powerpc: Not expected bl: opcode is 3c4c0001
+ WARNING: CPU: 0 PID: 227 at kernel/trace/ftrace.c:2001 ftrace_bug+0x90/0x318
+ Modules linked in:
+ CPU: 0 PID: 227 Comm: modprobe Not tainted 5.2.0-rc6-00678-g1c329100b942 #2
+ NIP: c000000000264318 LR: c00000000025d694 CTR: c000000000f5cd30
+ REGS: c000000001f2b7b0 TRAP: 0700 Not tainted (5.2.0-rc6-00678-g1c329100b942)
+ MSR: 900000010282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 28228222 XER: 00000000
+ CFAR: c0000000002642fc IRQMASK: 0
+ <snip>
+ NIP [c000000000264318] ftrace_bug+0x90/0x318
+ LR [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
+ Call Trace:
+ [c000000001f2ba40] [0000000000000004] 0x4 (unreliable)
+ [c000000001f2bad0] [c00000000025d694] ftrace_process_locs+0x4f4/0x5e0
+ [c000000001f2bb90] [c00000000020ff10] load_module+0x25b0/0x30c0
+ [c000000001f2bd00] [c000000000210cb0] sys_finit_module+0xc0/0x130
+ [c000000001f2be20] [c00000000000bda4] system_call+0x5c/0x70
+ Instruction dump:
+ 419e0018 2f83ffff 419e00bc 2f83ffea 409e00cc 4800001c 0fe00000 3c62ff96
+ 39000001 39400000 386386d0 480000c4 <0fe00000> 3ce20003 39000001 3c62ff96
+ ---[ end trace 4c438d5cebf78381 ]---
+ ftrace failed to modify
+ [<c0080000012a0008>] 0xc0080000012a0008
+ actual: 01:00:4c:3c
+ Initializing ftrace call sites
+ ftrace record flags: 2000000
+ (0)
+ expected tramp: c00000000006af4c
+
+Looking at the relocation records in __mcount_loc shows a few spurious
+entries:
+
+ RELOCATION RECORDS FOR [__mcount_loc]:
+ OFFSET TYPE VALUE
+ 0000000000000000 R_PPC64_ADDR64 .text.unlikely+0x0000000000000008
+ 0000000000000008 R_PPC64_ADDR64 .text.unlikely+0x0000000000000014
+ 0000000000000010 R_PPC64_ADDR64 .text.unlikely+0x0000000000000060
+ 0000000000000018 R_PPC64_ADDR64 .text.unlikely+0x00000000000000b4
+ 0000000000000020 R_PPC64_ADDR64 .init.text+0x0000000000000008
+ 0000000000000028 R_PPC64_ADDR64 .init.text+0x0000000000000014
+
+The first entry in each section is incorrect. Looking at the
+relocation records, the spurious entries correspond to the
+R_PPC64_ENTRY records:
+
+ RELOCATION RECORDS FOR [.text.unlikely]:
+ OFFSET TYPE VALUE
+ 0000000000000000 R_PPC64_REL64 .TOC.-0x0000000000000008
+ 0000000000000008 R_PPC64_ENTRY *ABS*
+ 0000000000000014 R_PPC64_REL24 _mcount
+ <snip>
+
+The problem is that we are not validating the return value from
+get_mcountsym() in sift_rel_mcount(). With this entry, mcountsym is 0,
+but Elf_r_sym(relp) also ends up being 0. Fix this by ensuring
+mcountsym is valid before processing the entry.
+
+Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
+Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
+Tested-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ scripts/recordmcount.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/scripts/recordmcount.h b/scripts/recordmcount.h
+index b9897e2be404..04151ede8043 100644
+--- a/scripts/recordmcount.h
++++ b/scripts/recordmcount.h
+@@ -326,7 +326,8 @@ static uint_t *sift_rel_mcount(uint_t *mlocp,
+ if (!mcountsym)
+ mcountsym = get_mcountsym(sym0, relp, str0);
+
+- if (mcountsym == Elf_r_sym(relp) && !is_fake_mcount(relp)) {
++ if (mcountsym && mcountsym == Elf_r_sym(relp) &&
++ !is_fake_mcount(relp)) {
+ uint_t const addend =
+ _w(_w(relp->r_offset) - recval + mcount_adjust);
+ mrelp->r_offset = _w(offbase
+--
+2.20.1
+
--- /dev/null
+From b2cb39baf6f074ae390515aff8fb1ae8b9112bc3 Mon Sep 17 00:00:00 2001
+From: Rautkoski Kimmo EXT <ext-kimmo.rautkoski@vaisala.com>
+Date: Fri, 24 May 2019 09:19:22 +0000
+Subject: serial: 8250: Fix TX interrupt handling condition
+
+[ Upstream commit db1b5bc047b3cadaedab3826bba82c3d9e023c4b ]
+
+Interrupt handler checked THRE bit (transmitter holding register
+empty) in LSR to detect if TX fifo is empty.
+In case when there is only receive interrupts the TX handling
+got called because THRE bit in LSR is set when there is no
+transmission (FIFO empty). TX handling caused TX stop, which in
+RS-485 half-duplex mode actually resets receiver FIFO. This is not
+desired during reception because of possible data loss.
+
+The fix is to check if THRI is set in IER in addition of the TX
+fifo status. THRI in IER is set when TX is started and cleared
+when TX is stopped.
+This ensures that TX handling is only called when there is really
+transmission on going and an interrupt for THRE and not when there
+are only RX interrupts.
+
+Signed-off-by: Kimmo Rautkoski <ext-kimmo.rautkoski@vaisala.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/8250/8250_port.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
+index 84474f06dbcf..8f1233324586 100644
+--- a/drivers/tty/serial/8250/8250_port.c
++++ b/drivers/tty/serial/8250/8250_port.c
+@@ -1819,7 +1819,8 @@ int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
+ status = serial8250_rx_chars(up, status);
+ }
+ serial8250_modem_status(up);
+- if ((!up->dma || up->dma->tx_err) && (status & UART_LSR_THRE))
++ if ((!up->dma || up->dma->tx_err) && (status & UART_LSR_THRE) &&
++ (up->ier & UART_IER_THRI))
+ serial8250_tx_chars(up);
+
+ spin_unlock_irqrestore(&port->lock, flags);
+--
+2.20.1
+
--- /dev/null
+From a8ef4617c606732a0e09d39f3b280f1306e06b05 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Mon, 24 Jun 2019 14:35:39 +0200
+Subject: serial: sh-sci: Fix TX DMA buffer flushing and workqueue races
+
+[ Upstream commit 8493eab02608b0e82f67b892aa72882e510c31d0 ]
+
+When uart_flush_buffer() is called, the .flush_buffer() callback zeroes
+the tx_dma_len field. This may race with the work queue function
+handling transmit DMA requests:
+
+ 1. If the buffer is flushed before the first DMA API call,
+ dmaengine_prep_slave_single() may be called with a zero length,
+ causing the DMA request to never complete, leading to messages
+ like:
+
+ rcar-dmac e7300000.dma-controller: Channel Address Error happen
+
+ and, with debug enabled:
+
+ sh-sci e6e88000.serial: sci_dma_tx_work_fn: ffff800639b55000: 0...0, cookie 126
+
+ and DMA timeouts.
+
+ 2. If the buffer is flushed after the first DMA API call, but before
+ the second, dma_sync_single_for_device() may be called with a zero
+ length, causing the transmit data not to be flushed to RAM, and
+ leading to stale data being output.
+
+Fix this by:
+ 1. Letting sci_dma_tx_work_fn() return immediately if the transmit
+ buffer is empty,
+ 2. Extending the critical section to cover all DMA preparational work,
+ so tx_dma_len stays consistent for all of it,
+ 3. Using local copies of circ_buf.head and circ_buf.tail, to make sure
+ they match the actual operation above.
+
+Reported-by: Eugeniu Rosca <erosca@de.adit-jv.com>
+Suggested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
+Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
+Link: https://lore.kernel.org/r/20190624123540.20629-2-geert+renesas@glider.be
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/sh-sci.c | 22 +++++++++++++++-------
+ 1 file changed, 15 insertions(+), 7 deletions(-)
+
+diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
+index 8ec8b3bbaf25..ea35f5144237 100644
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -1291,6 +1291,7 @@ static void work_fn_tx(struct work_struct *work)
+ struct uart_port *port = &s->port;
+ struct circ_buf *xmit = &port->state->xmit;
+ dma_addr_t buf;
++ int head, tail;
+
+ /*
+ * DMA is idle now.
+@@ -1300,16 +1301,23 @@ static void work_fn_tx(struct work_struct *work)
+ * consistent xmit buffer state.
+ */
+ spin_lock_irq(&port->lock);
+- buf = s->tx_dma_addr + (xmit->tail & (UART_XMIT_SIZE - 1));
++ head = xmit->head;
++ tail = xmit->tail;
++ buf = s->tx_dma_addr + (tail & (UART_XMIT_SIZE - 1));
+ s->tx_dma_len = min_t(unsigned int,
+- CIRC_CNT(xmit->head, xmit->tail, UART_XMIT_SIZE),
+- CIRC_CNT_TO_END(xmit->head, xmit->tail, UART_XMIT_SIZE));
+- spin_unlock_irq(&port->lock);
++ CIRC_CNT(head, tail, UART_XMIT_SIZE),
++ CIRC_CNT_TO_END(head, tail, UART_XMIT_SIZE));
++ if (!s->tx_dma_len) {
++ /* Transmit buffer has been flushed */
++ spin_unlock_irq(&port->lock);
++ return;
++ }
+
+ desc = dmaengine_prep_slave_single(chan, buf, s->tx_dma_len,
+ DMA_MEM_TO_DEV,
+ DMA_PREP_INTERRUPT | DMA_CTRL_ACK);
+ if (!desc) {
++ spin_unlock_irq(&port->lock);
+ dev_warn(port->dev, "Failed preparing Tx DMA descriptor\n");
+ /* switch to PIO */
+ sci_tx_dma_release(s, true);
+@@ -1319,20 +1327,20 @@ static void work_fn_tx(struct work_struct *work)
+ dma_sync_single_for_device(chan->device->dev, buf, s->tx_dma_len,
+ DMA_TO_DEVICE);
+
+- spin_lock_irq(&port->lock);
+ desc->callback = sci_dma_tx_complete;
+ desc->callback_param = s;
+- spin_unlock_irq(&port->lock);
+ s->cookie_tx = dmaengine_submit(desc);
+ if (dma_submit_error(s->cookie_tx)) {
++ spin_unlock_irq(&port->lock);
+ dev_warn(port->dev, "Failed submitting Tx DMA descriptor\n");
+ /* switch to PIO */
+ sci_tx_dma_release(s, true);
+ return;
+ }
+
++ spin_unlock_irq(&port->lock);
+ dev_dbg(port->dev, "%s: %p: %d...%d, cookie %d\n",
+- __func__, xmit->buf, xmit->tail, xmit->head, s->cookie_tx);
++ __func__, xmit->buf, tail, head, s->cookie_tx);
+
+ dma_async_issue_pending(chan);
+ }
+--
+2.20.1
+
--- /dev/null
+From 63327bd931c9f047f3c5632d8eababd322f60d39 Mon Sep 17 00:00:00 2001
+From: Geert Uytterhoeven <geert+renesas@glider.be>
+Date: Mon, 24 Jun 2019 14:35:40 +0200
+Subject: serial: sh-sci: Terminate TX DMA during buffer flushing
+
+[ Upstream commit 775b7ffd7d6d5db320d99b0a485c51e04dfcf9f1 ]
+
+While the .flush_buffer() callback clears sci_port.tx_dma_len since
+commit 1cf4a7efdc71cab8 ("serial: sh-sci: Fix race condition causing
+garbage during shutdown"), it does not terminate a transmit DMA
+operation that may be in progress.
+
+Fix this by terminating any pending DMA operations, and resetting the
+corresponding cookie.
+
+Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Reviewed-by: Eugeniu Rosca <erosca@de.adit-jv.com>
+Tested-by: Eugeniu Rosca <erosca@de.adit-jv.com>
+
+Link: https://lore.kernel.org/r/20190624123540.20629-3-geert+renesas@glider.be
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/sh-sci.c | 11 +++++++++--
+ 1 file changed, 9 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
+index bcb997935c5e..8ec8b3bbaf25 100644
+--- a/drivers/tty/serial/sh-sci.c
++++ b/drivers/tty/serial/sh-sci.c
+@@ -1538,11 +1538,18 @@ static void sci_free_dma(struct uart_port *port)
+
+ static void sci_flush_buffer(struct uart_port *port)
+ {
++ struct sci_port *s = to_sci_port(port);
++
+ /*
+ * In uart_flush_buffer(), the xmit circular buffer has just been
+- * cleared, so we have to reset tx_dma_len accordingly.
++ * cleared, so we have to reset tx_dma_len accordingly, and stop any
++ * pending transfers
+ */
+- to_sci_port(port)->tx_dma_len = 0;
++ s->tx_dma_len = 0;
++ if (s->chan_tx) {
++ dmaengine_terminate_async(s->chan_tx);
++ s->cookie_tx = -EINVAL;
++ }
+ }
+ #else /* !CONFIG_SERIAL_SH_SCI_DMA */
+ static inline void sci_request_dma(struct uart_port *port)
+--
+2.20.1
+
net-bridge-mcast-fix-stale-nsrcs-pointer-in-igmp3-mld2-report-handling.patch
net-bridge-mcast-fix-stale-ipv6-hdr-pointer-when-handling-v6-query.patch
net-bridge-stp-don-t-cache-eth-dest-pointer-before-skb-pull.patch
+perf-x86-amd-uncore-rename-l2-to-llc.patch
+perf-x86-amd-uncore-get-correct-number-of-cores-shar.patch
+perf-events-amd-uncore-fix-amd_uncore_llc-id-to-use-.patch
+nfsv4-fix-open-create-exclusive-when-the-server-rebo.patch
+nfsd-increase-drc-cache-limit.patch
+nfsd-give-out-fewer-session-slots-as-limit-approache.patch
+nfsd-fix-performance-limiting-session-calculation.patch
+nfsd-fix-overflow-causing-non-working-mounts-on-1-tb.patch
+drm-panel-simple-fix-panel_simple_dsi_probe.patch
+usb-core-hub-disable-hub-initiated-u1-u2.patch
+tty-max310x-fix-invalid-baudrate-divisors-calculator.patch
+pinctrl-rockchip-fix-leaked-of_node-references.patch
+tty-serial-cpm_uart-fix-init-when-smc-is-relocated.patch
+drm-bridge-tc358767-read-display_props-in-get_modes.patch
+drm-bridge-sii902x-pixel-clock-unit-is-10khz-instead.patch
+memstick-fix-error-cleanup-path-of-memstick_init.patch
+tty-serial-digicolor-fix-digicolor-usart-already-reg.patch
+tty-serial-msm_serial-avoid-system-lockup-condition.patch
+serial-8250-fix-tx-interrupt-handling-condition.patch
+drm-virtio-add-memory-barriers-for-capset-cache.patch
+phy-renesas-rcar-gen2-fix-memory-leak-at-error-paths.patch
+drm-rockchip-properly-adjust-to-a-true-clock-in-adju.patch
+tty-serial_core-set-port-active-bit-in-uart_port_act.patch
+usb-gadget-zero-ffs_io_data.patch
+powerpc-pci-of-fix-of-flags-parsing-for-64bit-bars.patch
+pci-sysfs-ignore-lockdep-for-remove-attribute.patch
+kbuild-add-werror-unknown-warning-option-to-clang_fl.patch
+pci-xilinx-nwl-fix-multi-msi-data-programming.patch
+iio-iio-utils-fix-possible-incorrect-mask-calculatio.patch
+recordmcount-fix-spurious-mcount-entries-on-powerpc.patch
+mfd-core-set-fwnode-for-created-devices.patch
+mfd-arizona-fix-undefined-behavior.patch
+mfd-hi655x-pmic-fix-missing-return-value-check-for-d.patch
+um-silence-lockdep-complaint-about-mmap_sem.patch
+powerpc-4xx-uic-clear-pending-interrupt-after-irq-ty.patch
+rdma-i40iw-set-queue-pair-state-when-being-queried.patch
+serial-sh-sci-terminate-tx-dma-during-buffer-flushin.patch
+serial-sh-sci-fix-tx-dma-buffer-flushing-and-workque.patch
+kallsyms-exclude-kasan-local-symbols-on-s390.patch
+perf-test-mmap-thread-lookup-initialize-variable-to-.patch
+rdma-rxe-fill-in-wc-byte_len-with-ib_wc_recv_rdma_wi.patch
+powerpc-boot-add-get-put-_unaligned_be32-to-xz_confi.patch
+f2fs-avoid-out-of-range-memory-access.patch
+mailbox-handle-failed-named-mailbox-channel-request.patch
+powerpc-eeh-handle-hugepages-in-ioremap-space.patch
+sh-prevent-warnings-when-using-iounmap.patch
+mm-kmemleak.c-fix-check-for-softirq-context.patch
+9p-pass-the-correct-prototype-to-read_cache_page.patch
+mm-mmu_notifier-use-hlist_add_head_rcu.patch
+locking-lockdep-fix-lock-used-or-unused-stats-error.patch
+locking-lockdep-hide-unused-class-variable.patch
--- /dev/null
+From 0214dfa043d5c34a12ec0f9aff9e52cba8208095 Mon Sep 17 00:00:00 2001
+From: Sam Ravnborg <sam@ravnborg.org>
+Date: Thu, 11 Jul 2019 20:52:52 -0700
+Subject: sh: prevent warnings when using iounmap
+
+[ Upstream commit 733f0025f0fb43e382b84db0930ae502099b7e62 ]
+
+When building drm/exynos for sh, as part of an allmodconfig build, the
+following warning triggered:
+
+ exynos7_drm_decon.c: In function `decon_remove':
+ exynos7_drm_decon.c:769:24: warning: unused variable `ctx'
+ struct decon_context *ctx = dev_get_drvdata(&pdev->dev);
+
+The ctx variable is only used as argument to iounmap().
+
+In sh - allmodconfig CONFIG_MMU is not defined
+so it ended up in:
+
+\#define __iounmap(addr) do { } while (0)
+\#define iounmap __iounmap
+
+Fix the warning by introducing a static inline function for iounmap.
+
+This is similar to several other architectures.
+
+Link: http://lkml.kernel.org/r/20190622114208.24427-1-sam@ravnborg.org
+Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
+Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
+Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
+Cc: Rich Felker <dalias@libc.org>
+Cc: Will Deacon <will.deacon@arm.com>
+Cc: Mark Brown <broonie@kernel.org>
+Cc: Inki Dae <inki.dae@samsung.com>
+Cc: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/sh/include/asm/io.h | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
+index 3280a6bfa503..b2592c3864ad 100644
+--- a/arch/sh/include/asm/io.h
++++ b/arch/sh/include/asm/io.h
+@@ -370,7 +370,11 @@ static inline int iounmap_fixed(void __iomem *addr) { return -EINVAL; }
+
+ #define ioremap_nocache ioremap
+ #define ioremap_uc ioremap
+-#define iounmap __iounmap
++
++static inline void iounmap(void __iomem *addr)
++{
++ __iounmap(addr);
++}
+
+ /*
+ * Convert a physical pointer to a virtual kernel pointer for /dev/mem
+--
+2.20.1
+
--- /dev/null
+From 28a58fe0b6d668bc2e3344af5befe5840e33d920 Mon Sep 17 00:00:00 2001
+From: Serge Semin <fancer.lancer@gmail.com>
+Date: Tue, 14 May 2019 13:14:12 +0300
+Subject: tty: max310x: Fix invalid baudrate divisors calculator
+
+[ Upstream commit 35240ba26a932b279a513f66fa4cabfd7af55221 ]
+
+Current calculator doesn't do it' job quite correct. First of all the
+max310x baud-rates generator supports the divisor being less than 16.
+In this case the x2/x4 modes can be used to double or quadruple
+the reference frequency. But the current baud-rate setter function
+just filters all these modes out by the first condition and setups
+these modes only if there is a clocks-baud division remainder. The former
+doesn't seem right at all, since enabling the x2/x4 modes causes the line
+noise tolerance reduction and should be only used as a last resort to
+enable a requested too high baud-rate.
+
+Finally the fraction is supposed to be calculated from D = Fref/(c*baud)
+formulae, but not from D % 16, which causes the precision loss. So to speak
+the current baud-rate calculator code works well only if the baud perfectly
+fits to the uart reference input frequency.
+
+Lets fix the calculator by implementing the algo fully compliant with
+the fractional baud-rate generator described in the datasheet:
+D = Fref / (c*baud), where c={16,8,4} is the x1/x2/x4 rate mode
+respectively, Fref - reference input frequency. The divisor fraction is
+calculated from the same formulae, but making sure it is found with a
+resolution of 0.0625 (four bits).
+
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/max310x.c | 51 ++++++++++++++++++++++--------------
+ 1 file changed, 31 insertions(+), 20 deletions(-)
+
+diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
+index ec3db8d8306c..bacc7e284c0c 100644
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -494,37 +494,48 @@ static bool max310x_reg_precious(struct device *dev, unsigned int reg)
+
+ static int max310x_set_baud(struct uart_port *port, int baud)
+ {
+- unsigned int mode = 0, clk = port->uartclk, div = clk / baud;
++ unsigned int mode = 0, div = 0, frac = 0, c = 0, F = 0;
+
+- /* Check for minimal value for divider */
+- if (div < 16)
+- div = 16;
+-
+- if (clk % baud && (div / 16) < 0x8000) {
++ /*
++ * Calculate the integer divisor first. Select a proper mode
++ * in case if the requested baud is too high for the pre-defined
++ * clocks frequency.
++ */
++ div = port->uartclk / baud;
++ if (div < 8) {
++ /* Mode x4 */
++ c = 4;
++ mode = MAX310X_BRGCFG_4XMODE_BIT;
++ } else if (div < 16) {
+ /* Mode x2 */
++ c = 8;
+ mode = MAX310X_BRGCFG_2XMODE_BIT;
+- clk = port->uartclk * 2;
+- div = clk / baud;
+-
+- if (clk % baud && (div / 16) < 0x8000) {
+- /* Mode x4 */
+- mode = MAX310X_BRGCFG_4XMODE_BIT;
+- clk = port->uartclk * 4;
+- div = clk / baud;
+- }
++ } else {
++ c = 16;
+ }
+
+- max310x_port_write(port, MAX310X_BRGDIVMSB_REG, (div / 16) >> 8);
+- max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div / 16);
+- max310x_port_write(port, MAX310X_BRGCFG_REG, (div % 16) | mode);
++ /* Calculate the divisor in accordance with the fraction coefficient */
++ div /= c;
++ F = c*baud;
++
++ /* Calculate the baud rate fraction */
++ if (div > 0)
++ frac = (16*(port->uartclk % F)) / F;
++ else
++ div = 1;
++
++ max310x_port_write(port, MAX310X_BRGDIVMSB_REG, div >> 8);
++ max310x_port_write(port, MAX310X_BRGDIVLSB_REG, div);
++ max310x_port_write(port, MAX310X_BRGCFG_REG, frac | mode);
+
+- return DIV_ROUND_CLOSEST(clk, div);
++ /* Return the actual baud rate we just programmed */
++ return (16*port->uartclk) / (c*(16*div + frac));
+ }
+
+ static int max310x_update_best_err(unsigned long f, long *besterr)
+ {
+ /* Use baudrate 115200 for calculate error */
+- long err = f % (115200 * 16);
++ long err = f % (460800 * 16);
+
+ if ((*besterr < 0) || (*besterr > err)) {
+ *besterr = err;
+--
+2.20.1
+
--- /dev/null
+From ef311f13f3cd149c628edcf4385448659914de24 Mon Sep 17 00:00:00 2001
+From: Christophe Leroy <christophe.leroy@c-s.fr>
+Date: Wed, 22 May 2019 12:17:11 +0000
+Subject: tty: serial: cpm_uart - fix init when SMC is relocated
+
+[ Upstream commit 06aaa3d066db87e8478522d910285141d44b1e58 ]
+
+SMC relocation can also be activated earlier by the bootloader,
+so the driver's behaviour cannot rely on selected kernel config.
+
+When the SMC is relocated, CPM_CR_INIT_TRX cannot be used.
+
+But the only thing CPM_CR_INIT_TRX does is to clear the
+rstate and tstate registers, so this can be done manually,
+even when SMC is not relocated.
+
+Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
+Fixes: 9ab921201444 ("cpm_uart: fix non-console port startup bug")
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/cpm_uart/cpm_uart_core.c | 17 +++++++++++------
+ 1 file changed, 11 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+index 0040c29f651a..b9e137c03fe3 100644
+--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
++++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+@@ -421,7 +421,16 @@ static int cpm_uart_startup(struct uart_port *port)
+ clrbits16(&pinfo->sccp->scc_sccm, UART_SCCM_RX);
+ }
+ cpm_uart_initbd(pinfo);
+- cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
++ if (IS_SMC(pinfo)) {
++ out_be32(&pinfo->smcup->smc_rstate, 0);
++ out_be32(&pinfo->smcup->smc_tstate, 0);
++ out_be16(&pinfo->smcup->smc_rbptr,
++ in_be16(&pinfo->smcup->smc_rbase));
++ out_be16(&pinfo->smcup->smc_tbptr,
++ in_be16(&pinfo->smcup->smc_tbase));
++ } else {
++ cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
++ }
+ }
+ /* Install interrupt handler. */
+ retval = request_irq(port->irq, cpm_uart_int, 0, "cpm_uart", port);
+@@ -875,16 +884,14 @@ static void cpm_uart_init_smc(struct uart_cpm_port *pinfo)
+ (u8 __iomem *)pinfo->tx_bd_base - DPRAM_BASE);
+
+ /*
+- * In case SMC1 is being relocated...
++ * In case SMC is being relocated...
+ */
+-#if defined (CONFIG_I2C_SPI_SMC1_UCODE_PATCH)
+ out_be16(&up->smc_rbptr, in_be16(&pinfo->smcup->smc_rbase));
+ out_be16(&up->smc_tbptr, in_be16(&pinfo->smcup->smc_tbase));
+ out_be32(&up->smc_rstate, 0);
+ out_be32(&up->smc_tstate, 0);
+ out_be16(&up->smc_brkcr, 1); /* number of break chars */
+ out_be16(&up->smc_brkec, 0);
+-#endif
+
+ /* Set up the uart parameters in the
+ * parameter ram.
+@@ -898,8 +905,6 @@ static void cpm_uart_init_smc(struct uart_cpm_port *pinfo)
+ out_be16(&up->smc_brkec, 0);
+ out_be16(&up->smc_brkcr, 1);
+
+- cpm_line_cr_cmd(pinfo, CPM_CR_INIT_TRX);
+-
+ /* Set UART mode, 8 bit, no parity, one stop.
+ * Enable receive and transmit.
+ */
+--
+2.20.1
+
--- /dev/null
+From 5cf0b90ec10df74bd647512cb524b59871025a26 Mon Sep 17 00:00:00 2001
+From: Kefeng Wang <wangkefeng.wang@huawei.com>
+Date: Fri, 31 May 2019 21:37:33 +0800
+Subject: tty/serial: digicolor: Fix digicolor-usart already registered warning
+
+[ Upstream commit c7ad9ba0611c53cfe194223db02e3bca015f0674 ]
+
+When modprobe/rmmod/modprobe module, if platform_driver_register() fails,
+the kernel complained,
+
+ proc_dir_entry 'driver/digicolor-usart' already registered
+ WARNING: CPU: 1 PID: 5636 at fs/proc/generic.c:360 proc_register+0x19d/0x270
+
+Fix this by adding uart_unregister_driver() when platform_driver_register() fails.
+
+Reported-by: Hulk Robot <hulkci@huawei.com>
+Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
+Acked-by: Baruch Siach <baruch@tkos.co.il>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/digicolor-usart.c | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/tty/serial/digicolor-usart.c b/drivers/tty/serial/digicolor-usart.c
+index 02ad6953b167..50ec5f1ac77f 100644
+--- a/drivers/tty/serial/digicolor-usart.c
++++ b/drivers/tty/serial/digicolor-usart.c
+@@ -545,7 +545,11 @@ static int __init digicolor_uart_init(void)
+ if (ret)
+ return ret;
+
+- return platform_driver_register(&digicolor_uart_platform);
++ ret = platform_driver_register(&digicolor_uart_platform);
++ if (ret)
++ uart_unregister_driver(&digicolor_uart);
++
++ return ret;
+ }
+ module_init(digicolor_uart_init);
+
+--
+2.20.1
+
--- /dev/null
+From 8e8989371a652413ce4388e549e1e05fde057cc6 Mon Sep 17 00:00:00 2001
+From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Date: Mon, 10 Jun 2019 19:23:08 +0200
+Subject: tty: serial: msm_serial: avoid system lockup condition
+
+[ Upstream commit ba3684f99f1b25d2a30b6956d02d339d7acb9799 ]
+
+The function msm_wait_for_xmitr can be taken with interrupts
+disabled. In order to avoid a potential system lockup - demonstrated
+under stress testing conditions on SoC QCS404/5 - make sure we wait
+for a bounded amount of time.
+
+Tested on SoC QCS404.
+
+Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/msm_serial.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/tty/serial/msm_serial.c b/drivers/tty/serial/msm_serial.c
+index 7dc8272c6b15..9027455c6be1 100644
+--- a/drivers/tty/serial/msm_serial.c
++++ b/drivers/tty/serial/msm_serial.c
+@@ -391,10 +391,14 @@ static void msm_request_rx_dma(struct msm_port *msm_port, resource_size_t base)
+
+ static inline void msm_wait_for_xmitr(struct uart_port *port)
+ {
++ unsigned int timeout = 500000;
++
+ while (!(msm_read(port, UART_SR) & UART_SR_TX_EMPTY)) {
+ if (msm_read(port, UART_ISR) & UART_ISR_TX_READY)
+ break;
+ udelay(1);
++ if (!timeout--)
++ break;
+ }
+ msm_write(port, UART_CR_CMD_RESET_TX_READY, UART_CR);
+ }
+--
+2.20.1
+
--- /dev/null
+From 55cb4c7f1c21b077b5d2b0338e9fa4cf556b7bf4 Mon Sep 17 00:00:00 2001
+From: Serge Semin <fancer.lancer@gmail.com>
+Date: Wed, 8 May 2019 13:44:41 +0300
+Subject: tty: serial_core: Set port active bit in uart_port_activate
+
+[ Upstream commit 13b18d35909707571af9539f7731389fbf0feb31 ]
+
+A bug was introduced by commit b3b576461864 ("tty: serial_core: convert
+uart_open to use tty_port_open"). It caused a constant warning printed
+into the system log regarding the tty and port counter mismatch:
+
+[ 21.644197] ttyS ttySx: tty_port_close_start: tty->count = 1 port count = 2
+
+in case if session hangup was detected so the warning is printed starting
+from the second open-close iteration.
+
+Particularly the problem was discovered in situation when there is a
+serial tty device without hardware back-end being setup. It is considered
+by the tty-serial subsystems as a hardware problem with session hang up.
+In this case uart_startup() will return a positive value with TTY_IO_ERROR
+flag set in corresponding tty_struct instance. The same value will get
+passed to be returned from the activate() callback and then being returned
+from tty_port_open(). But since in this case tty_port_block_til_ready()
+isn't called the TTY_PORT_ACTIVE flag isn't set (while the method had been
+called before tty_port_open conversion was introduced and the rest of the
+subsystem code expected the bit being set in this case), which prevents the
+uart_hangup() method to perform any cleanups including the tty port
+counter setting to zero. So the next attempt to open/close the tty device
+will discover the counters mismatch.
+
+In order to fix the problem we need to manually set the TTY_PORT_ACTIVE
+flag in case if uart_startup() returned a positive value. In this case
+the hang up procedure will perform a full set of cleanup actions including
+the port ref-counter resetting.
+
+Fixes: b3b576461864 "tty: serial_core: convert uart_open to use tty_port_open"
+Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/serial/serial_core.c | 7 ++++++-
+ 1 file changed, 6 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
+index 680fb3f9be2d..04c023f7f633 100644
+--- a/drivers/tty/serial/serial_core.c
++++ b/drivers/tty/serial/serial_core.c
+@@ -1725,6 +1725,7 @@ static int uart_port_activate(struct tty_port *port, struct tty_struct *tty)
+ {
+ struct uart_state *state = container_of(port, struct uart_state, port);
+ struct uart_port *uport;
++ int ret;
+
+ uport = uart_port_check(state);
+ if (!uport || uport->flags & UPF_DEAD)
+@@ -1735,7 +1736,11 @@ static int uart_port_activate(struct tty_port *port, struct tty_struct *tty)
+ /*
+ * Start up the serial port.
+ */
+- return uart_startup(tty, state, 0);
++ ret = uart_startup(tty, state, 0);
++ if (ret > 0)
++ tty_port_set_active(port, 1);
++
++ return ret;
+ }
+
+ static const char *uart_type(struct uart_port *port)
+--
+2.20.1
+
--- /dev/null
+From 1049d428b69611e430d5e46e3421e28faa94a0f0 Mon Sep 17 00:00:00 2001
+From: Johannes Berg <johannes.berg@intel.com>
+Date: Fri, 24 May 2019 21:54:14 +0200
+Subject: um: Silence lockdep complaint about mmap_sem
+
+[ Upstream commit 80bf6ceaf9310b3f61934c69b382d4912deee049 ]
+
+When we get into activate_mm(), lockdep complains that we're doing
+something strange:
+
+ WARNING: possible circular locking dependency detected
+ 5.1.0-10252-gb00152307319-dirty #121 Not tainted
+ ------------------------------------------------------
+ inside.sh/366 is trying to acquire lock:
+ (____ptrval____) (&(&p->alloc_lock)->rlock){+.+.}, at: flush_old_exec+0x703/0x8d7
+
+ but task is already holding lock:
+ (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7
+
+ which lock already depends on the new lock.
+
+ the existing dependency chain (in reverse order) is:
+
+ -> #1 (&mm->mmap_sem){++++}:
+ [...]
+ __lock_acquire+0x12ab/0x139f
+ lock_acquire+0x155/0x18e
+ down_write+0x3f/0x98
+ flush_old_exec+0x748/0x8d7
+ load_elf_binary+0x2ca/0xddb
+ [...]
+
+ -> #0 (&(&p->alloc_lock)->rlock){+.+.}:
+ [...]
+ __lock_acquire+0x12ab/0x139f
+ lock_acquire+0x155/0x18e
+ _raw_spin_lock+0x30/0x83
+ flush_old_exec+0x703/0x8d7
+ load_elf_binary+0x2ca/0xddb
+ [...]
+
+ other info that might help us debug this:
+
+ Possible unsafe locking scenario:
+
+ CPU0 CPU1
+ ---- ----
+ lock(&mm->mmap_sem);
+ lock(&(&p->alloc_lock)->rlock);
+ lock(&mm->mmap_sem);
+ lock(&(&p->alloc_lock)->rlock);
+
+ *** DEADLOCK ***
+
+ 2 locks held by inside.sh/366:
+ #0: (____ptrval____) (&sig->cred_guard_mutex){+.+.}, at: __do_execve_file+0x12d/0x869
+ #1: (____ptrval____) (&mm->mmap_sem){++++}, at: flush_old_exec+0x6c5/0x8d7
+
+ stack backtrace:
+ CPU: 0 PID: 366 Comm: inside.sh Not tainted 5.1.0-10252-gb00152307319-dirty #121
+ Stack:
+ [...]
+ Call Trace:
+ [<600420de>] show_stack+0x13b/0x155
+ [<6048906b>] dump_stack+0x2a/0x2c
+ [<6009ae64>] print_circular_bug+0x332/0x343
+ [<6009c5c6>] check_prev_add+0x669/0xdad
+ [<600a06b4>] __lock_acquire+0x12ab/0x139f
+ [<6009f3d0>] lock_acquire+0x155/0x18e
+ [<604a07e0>] _raw_spin_lock+0x30/0x83
+ [<60151e6a>] flush_old_exec+0x703/0x8d7
+ [<601a8eb8>] load_elf_binary+0x2ca/0xddb
+ [...]
+
+I think it's because in exec_mmap() we have
+
+ down_read(&old_mm->mmap_sem);
+...
+ task_lock(tsk);
+...
+ activate_mm(active_mm, mm);
+ (which does down_write(&mm->mmap_sem))
+
+I'm not really sure why lockdep throws in the whole knowledge
+about the task lock, but it seems that old_mm and mm shouldn't
+ever be the same (and it doesn't deadlock) so tell lockdep that
+they're different.
+
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/um/include/asm/mmu_context.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/arch/um/include/asm/mmu_context.h b/arch/um/include/asm/mmu_context.h
+index 1a60e1328e2f..6aca4c90aa1a 100644
+--- a/arch/um/include/asm/mmu_context.h
++++ b/arch/um/include/asm/mmu_context.h
+@@ -56,7 +56,7 @@ static inline void activate_mm(struct mm_struct *old, struct mm_struct *new)
+ * when the new ->mm is used for the first time.
+ */
+ __switch_mm(&new->context.id);
+- down_write(&new->mmap_sem);
++ down_write_nested(&new->mmap_sem, 1);
+ uml_setup_stubs(new);
+ up_write(&new->mmap_sem);
+ }
+--
+2.20.1
+
--- /dev/null
+From c4de36618a51b5a2cacba2e8d792d46489c9d601 Mon Sep 17 00:00:00 2001
+From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
+Date: Tue, 14 May 2019 14:38:38 -0700
+Subject: usb: core: hub: Disable hub-initiated U1/U2
+
+[ Upstream commit 561759292774707b71ee61aecc07724905bb7ef1 ]
+
+If the device rejects the control transfer to enable device-initiated
+U1/U2 entry, then the device will not initiate U1/U2 transition. To
+improve the performance, the downstream port should not initate
+transition to U1/U2 to avoid the delay from the device link command
+response (no packet can be transmitted while waiting for a response from
+the device). If the device has some quirks and does not implement U1/U2,
+it may reject all the link state change requests, and the downstream
+port may resend and flood the bus with more requests. This will affect
+the device performance even further. This patch disables the
+hub-initated U1/U2 if the device-initiated U1/U2 entry fails.
+
+Reference: USB 3.2 spec 7.2.4.2.3
+
+Signed-off-by: Thinh Nguyen <thinhn@synopsys.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/core/hub.c | 28 ++++++++++++++++------------
+ 1 file changed, 16 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
+index 9f132fac7b2c..63646dc3ca27 100644
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -3879,6 +3879,9 @@ static int usb_set_lpm_timeout(struct usb_device *udev,
+ * control transfers to set the hub timeout or enable device-initiated U1/U2
+ * will be successful.
+ *
++ * If the control transfer to enable device-initiated U1/U2 entry fails, then
++ * hub-initiated U1/U2 will be disabled.
++ *
+ * If we cannot set the parent hub U1/U2 timeout, we attempt to let the xHCI
+ * driver know about it. If that call fails, it should be harmless, and just
+ * take up more slightly more bus bandwidth for unnecessary U1/U2 exit latency.
+@@ -3933,23 +3936,24 @@ static void usb_enable_link_state(struct usb_hcd *hcd, struct usb_device *udev,
+ * host know that this link state won't be enabled.
+ */
+ hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state);
+- } else {
+- /* Only a configured device will accept the Set Feature
+- * U1/U2_ENABLE
+- */
+- if (udev->actconfig)
+- usb_set_device_initiated_lpm(udev, state, true);
++ return;
++ }
+
+- /* As soon as usb_set_lpm_timeout(timeout) returns 0, the
+- * hub-initiated LPM is enabled. Thus, LPM is enabled no
+- * matter the result of usb_set_device_initiated_lpm().
+- * The only difference is whether device is able to initiate
+- * LPM.
+- */
++ /* Only a configured device will accept the Set Feature
++ * U1/U2_ENABLE
++ */
++ if (udev->actconfig &&
++ usb_set_device_initiated_lpm(udev, state, true) == 0) {
+ if (state == USB3_LPM_U1)
+ udev->usb3_lpm_u1_enabled = 1;
+ else if (state == USB3_LPM_U2)
+ udev->usb3_lpm_u2_enabled = 1;
++ } else {
++ /* Don't request U1/U2 entry if the device
++ * cannot transition to U1/U2.
++ */
++ usb_set_lpm_timeout(udev, state, 0);
++ hcd->driver->disable_usb3_lpm_timeout(hcd, udev, state);
+ }
+ }
+
+--
+2.20.1
+
--- /dev/null
+From 15d4d70de60157166ecbdd81f8735f332cf8ecc1 Mon Sep 17 00:00:00 2001
+From: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
+Date: Mon, 3 Jun 2019 19:05:28 +0200
+Subject: usb: gadget: Zero ffs_io_data
+
+[ Upstream commit 508595515f4bcfe36246e4a565cf280937aeaade ]
+
+In some cases the "Allocate & copy" block in ffs_epfile_io() is not
+executed. Consequently, in such a case ffs_alloc_buffer() is never called
+and struct ffs_io_data is not initialized properly. This in turn leads to
+problems when ffs_free_buffer() is called at the end of ffs_epfile_io().
+
+This patch uses kzalloc() instead of kmalloc() in the aio case and memset()
+in non-aio case to properly initialize struct ffs_io_data.
+
+Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/usb/gadget/function/f_fs.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
+index 927ac0ee09b7..d1278d2d544b 100644
+--- a/drivers/usb/gadget/function/f_fs.c
++++ b/drivers/usb/gadget/function/f_fs.c
+@@ -1101,11 +1101,12 @@ static ssize_t ffs_epfile_write_iter(struct kiocb *kiocb, struct iov_iter *from)
+ ENTER();
+
+ if (!is_sync_kiocb(kiocb)) {
+- p = kmalloc(sizeof(io_data), GFP_KERNEL);
++ p = kzalloc(sizeof(io_data), GFP_KERNEL);
+ if (unlikely(!p))
+ return -ENOMEM;
+ p->aio = true;
+ } else {
++ memset(p, 0, sizeof(*p));
+ p->aio = false;
+ }
+
+@@ -1137,11 +1138,12 @@ static ssize_t ffs_epfile_read_iter(struct kiocb *kiocb, struct iov_iter *to)
+ ENTER();
+
+ if (!is_sync_kiocb(kiocb)) {
+- p = kmalloc(sizeof(io_data), GFP_KERNEL);
++ p = kzalloc(sizeof(io_data), GFP_KERNEL);
+ if (unlikely(!p))
+ return -ENOMEM;
+ p->aio = true;
+ } else {
++ memset(p, 0, sizeof(*p));
+ p->aio = false;
+ }
+
+--
+2.20.1
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
