--- /dev/null
+From 6282e916f774e37845c65d1eae9f8c649004f033 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Date: Mon, 5 Nov 2018 14:54:56 +0100
+Subject: ARM: 8809/1: proc-v7: fix Thumb annotation of cpu_v7_hvc_switch_mm
+
+From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+
+commit 6282e916f774e37845c65d1eae9f8c649004f033 upstream.
+
+Due to what appears to be a copy/paste error, the opening ENTRY()
+of cpu_v7_hvc_switch_mm() lacks a matching ENDPROC(), and instead,
+the one for cpu_v7_smc_switch_mm() is duplicated.
+
+Given that it is ENDPROC() that emits the Thumb annotation, the
+cpu_v7_hvc_switch_mm() routine will be called in ARM mode on a
+Thumb2 kernel, resulting in the following splat:
+
+ Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2
+ Modules linked in:
+ CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc1-00030-g4d28ad89189d-dirty #488
+ Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
+ PC is at cpu_v7_hvc_switch_mm+0x12/0x18
+ LR is at flush_old_exec+0x31b/0x570
+ pc : [<c0316efe>] lr : [<c04117c7>] psr: 00000013
+ sp : ee899e50 ip : 00000000 fp : 00000001
+ r10: eda28f34 r9 : eda31800 r8 : c12470e0
+ r7 : eda1fc00 r6 : eda53000 r5 : 00000000 r4 : ee88c000
+ r3 : c0316eec r2 : 00000001 r1 : eda53000 r0 : 6da6c000
+ Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
+
+Note the 'ISA ARM' in the last line.
+
+Fix this by using the correct name in ENDPROC().
+
+Cc: <stable@vger.kernel.org>
+Fixes: 10115105cb3a ("ARM: spectre-v2: add firmware based hardening")
+Reviewed-by: Dave Martin <Dave.Martin@arm.com>
+Acked-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
+Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/mm/proc-v7.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm/mm/proc-v7.S
++++ b/arch/arm/mm/proc-v7.S
+@@ -112,7 +112,7 @@ ENTRY(cpu_v7_hvc_switch_mm)
+ hvc #0
+ ldmfd sp!, {r0 - r3}
+ b cpu_v7_switch_mm
+-ENDPROC(cpu_v7_smc_switch_mm)
++ENDPROC(cpu_v7_hvc_switch_mm)
+ #endif
+ ENTRY(cpu_v7_iciallu_switch_mm)
+ mov r3, #0
--- /dev/null
+From 0f5cb0e6225cae2f029944cb8c74617aab6ddd49 Mon Sep 17 00:00:00 2001
+From: Ronald Wahl <rwahl@gmx.de>
+Date: Wed, 10 Oct 2018 15:54:54 +0200
+Subject: clk: at91: Fix division by zero in PLL recalc_rate()
+
+From: Ronald Wahl <rwahl@gmx.de>
+
+commit 0f5cb0e6225cae2f029944cb8c74617aab6ddd49 upstream.
+
+Commit a982e45dc150 ("clk: at91: PLL recalc_rate() now using cached MUL
+and DIV values") removed a check that prevents a division by zero. This
+now causes a stacktrace when booting the kernel on a at91 platform if
+the PLL DIV register contains zero. This commit reintroduces this check.
+
+Fixes: a982e45dc150 ("clk: at91: PLL recalc_rate() now using cached...")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Ronald Wahl <rwahl@gmx.de>
+Acked-by: Ludovic Desroches <ludovic.desroches@microchip.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/at91/clk-pll.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/clk/at91/clk-pll.c
++++ b/drivers/clk/at91/clk-pll.c
+@@ -133,6 +133,9 @@ static unsigned long clk_pll_recalc_rate
+ {
+ struct clk_pll *pll = to_clk_pll(hw);
+
++ if (!pll->div || !pll->mul)
++ return 0;
++
+ return (parent_rate / pll->div) * (pll->mul + 1);
+ }
+
--- /dev/null
+From 00c5a926af12a9f0236928dab3dc9faf621406a1 Mon Sep 17 00:00:00 2001
+From: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Date: Thu, 24 May 2018 17:23:41 +1200
+Subject: clk: mvebu: use correct bit for 98DX3236 NAND
+
+From: Chris Packham <chris.packham@alliedtelesis.co.nz>
+
+commit 00c5a926af12a9f0236928dab3dc9faf621406a1 upstream.
+
+The correct fieldbit value for the NAND PLL reload trigger is 27.
+
+Fixes: commit e120c17a70e5 ("clk: mvebu: support for 98DX3236 SoC")
+Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/mvebu/clk-corediv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/clk/mvebu/clk-corediv.c
++++ b/drivers/clk/mvebu/clk-corediv.c
+@@ -72,7 +72,7 @@ static const struct clk_corediv_desc mve
+ };
+
+ static const struct clk_corediv_desc mv98dx3236_corediv_desc[] = {
+- { .mask = 0x0f, .offset = 6, .fieldbit = 26 }, /* NAND clock */
++ { .mask = 0x0f, .offset = 6, .fieldbit = 27 }, /* NAND clock */
+ };
+
+ #define to_corediv_clk(p) container_of(p, struct clk_corediv, hw)
--- /dev/null
+From 665636b2940d0897c4130253467f5e8c42eea392 Mon Sep 17 00:00:00 2001
+From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Date: Tue, 16 Oct 2018 15:41:44 +0200
+Subject: clk: rockchip: Fix static checker warning in rockchip_ddrclk_get_parent call
+
+From: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+
+commit 665636b2940d0897c4130253467f5e8c42eea392 upstream.
+
+Fixes the signedness bug returning '(-22)' on the return type by removing the
+sanity checker in rockchip_ddrclk_get_parent(). The function should return
+and unsigned value only and it's safe to remove the sanity checker as the
+core functions that call get_parent like clk_core_get_parent_by_index already
+ensures the validity of the clk index returned (index >= core->num_parents).
+
+Fixes: a4f182bf81f18 ("clk: rockchip: add new clock-type for the ddrclk")
+Cc: stable@vger.kernel.org
+Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
+Reviewed-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/rockchip/clk-ddr.c | 4 ----
+ 1 file changed, 4 deletions(-)
+
+--- a/drivers/clk/rockchip/clk-ddr.c
++++ b/drivers/clk/rockchip/clk-ddr.c
+@@ -80,16 +80,12 @@ static long rockchip_ddrclk_sip_round_ra
+ static u8 rockchip_ddrclk_get_parent(struct clk_hw *hw)
+ {
+ struct rockchip_ddrclk *ddrclk = to_rockchip_ddrclk_hw(hw);
+- int num_parents = clk_hw_get_num_parents(hw);
+ u32 val;
+
+ val = clk_readl(ddrclk->reg_base +
+ ddrclk->mux_offset) >> ddrclk->mux_shift;
+ val &= GENMASK(ddrclk->mux_width - 1, 0);
+
+- if (val >= num_parents)
+- return -EINVAL;
+-
+ return val;
+ }
+
--- /dev/null
+From 8985167ecf57f97061599a155bb9652c84ea4913 Mon Sep 17 00:00:00 2001
+From: Krzysztof Kozlowski <krzk@kernel.org>
+Date: Wed, 29 Aug 2018 21:20:10 +0200
+Subject: clk: s2mps11: Fix matching when built as module and DT node contains compatible
+
+From: Krzysztof Kozlowski <krzk@kernel.org>
+
+commit 8985167ecf57f97061599a155bb9652c84ea4913 upstream.
+
+When driver is built as module and DT node contains clocks compatible
+(e.g. "samsung,s2mps11-clk"), the module will not be autoloaded because
+module aliases won't match.
+
+The modalias from uevent: of:NclocksT<NULL>Csamsung,s2mps11-clk
+The modalias from driver: platform:s2mps11-clk
+
+The devices are instantiated by parent's MFD. However both Device Tree
+bindings and parent define the compatible for clocks devices. In case
+of module matching this DT compatible will be used.
+
+The issue will not happen if this is a built-in (no need for module
+matching) or when clocks DT node does not contain compatible (not
+correct from bindings perspective but working for driver).
+
+Note when backporting to stable kernels: adjust the list of device ID
+entries.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 53c31b3437a6 ("mfd: sec-core: Add of_compatible strings for clock MFD cells")
+Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
+Acked-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/clk-s2mps11.c | 30 ++++++++++++++++++++++++++++++
+ 1 file changed, 30 insertions(+)
+
+--- a/drivers/clk/clk-s2mps11.c
++++ b/drivers/clk/clk-s2mps11.c
+@@ -245,6 +245,36 @@ static const struct platform_device_id s
+ };
+ MODULE_DEVICE_TABLE(platform, s2mps11_clk_id);
+
++#ifdef CONFIG_OF
++/*
++ * Device is instantiated through parent MFD device and device matching is done
++ * through platform_device_id.
++ *
++ * However if device's DT node contains proper clock compatible and driver is
++ * built as a module, then the *module* matching will be done trough DT aliases.
++ * This requires of_device_id table. In the same time this will not change the
++ * actual *device* matching so do not add .of_match_table.
++ */
++static const struct of_device_id s2mps11_dt_match[] = {
++ {
++ .compatible = "samsung,s2mps11-clk",
++ .data = (void *)S2MPS11X,
++ }, {
++ .compatible = "samsung,s2mps13-clk",
++ .data = (void *)S2MPS13X,
++ }, {
++ .compatible = "samsung,s2mps14-clk",
++ .data = (void *)S2MPS14X,
++ }, {
++ .compatible = "samsung,s5m8767-clk",
++ .data = (void *)S5M8767X,
++ }, {
++ /* Sentinel */
++ },
++};
++MODULE_DEVICE_TABLE(of, s2mps11_dt_match);
++#endif
++
+ static struct platform_driver s2mps11_clk_driver = {
+ .driver = {
+ .name = "s2mps11-clk",
--- /dev/null
+From 94e6992bb560be8bffb47f287194adf070b57695 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Wed, 26 Sep 2018 18:03:16 +0200
+Subject: libceph: bump CEPH_MSG_MAX_DATA_LEN
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit 94e6992bb560be8bffb47f287194adf070b57695 upstream.
+
+If the read is large enough, we end up spinning in the messenger:
+
+ libceph: osd0 192.168.122.1:6801 io error
+ libceph: osd0 192.168.122.1:6801 io error
+ libceph: osd0 192.168.122.1:6801 io error
+
+This is a receive side limit, so only reads were affected.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ include/linux/ceph/libceph.h | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/include/linux/ceph/libceph.h
++++ b/include/linux/ceph/libceph.h
+@@ -81,7 +81,13 @@ struct ceph_options {
+
+ #define CEPH_MSG_MAX_FRONT_LEN (16*1024*1024)
+ #define CEPH_MSG_MAX_MIDDLE_LEN (16*1024*1024)
+-#define CEPH_MSG_MAX_DATA_LEN (16*1024*1024)
++
++/*
++ * Handle the largest possible rbd object in one message.
++ * There is no limit on the size of cephfs objects, but it has to obey
++ * rsize and wsize mount options anyway.
++ */
++#define CEPH_MSG_MAX_DATA_LEN (32*1024*1024)
+
+ #define CEPH_AUTH_NAME_DEFAULT "guest"
+
--- /dev/null
+From 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 8 Oct 2018 12:57:34 +0200
+Subject: mach64: fix display corruption on big endian machines
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 upstream.
+
+The code for manual bit triple is not endian-clean. It builds the variable
+"hostdword" using byte accesses, therefore we must read the variable with
+"le32_to_cpu".
+
+The patch also enables (hardware or software) bit triple only if the image
+is monochrome (image->depth). If we want to blit full-color image, we
+shouldn't use the triple code.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
+Cc: stable@vger.kernel.org
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/aty/mach64_accel.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/video/fbdev/aty/mach64_accel.c
++++ b/drivers/video/fbdev/aty/mach64_accel.c
+@@ -345,7 +345,7 @@ void atyfb_imageblit(struct fb_info *inf
+ * since Rage 3D IIc we have DP_HOST_TRIPLE_EN bit
+ * this hwaccelerated triple has an issue with not aligned data
+ */
+- if (M64_HAS(HW_TRIPLE) && image->width % 8 == 0)
++ if (image->depth == 1 && M64_HAS(HW_TRIPLE) && image->width % 8 == 0)
+ pix_width |= DP_HOST_TRIPLE_EN;
+ }
+
+@@ -382,7 +382,7 @@ void atyfb_imageblit(struct fb_info *inf
+ src_bytes = (((image->width * image->depth) + 7) / 8) * image->height;
+
+ /* manual triple each pixel */
+- if (info->var.bits_per_pixel == 24 && !(pix_width & DP_HOST_TRIPLE_EN)) {
++ if (image->depth == 1 && info->var.bits_per_pixel == 24 && !(pix_width & DP_HOST_TRIPLE_EN)) {
+ int inbit, outbit, mult24, byte_id_in_dword, width;
+ u8 *pbitmapin = (u8*)image->data, *pbitmapout;
+ u32 hostdword;
+@@ -415,7 +415,7 @@ void atyfb_imageblit(struct fb_info *inf
+ }
+ }
+ wait_for_fifo(1, par);
+- aty_st_le32(HOST_DATA0, hostdword, par);
++ aty_st_le32(HOST_DATA0, le32_to_cpu(hostdword), par);
+ }
+ } else {
+ u32 *pbitmap, dwords = (src_bytes + 3) / 4;
--- /dev/null
+From c09bcc91bb94ed91f1391bffcbe294963d605732 Mon Sep 17 00:00:00 2001
+From: Mikulas Patocka <mpatocka@redhat.com>
+Date: Mon, 8 Oct 2018 12:57:35 +0200
+Subject: mach64: fix image corruption due to reading accelerator registers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mikulas Patocka <mpatocka@redhat.com>
+
+commit c09bcc91bb94ed91f1391bffcbe294963d605732 upstream.
+
+Reading the registers without waiting for engine idle returns
+unpredictable values. These unpredictable values result in display
+corruption - if atyfb_imageblit reads the content of DP_PIX_WIDTH with the
+bit DP_HOST_TRIPLE_EN set (from previous invocation), the driver would
+never ever clear the bit, resulting in display corruption.
+
+We don't want to wait for idle because it would degrade performance, so
+this patch modifies the driver so that it never reads accelerator
+registers.
+
+HOST_CNTL doesn't have to be read, we can just write it with
+HOST_BYTE_ALIGN because no other part of the driver cares if
+HOST_BYTE_ALIGN is set.
+
+DP_PIX_WIDTH is written in the functions atyfb_copyarea and atyfb_fillrect
+with the default value and in atyfb_imageblit with the value set according
+to the source image data.
+
+Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
+Reviewed-by: Ville Syrjälä <syrjala@sci.fi>
+Cc: stable@vger.kernel.org
+Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/video/fbdev/aty/mach64_accel.c | 22 +++++++++-------------
+ 1 file changed, 9 insertions(+), 13 deletions(-)
+
+--- a/drivers/video/fbdev/aty/mach64_accel.c
++++ b/drivers/video/fbdev/aty/mach64_accel.c
+@@ -127,7 +127,7 @@ void aty_init_engine(struct atyfb_par *p
+
+ /* set host attributes */
+ wait_for_fifo(13, par);
+- aty_st_le32(HOST_CNTL, 0, par);
++ aty_st_le32(HOST_CNTL, HOST_BYTE_ALIGN, par);
+
+ /* set pattern attributes */
+ aty_st_le32(PAT_REG0, 0, par);
+@@ -233,7 +233,8 @@ void atyfb_copyarea(struct fb_info *info
+ rotation = rotation24bpp(dx, direction);
+ }
+
+- wait_for_fifo(4, par);
++ wait_for_fifo(5, par);
++ aty_st_le32(DP_PIX_WIDTH, par->crtc.dp_pix_width, par);
+ aty_st_le32(DP_SRC, FRGD_SRC_BLIT, par);
+ aty_st_le32(SRC_Y_X, (sx << 16) | sy, par);
+ aty_st_le32(SRC_HEIGHT1_WIDTH1, (width << 16) | area->height, par);
+@@ -269,7 +270,8 @@ void atyfb_fillrect(struct fb_info *info
+ rotation = rotation24bpp(dx, DST_X_LEFT_TO_RIGHT);
+ }
+
+- wait_for_fifo(3, par);
++ wait_for_fifo(4, par);
++ aty_st_le32(DP_PIX_WIDTH, par->crtc.dp_pix_width, par);
+ aty_st_le32(DP_FRGD_CLR, color, par);
+ aty_st_le32(DP_SRC,
+ BKGD_SRC_BKGD_CLR | FRGD_SRC_FRGD_CLR | MONO_SRC_ONE,
+@@ -284,7 +286,7 @@ void atyfb_imageblit(struct fb_info *inf
+ {
+ struct atyfb_par *par = (struct atyfb_par *) info->par;
+ u32 src_bytes, dx = image->dx, dy = image->dy, width = image->width;
+- u32 pix_width_save, pix_width, host_cntl, rotation = 0, src, mix;
++ u32 pix_width, rotation = 0, src, mix;
+
+ if (par->asleep)
+ return;
+@@ -296,8 +298,7 @@ void atyfb_imageblit(struct fb_info *inf
+ return;
+ }
+
+- pix_width = pix_width_save = aty_ld_le32(DP_PIX_WIDTH, par);
+- host_cntl = aty_ld_le32(HOST_CNTL, par) | HOST_BYTE_ALIGN;
++ pix_width = par->crtc.dp_pix_width;
+
+ switch (image->depth) {
+ case 1:
+@@ -370,12 +371,11 @@ void atyfb_imageblit(struct fb_info *inf
+ mix = FRGD_MIX_D_XOR_S | BKGD_MIX_D;
+ }
+
+- wait_for_fifo(6, par);
+- aty_st_le32(DP_WRITE_MASK, 0xFFFFFFFF, par);
++ wait_for_fifo(5, par);
+ aty_st_le32(DP_PIX_WIDTH, pix_width, par);
+ aty_st_le32(DP_MIX, mix, par);
+ aty_st_le32(DP_SRC, src, par);
+- aty_st_le32(HOST_CNTL, host_cntl, par);
++ aty_st_le32(HOST_CNTL, HOST_BYTE_ALIGN, par);
+ aty_st_le32(DST_CNTL, DST_Y_TOP_TO_BOTTOM | DST_X_LEFT_TO_RIGHT | rotation, par);
+
+ draw_rect(dx, dy, width, image->height, par);
+@@ -424,8 +424,4 @@ void atyfb_imageblit(struct fb_info *inf
+ aty_st_le32(HOST_DATA0, get_unaligned_le32(pbitmap), par);
+ }
+ }
+-
+- /* restore pix_width */
+- wait_for_fifo(1, par);
+- aty_st_le32(DP_PIX_WIDTH, pix_width_save, par);
+ }
--- /dev/null
+From 786fa584eda86d6598db3b87c61dc81f68808d11 Mon Sep 17 00:00:00 2001
+From: Lubomir Rintel <lkundrak@v3.sk>
+Date: Thu, 4 Oct 2018 17:29:03 -0400
+Subject: media: ov7670: make "xclk" clock optional
+
+From: Lubomir Rintel <lkundrak@v3.sk>
+
+commit 786fa584eda86d6598db3b87c61dc81f68808d11 upstream.
+
+When the "xclk" clock was added, it was made mandatory. This broke the
+driver on an OLPC plaform which doesn't know such clock. Make it
+optional.
+
+Tested on a OLPC XO-1 laptop.
+
+Fixes: 0a024d634cee ("[media] ov7670: get xclk")
+
+Cc: stable@vger.kernel.org # 4.11+
+Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
+Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
+Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/media/i2c/ov7670.c | 30 ++++++++++++++++++------------
+ 1 file changed, 18 insertions(+), 12 deletions(-)
+
+--- a/drivers/media/i2c/ov7670.c
++++ b/drivers/media/i2c/ov7670.c
+@@ -1612,23 +1612,29 @@ static int ov7670_probe(struct i2c_clien
+ info->pclk_hb_disable = true;
+ }
+
+- info->clk = devm_clk_get(&client->dev, "xclk");
+- if (IS_ERR(info->clk))
+- return PTR_ERR(info->clk);
+- ret = clk_prepare_enable(info->clk);
+- if (ret)
+- return ret;
++ info->clk = devm_clk_get(&client->dev, "xclk"); /* optional */
++ if (IS_ERR(info->clk)) {
++ ret = PTR_ERR(info->clk);
++ if (ret == -ENOENT)
++ info->clk = NULL;
++ else
++ return ret;
++ }
++ if (info->clk) {
++ ret = clk_prepare_enable(info->clk);
++ if (ret)
++ return ret;
++ info->clock_speed = clk_get_rate(info->clk) / 1000000;
++ if (info->clock_speed < 10 || info->clock_speed > 48) {
++ ret = -EINVAL;
++ goto clk_disable;
++ }
++ }
+
+ ret = ov7670_init_gpio(client, info);
+ if (ret)
+ goto clk_disable;
+
+- info->clock_speed = clk_get_rate(info->clk) / 1000000;
+- if (info->clock_speed < 10 || info->clock_speed > 48) {
+- ret = -EINVAL;
+- goto clk_disable;
+- }
+-
+ /* Make sure it's an ov7670 */
+ ret = ov7670_detect(sd);
+ if (ret) {
--- /dev/null
+From ac5b2c18911ffe95c08d69273917f90212cf5659 Mon Sep 17 00:00:00 2001
+From: Andrea Arcangeli <aarcange@redhat.com>
+Date: Fri, 2 Nov 2018 15:47:59 -0700
+Subject: mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
+
+From: Andrea Arcangeli <aarcange@redhat.com>
+
+commit ac5b2c18911ffe95c08d69273917f90212cf5659 upstream.
+
+THP allocation might be really disruptive when allocated on NUMA system
+with the local node full or hard to reclaim. Stefan has posted an
+allocation stall report on 4.12 based SLES kernel which suggests the
+same issue:
+
+ kvm: page allocation stalls for 194572ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null)
+ kvm cpuset=/ mems_allowed=0-1
+ CPU: 10 PID: 84752 Comm: kvm Tainted: G W 4.12.0+98-ph <a href="/view.php?id=1" title="[geschlossen] Integration Ramdisk" class="resolved">0000001</a> SLE15 (unreleased)
+ Hardware name: Supermicro SYS-1029P-WTRT/X11DDW-NT, BIOS 2.0 12/05/2017
+ Call Trace:
+ dump_stack+0x5c/0x84
+ warn_alloc+0xe0/0x180
+ __alloc_pages_slowpath+0x820/0xc90
+ __alloc_pages_nodemask+0x1cc/0x210
+ alloc_pages_vma+0x1e5/0x280
+ do_huge_pmd_wp_page+0x83f/0xf00
+ __handle_mm_fault+0x93d/0x1060
+ handle_mm_fault+0xc6/0x1b0
+ __do_page_fault+0x230/0x430
+ do_page_fault+0x2a/0x70
+ page_fault+0x7b/0x80
+ [...]
+ Mem-Info:
+ active_anon:126315487 inactive_anon:1612476 isolated_anon:5
+ active_file:60183 inactive_file:245285 isolated_file:0
+ unevictable:15657 dirty:286 writeback:1 unstable:0
+ slab_reclaimable:75543 slab_unreclaimable:2509111
+ mapped:81814 shmem:31764 pagetables:370616 bounce:0
+ free:32294031 free_pcp:6233 free_cma:0
+ Node 0 active_anon:254680388kB inactive_anon:1112760kB active_file:240648kB inactive_file:981168kB unevictable:13368kB isolated(anon):0kB isolated(file):0kB mapped:280240kB dirty:1144kB writeback:0kB shmem:95832kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 81225728kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
+ Node 1 active_anon:250583072kB inactive_anon:5337144kB active_file:84kB inactive_file:0kB unevictable:49260kB isolated(anon):20kB isolated(file):0kB mapped:47016kB dirty:0kB writeback:4kB shmem:31224kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 31897600kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
+
+The defrag mode is "madvise" and from the above report it is clear that
+the THP has been allocated for MADV_HUGEPAGA vma.
+
+Andrea has identified that the main source of the problem is
+__GFP_THISNODE usage:
+
+: The problem is that direct compaction combined with the NUMA
+: __GFP_THISNODE logic in mempolicy.c is telling reclaim to swap very
+: hard the local node, instead of failing the allocation if there's no
+: THP available in the local node.
+:
+: Such logic was ok until __GFP_THISNODE was added to the THP allocation
+: path even with MPOL_DEFAULT.
+:
+: The idea behind the __GFP_THISNODE addition, is that it is better to
+: provide local memory in PAGE_SIZE units than to use remote NUMA THP
+: backed memory. That largely depends on the remote latency though, on
+: threadrippers for example the overhead is relatively low in my
+: experience.
+:
+: The combination of __GFP_THISNODE and __GFP_DIRECT_RECLAIM results in
+: extremely slow qemu startup with vfio, if the VM is larger than the
+: size of one host NUMA node. This is because it will try very hard to
+: unsuccessfully swapout get_user_pages pinned pages as result of the
+: __GFP_THISNODE being set, instead of falling back to PAGE_SIZE
+: allocations and instead of trying to allocate THP on other nodes (it
+: would be even worse without vfio type1 GUP pins of course, except it'd
+: be swapping heavily instead).
+
+Fix this by removing __GFP_THISNODE for THP requests which are
+requesting the direct reclaim. This effectivelly reverts 5265047ac301
+on the grounds that the zone/node reclaim was known to be disruptive due
+to premature reclaim when there was memory free. While it made sense at
+the time for HPC workloads without NUMA awareness on rare machines, it
+was ultimately harmful in the majority of cases. The existing behaviour
+is similar, if not as widespare as it applies to a corner case but
+crucially, it cannot be tuned around like zone_reclaim_mode can. The
+default behaviour should always be to cause the least harm for the
+common case.
+
+If there are specialised use cases out there that want zone_reclaim_mode
+in specific cases, then it can be built on top. Longterm we should
+consider a memory policy which allows for the node reclaim like behavior
+for the specific memory ranges which would allow a
+
+[1] http://lkml.kernel.org/r/20180820032204.9591-1-aarcange@redhat.com
+
+Mel said:
+
+: Both patches look correct to me but I'm responding to this one because
+: it's the fix. The change makes sense and moves further away from the
+: severe stalling behaviour we used to see with both THP and zone reclaim
+: mode.
+:
+: I put together a basic experiment with usemem configured to reference a
+: buffer multiple times that is 80% the size of main memory on a 2-socket
+: box with symmetric node sizes and defrag set to "always". The defrag
+: setting is not the default but it would be functionally similar to
+: accessing a buffer with madvise(MADV_HUGEPAGE). Usemem is configured to
+: reference the buffer multiple times and while it's not an interesting
+: workload, it would be expected to complete reasonably quickly as it fits
+: within memory. The results were;
+:
+: usemem
+: vanilla noreclaim-v1
+: Amean Elapsd-1 42.78 ( 0.00%) 26.87 ( 37.18%)
+: Amean Elapsd-3 27.55 ( 0.00%) 7.44 ( 73.00%)
+: Amean Elapsd-4 5.72 ( 0.00%) 5.69 ( 0.45%)
+:
+: This shows the elapsed time in seconds for 1 thread, 3 threads and 4
+: threads referencing buffers 80% the size of memory. With the patches
+: applied, it's 37.18% faster for the single thread and 73% faster with two
+: threads. Note that 4 threads showing little difference does not indicate
+: the problem is related to thread counts. It's simply the case that 4
+: threads gets spread so their workload mostly fits in one node.
+:
+: The overall view from /proc/vmstats is more startling
+:
+: 4.19.0-rc1 4.19.0-rc1
+: vanillanoreclaim-v1r1
+: Minor Faults 35593425 708164
+: Major Faults 484088 36
+: Swap Ins 3772837 0
+: Swap Outs 3932295 0
+:
+: Massive amounts of swap in/out without the patch
+:
+: Direct pages scanned 6013214 0
+: Kswapd pages scanned 0 0
+: Kswapd pages reclaimed 0 0
+: Direct pages reclaimed 4033009 0
+:
+: Lots of reclaim activity without the patch
+:
+: Kswapd efficiency 100% 100%
+: Kswapd velocity 0.000 0.000
+: Direct efficiency 67% 100%
+: Direct velocity 11191.956 0.000
+:
+: Mostly from direct reclaim context as you'd expect without the patch.
+:
+: Page writes by reclaim 3932314.000 0.000
+: Page writes file 19 0
+: Page writes anon 3932295 0
+: Page reclaim immediate 42336 0
+:
+: Writes from reclaim context is never good but the patch eliminates it.
+:
+: We should never have default behaviour to thrash the system for such a
+: basic workload. If zone reclaim mode behaviour is ever desired but on a
+: single task instead of a global basis then the sensible option is to build
+: a mempolicy that enforces that behaviour.
+
+This was a severe regression compared to previous kernels that made
+important workloads unusable and it starts when __GFP_THISNODE was
+added to THP allocations under MADV_HUGEPAGE. It is not a significant
+risk to go to the previous behavior before __GFP_THISNODE was added, it
+worked like that for years.
+
+This was simply an optimization to some lucky workloads that can fit in
+a single node, but it ended up breaking the VM for others that can't
+possibly fit in a single node, so going back is safe.
+
+[mhocko@suse.com: rewrote the changelog based on the one from Andrea]
+Link: http://lkml.kernel.org/r/20180925120326.24392-2-mhocko@kernel.org
+Fixes: 5265047ac301 ("mm, thp: really limit transparent hugepage allocation to local node")
+Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
+Signed-off-by: Michal Hocko <mhocko@suse.com>
+Reported-by: Stefan Priebe <s.priebe@profihost.ag>
+Debugged-by: Andrea Arcangeli <aarcange@redhat.com>
+Reported-by: Alex Williamson <alex.williamson@redhat.com>
+Reviewed-by: Mel Gorman <mgorman@techsingularity.net>
+Tested-by: Mel Gorman <mgorman@techsingularity.net>
+Cc: Zi Yan <zi.yan@cs.rutgers.edu>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: David Rientjes <rientjes@google.com>
+Cc: "Kirill A. Shutemov" <kirill@shutemov.name>
+Cc: <stable@vger.kernel.org> [4.1+]
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ mm/mempolicy.c | 32 ++++++++++++++++++++++++++++++--
+ 1 file changed, 30 insertions(+), 2 deletions(-)
+
+--- a/mm/mempolicy.c
++++ b/mm/mempolicy.c
+@@ -2012,8 +2012,36 @@ alloc_pages_vma(gfp_t gfp, int order, st
+ nmask = policy_nodemask(gfp, pol);
+ if (!nmask || node_isset(hpage_node, *nmask)) {
+ mpol_cond_put(pol);
+- page = __alloc_pages_node(hpage_node,
+- gfp | __GFP_THISNODE, order);
++ /*
++ * We cannot invoke reclaim if __GFP_THISNODE
++ * is set. Invoking reclaim with
++ * __GFP_THISNODE set, would cause THP
++ * allocations to trigger heavy swapping
++ * despite there may be tons of free memory
++ * (including potentially plenty of THP
++ * already available in the buddy) on all the
++ * other NUMA nodes.
++ *
++ * At most we could invoke compaction when
++ * __GFP_THISNODE is set (but we would need to
++ * refrain from invoking reclaim even if
++ * compaction returned COMPACT_SKIPPED because
++ * there wasn't not enough memory to succeed
++ * compaction). For now just avoid
++ * __GFP_THISNODE instead of limiting the
++ * allocation path to a strict and single
++ * compaction invocation.
++ *
++ * Supposedly if direct reclaim was enabled by
++ * the caller, the app prefers THP regardless
++ * of the node it comes from so this would be
++ * more desiderable behavior than only
++ * providing THP originated from the local
++ * node in such case.
++ */
++ if (!(gfp & __GFP_DIRECT_RECLAIM))
++ gfp |= __GFP_THISNODE;
++ page = __alloc_pages_node(hpage_node, gfp, order);
+ goto out;
+ }
+ }
--- /dev/null
+From be2e1c9dcf76886a83fb1c433a316e26d4ca2550 Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Thu, 11 Oct 2018 13:06:16 +0200
+Subject: mtd: docg3: don't set conflicting BCH_CONST_PARAMS option
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+commit be2e1c9dcf76886a83fb1c433a316e26d4ca2550 upstream.
+
+I noticed during the creation of another bugfix that the BCH_CONST_PARAMS
+option that is set by DOCG3 breaks setting variable parameters for any
+other users of the BCH library code.
+
+The only other user we have today is the MTD_NAND software BCH
+implementation (most flash controllers use hardware BCH these days
+and are not affected). I considered removing BCH_CONST_PARAMS entirely
+because of the inherent conflict, but according to the description in
+lib/bch.c there is a significant performance benefit in keeping it.
+
+To avoid the immediate problem of the conflict between MTD_NAND_BCH
+and DOCG3, this only sets the constant parameters if MTD_NAND_BCH
+is disabled, which should fix the problem for all cases that
+are affected. This should also work for all stable kernels.
+
+Note that there is only one machine that actually seems to use the
+DOCG3 driver (arch/arm/mach-pxa/mioa701.c), so most users should have
+the driver disabled, but it almost certainly shows up if we wanted
+to test random kernels on machines that use software BCH in MTD.
+
+Fixes: d13d19ece39f ("mtd: docg3: add ECC correction code")
+Cc: stable@vger.kernel.org
+Cc: Robert Jarzmik <robert.jarzmik@free.fr>
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Boris Brezillon <boris.brezillon@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/devices/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mtd/devices/Kconfig
++++ b/drivers/mtd/devices/Kconfig
+@@ -206,7 +206,7 @@ comment "Disk-On-Chip Device Drivers"
+ config MTD_DOCG3
+ tristate "M-Systems Disk-On-Chip G3"
+ select BCH
+- select BCH_CONST_PARAMS
++ select BCH_CONST_PARAMS if !MTD_NAND_BCH
+ select BITREVERSE
+ ---help---
+ This provides an MTD device driver for the M-Systems DiskOnChip
--- /dev/null
+From f393808dc64149ccd0e5a8427505ba2974a59854 Mon Sep 17 00:00:00 2001
+From: Vasily Khoruzhick <vasilykh@arista.com>
+Date: Thu, 25 Oct 2018 12:15:43 -0700
+Subject: netfilter: conntrack: fix calculation of next bucket number in early_drop
+
+From: Vasily Khoruzhick <vasilykh@arista.com>
+
+commit f393808dc64149ccd0e5a8427505ba2974a59854 upstream.
+
+If there's no entry to drop in bucket that corresponds to the hash,
+early_drop() should look for it in other buckets. But since it increments
+hash instead of bucket number, it actually looks in the same bucket 8
+times: hsize is 16k by default (14 bits) and hash is 32-bit value, so
+reciprocal_scale(hash, hsize) returns the same value for hash..hash+7 in
+most cases.
+
+Fix it by increasing bucket number instead of hash and rename _hash
+to bucket to avoid future confusion.
+
+Fixes: 3e86638e9a0b ("netfilter: conntrack: consider ct netns in early_drop logic")
+Cc: <stable@vger.kernel.org> # v4.7+
+Signed-off-by: Vasily Khoruzhick <vasilykh@arista.com>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ net/netfilter/nf_conntrack_core.c | 13 ++++++++-----
+ 1 file changed, 8 insertions(+), 5 deletions(-)
+
+--- a/net/netfilter/nf_conntrack_core.c
++++ b/net/netfilter/nf_conntrack_core.c
+@@ -932,19 +932,22 @@ static unsigned int early_drop_list(stru
+ return drops;
+ }
+
+-static noinline int early_drop(struct net *net, unsigned int _hash)
++static noinline int early_drop(struct net *net, unsigned int hash)
+ {
+- unsigned int i;
++ unsigned int i, bucket;
+
+ for (i = 0; i < NF_CT_EVICTION_RANGE; i++) {
+ struct hlist_nulls_head *ct_hash;
+- unsigned int hash, hsize, drops;
++ unsigned int hsize, drops;
+
+ rcu_read_lock();
+ nf_conntrack_get_ht(&ct_hash, &hsize);
+- hash = reciprocal_scale(_hash++, hsize);
++ if (!i)
++ bucket = reciprocal_scale(hash, hsize);
++ else
++ bucket = (bucket + 1) % hsize;
+
+- drops = early_drop_list(net, &ct_hash[hash]);
++ drops = early_drop_list(net, &ct_hash[bucket]);
+ rcu_read_unlock();
+
+ if (drops) {
--- /dev/null
+From 29aa30167a0a2e6045a0d6d2e89d8168132333d5 Mon Sep 17 00:00:00 2001
+From: Changwei Ge <ge.changwei@h3c.com>
+Date: Fri, 2 Nov 2018 15:48:15 -0700
+Subject: ocfs2: fix a misuse a of brelse after failing ocfs2_check_dir_entry
+
+From: Changwei Ge <ge.changwei@h3c.com>
+
+commit 29aa30167a0a2e6045a0d6d2e89d8168132333d5 upstream.
+
+Somehow, file system metadata was corrupted, which causes
+ocfs2_check_dir_entry() to fail in function ocfs2_dir_foreach_blk_el().
+
+According to the original design intention, if above happens we should
+skip the problematic block and continue to retrieve dir entry. But
+there is obviouse misuse of brelse around related code.
+
+After failure of ocfs2_check_dir_entry(), current code just moves to
+next position and uses the problematic buffer head again and again
+during which the problematic buffer head is released for multiple times.
+I suppose, this a serious issue which is long-lived in ocfs2. This may
+cause other file systems which is also used in a the same host insane.
+
+So we should also consider about bakcporting this patch into linux
+-stable.
+
+Link: http://lkml.kernel.org/r/HK2PR06MB045211675B43EED794E597B6D56E0@HK2PR06MB0452.apcprd06.prod.outlook.com
+Signed-off-by: Changwei Ge <ge.changwei@h3c.com>
+Suggested-by: Changkuo Shi <shi.changkuo@h3c.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: Junxiao Bi <junxiao.bi@oracle.com>
+Cc: Joseph Qi <jiangqi903@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/dir.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/fs/ocfs2/dir.c
++++ b/fs/ocfs2/dir.c
+@@ -1896,8 +1896,7 @@ static int ocfs2_dir_foreach_blk_el(stru
+ /* On error, skip the f_pos to the
+ next block. */
+ ctx->pos = (ctx->pos | (sb->s_blocksize - 1)) + 1;
+- brelse(bh);
+- continue;
++ break;
+ }
+ if (le64_to_cpu(de->inode)) {
+ unsigned char d_type = DT_UNKNOWN;
--- /dev/null
+From 5040f8df56fb90c7919f1c9b0b6e54c843437456 Mon Sep 17 00:00:00 2001
+From: Wengang Wang <wen.gang.wang@oracle.com>
+Date: Fri, 16 Nov 2018 15:08:25 -0800
+Subject: ocfs2: free up write context when direct IO failed
+
+From: Wengang Wang <wen.gang.wang@oracle.com>
+
+commit 5040f8df56fb90c7919f1c9b0b6e54c843437456 upstream.
+
+The write context should also be freed even when direct IO failed.
+Otherwise a memory leak is introduced and entries remain in
+oi->ip_unwritten_list causing the following BUG later in unlink path:
+
+ ERROR: bug expression: !list_empty(&oi->ip_unwritten_list)
+ ERROR: Clear inode of 215043, inode has unwritten extents
+ ...
+ Call Trace:
+ ? __set_current_blocked+0x42/0x68
+ ocfs2_evict_inode+0x91/0x6a0 [ocfs2]
+ ? bit_waitqueue+0x40/0x33
+ evict+0xdb/0x1af
+ iput+0x1a2/0x1f7
+ do_unlinkat+0x194/0x28f
+ SyS_unlinkat+0x1b/0x2f
+ do_syscall_64+0x79/0x1ae
+ entry_SYSCALL_64_after_hwframe+0x151/0x0
+
+This patch also logs, with frequency limit, direct IO failures.
+
+Link: http://lkml.kernel.org/r/20181102170632.25921-1-wen.gang.wang@oracle.com
+Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
+Reviewed-by: Junxiao Bi <junxiao.bi@oracle.com>
+Reviewed-by: Changwei Ge <ge.changwei@h3c.com>
+Reviewed-by: Joseph Qi <jiangqi903@gmail.com>
+Cc: Mark Fasheh <mark@fasheh.com>
+Cc: Joel Becker <jlbec@evilplan.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ocfs2/aops.c | 12 ++++++++++--
+ fs/ocfs2/cluster/masklog.h | 9 +++++++++
+ 2 files changed, 19 insertions(+), 2 deletions(-)
+
+--- a/fs/ocfs2/aops.c
++++ b/fs/ocfs2/aops.c
+@@ -2404,8 +2404,16 @@ static int ocfs2_dio_end_io(struct kiocb
+ /* this io's submitter should not have unlocked this before we could */
+ BUG_ON(!ocfs2_iocb_is_rw_locked(iocb));
+
+- if (bytes > 0 && private)
+- ret = ocfs2_dio_end_io_write(inode, private, offset, bytes);
++ if (bytes <= 0)
++ mlog_ratelimited(ML_ERROR, "Direct IO failed, bytes = %lld",
++ (long long)bytes);
++ if (private) {
++ if (bytes > 0)
++ ret = ocfs2_dio_end_io_write(inode, private, offset,
++ bytes);
++ else
++ ocfs2_dio_free_write_ctx(inode, private);
++ }
+
+ ocfs2_iocb_clear_rw_locked(iocb);
+
+--- a/fs/ocfs2/cluster/masklog.h
++++ b/fs/ocfs2/cluster/masklog.h
+@@ -178,6 +178,15 @@ do { \
+ ##__VA_ARGS__); \
+ } while (0)
+
++#define mlog_ratelimited(mask, fmt, ...) \
++do { \
++ static DEFINE_RATELIMIT_STATE(_rs, \
++ DEFAULT_RATELIMIT_INTERVAL, \
++ DEFAULT_RATELIMIT_BURST); \
++ if (__ratelimit(&_rs)) \
++ mlog(mask, fmt, ##__VA_ARGS__); \
++} while (0)
++
+ #define mlog_errno(st) ({ \
+ int _st = (st); \
+ if (_st != -ERESTARTSYS && _st != -EINTR && \
--- /dev/null
+From 89c38422e072bb453e3045b8f1b962a344c3edea Mon Sep 17 00:00:00 2001
+From: John Garry <john.garry@huawei.com>
+Date: Thu, 8 Nov 2018 18:17:03 +0800
+Subject: of, numa: Validate some distance map rules
+
+From: John Garry <john.garry@huawei.com>
+
+commit 89c38422e072bb453e3045b8f1b962a344c3edea upstream.
+
+Currently the NUMA distance map parsing does not validate the distance
+table for the distance-matrix rules 1-2 in [1].
+
+However the arch NUMA code may enforce some of these rules, but not all.
+Such is the case for the arm64 port, which does not enforce the rule that
+the distance between separates nodes cannot equal LOCAL_DISTANCE.
+
+The patch adds the following rules validation:
+- distance of node to self equals LOCAL_DISTANCE
+- distance of separate nodes > LOCAL_DISTANCE
+
+This change avoids a yet-unresolved crash reported in [2].
+
+A note on dealing with symmetrical distances between nodes:
+
+Validating symmetrical distances between nodes is difficult. If it were
+mandated in the bindings that every distance must be recorded in the
+table, then it would be easy. However, it isn't.
+
+In addition to this, it is also possible to record [b, a] distance only
+(and not [a, b]). So, when processing the table for [b, a], we cannot
+assert that current distance of [a, b] != [b, a] as invalid, as [a, b]
+distance may not be present in the table and current distance would be
+default at REMOTE_DISTANCE.
+
+As such, we maintain the policy that we overwrite distance [a, b] = [b, a]
+for b > a. This policy is different to kernel ACPI SLIT validation, which
+allows non-symmetrical distances (ACPI spec SLIT rules allow it). However,
+the distance debug message is dropped as it may be misleading (for a distance
+which is later overwritten).
+
+Some final notes on semantics:
+
+- It is implied that it is the responsibility of the arch NUMA code to
+ reset the NUMA distance map for an error in distance map parsing.
+
+- It is the responsibility of the FW NUMA topology parsing (whether OF or
+ ACPI) to enforce NUMA distance rules, and not arch NUMA code.
+
+[1] Documents/devicetree/bindings/numa.txt
+[2] https://www.spinics.net/lists/arm-kernel/msg683304.html
+
+Cc: stable@vger.kernel.org # 4.7
+Signed-off-by: John Garry <john.garry@huawei.com>
+Acked-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/of/of_numa.c | 9 +++++++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+--- a/drivers/of/of_numa.c
++++ b/drivers/of/of_numa.c
+@@ -126,9 +126,14 @@ static int __init of_numa_parse_distance
+ distance = of_read_number(matrix, 1);
+ matrix++;
+
++ if ((nodea == nodeb && distance != LOCAL_DISTANCE) ||
++ (nodea != nodeb && distance <= LOCAL_DISTANCE)) {
++ pr_err("Invalid distance[node%d -> node%d] = %d\n",
++ nodea, nodeb, distance);
++ return -EINVAL;
++ }
++
+ numa_set_distance(nodea, nodeb, distance);
+- pr_debug("distance[node%d -> node%d] = %d\n",
+- nodea, nodeb, distance);
+
+ /* Set default distance of node B->A same as A->B */
+ if (nodeb > nodea)
--- /dev/null
+From e9a2310fb689151166df7fd9971093362d34bd79 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Wed, 25 Jul 2018 19:47:19 -0500
+Subject: reset: hisilicon: fix potential NULL pointer dereference
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit e9a2310fb689151166df7fd9971093362d34bd79 upstream.
+
+There is a potential execution path in which function
+platform_get_resource() returns NULL. If this happens,
+we will end up having a NULL pointer dereference.
+
+Fix this by replacing devm_ioremap with devm_ioremap_resource,
+which has the NULL check and the memory region request.
+
+This code was detected with the help of Coccinelle.
+
+Cc: stable@vger.kernel.org
+Fixes: 97b7129cd2af ("reset: hisilicon: change the definition of hisi_reset_init")
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Stephen Boyd <sboyd@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/clk/hisilicon/reset.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/clk/hisilicon/reset.c
++++ b/drivers/clk/hisilicon/reset.c
+@@ -109,9 +109,8 @@ struct hisi_reset_controller *hisi_reset
+ return NULL;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+- rstc->membase = devm_ioremap(&pdev->dev,
+- res->start, resource_size(res));
+- if (!rstc->membase)
++ rstc->membase = devm_ioremap_resource(&pdev->dev, res);
++ if (IS_ERR(rstc->membase))
+ return NULL;
+
+ spin_lock_init(&rstc->lock);
--- /dev/null
+From efe328230dc01aa0b1269aad0b5fae73eea4677a Mon Sep 17 00:00:00 2001
+From: "Yan, Zheng" <zyan@redhat.com>
+Date: Thu, 27 Sep 2018 21:16:05 +0800
+Subject: Revert "ceph: fix dentry leak in splice_dentry()"
+
+From: Yan, Zheng <zyan@redhat.com>
+
+commit efe328230dc01aa0b1269aad0b5fae73eea4677a upstream.
+
+This reverts commit 8b8f53af1ed9df88a4c0fbfdf3db58f62060edf3.
+
+splice_dentry() is used by three places. For two places, req->r_dentry
+is passed to splice_dentry(). In the case of error, req->r_dentry does
+not get updated. So splice_dentry() should not drop reference.
+
+Cc: stable@vger.kernel.org # 4.18+
+Signed-off-by: "Yan, Zheng" <zyan@redhat.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/ceph/inode.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/ceph/inode.c
++++ b/fs/ceph/inode.c
+@@ -1087,8 +1087,12 @@ static struct dentry *splice_dentry(stru
+ if (IS_ERR(realdn)) {
+ pr_err("splice_dentry error %ld %p inode %p ino %llx.%llx\n",
+ PTR_ERR(realdn), dn, in, ceph_vinop(in));
+- dput(dn);
+- dn = realdn; /* note realdn contains the error */
++ dn = realdn;
++ /*
++ * Caller should release 'dn' in the case of error.
++ * If 'req->r_dentry' is passed to this function,
++ * caller should leave 'req->r_dentry' untouched.
++ */
+ goto out;
+ } else if (realdn) {
+ dout("dn %p (%d) spliced with %p (%d) "
--- /dev/null
+From 8dc765d438f1e42b3e8227b3b09fad7d73f4ec9a Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Wed, 14 Nov 2018 16:25:51 +0800
+Subject: SCSI: fix queue cleanup race before queue initialization is done
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit 8dc765d438f1e42b3e8227b3b09fad7d73f4ec9a upstream.
+
+c2856ae2f315d ("blk-mq: quiesce queue before freeing queue") has
+already fixed this race, however the implied synchronize_rcu()
+in blk_mq_quiesce_queue() can slow down LUN probe a lot, so caused
+performance regression.
+
+Then 1311326cf4755c7 ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
+tried to quiesce queue for avoiding unnecessary synchronize_rcu()
+only when queue initialization is done, because it is usual to see
+lots of inexistent LUNs which need to be probed.
+
+However, turns out it isn't safe to quiesce queue only when queue
+initialization is done. Because when one SCSI command is completed,
+the user of sending command can be waken up immediately, then the
+scsi device may be removed, meantime the run queue in scsi_end_request()
+is still in-progress, so kernel panic can be caused.
+
+In Red Hat QE lab, there are several reports about this kind of kernel
+panic triggered during kernel booting.
+
+This patch tries to address the issue by grabing one queue usage
+counter during freeing one request and the following run queue.
+
+Fixes: 1311326cf4755c7 ("blk-mq: avoid to synchronize rcu inside blk_cleanup_queue()")
+Cc: Andrew Jones <drjones@redhat.com>
+Cc: Bart Van Assche <bart.vanassche@wdc.com>
+Cc: linux-scsi@vger.kernel.org
+Cc: Martin K. Petersen <martin.petersen@oracle.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
+Cc: stable <stable@vger.kernel.org>
+Cc: jianchao.wang <jianchao.w.wang@oracle.com>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ block/blk-core.c | 5 ++---
+ drivers/scsi/scsi_lib.c | 8 ++++++++
+ 2 files changed, 10 insertions(+), 3 deletions(-)
+
+--- a/block/blk-core.c
++++ b/block/blk-core.c
+@@ -671,9 +671,8 @@ void blk_cleanup_queue(struct request_qu
+ * dispatch may still be in-progress since we dispatch requests
+ * from more than one contexts.
+ *
+- * No need to quiesce queue if it isn't initialized yet since
+- * blk_freeze_queue() should be enough for cases of passthrough
+- * request.
++ * We rely on driver to deal with the race in case that queue
++ * initialization isn't done.
+ */
+ if (q->mq_ops && blk_queue_init_done(q))
+ blk_mq_quiesce_queue(q);
+--- a/drivers/scsi/scsi_lib.c
++++ b/drivers/scsi/scsi_lib.c
+@@ -683,6 +683,12 @@ static bool scsi_end_request(struct requ
+ */
+ scsi_mq_uninit_cmd(cmd);
+
++ /*
++ * queue is still alive, so grab the ref for preventing it
++ * from being cleaned up during running queue.
++ */
++ percpu_ref_get(&q->q_usage_counter);
++
+ __blk_mq_end_request(req, error);
+
+ if (scsi_target(sdev)->single_lun ||
+@@ -690,6 +696,8 @@ static bool scsi_end_request(struct requ
+ kblockd_schedule_work(&sdev->requeue_work);
+ else
+ blk_mq_run_hw_queues(q, true);
++
++ percpu_ref_put(&q->q_usage_counter);
+ } else {
+ unsigned long flags;
+
--- /dev/null
+From f635e48e866ee1a47d2d42ce012fdcc07bf55853 Mon Sep 17 00:00:00 2001
+From: Quinn Tran <quinn.tran@cavium.com>
+Date: Tue, 6 Nov 2018 00:51:21 -0800
+Subject: scsi: qla2xxx: Initialize port speed to avoid setting lower speed
+
+From: Quinn Tran <quinn.tran@cavium.com>
+
+commit f635e48e866ee1a47d2d42ce012fdcc07bf55853 upstream.
+
+This patch initializes port speed so that firmware does not set lower
+operating speed. Setting lower speed in firmware impacts WRITE perfomance.
+
+Fixes: 726b85487067 ("qla2xxx: Add framework for async fabric discovery")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
+Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
+Tested-by: Laurence Oberman <loberman@redhat.com>
+Reviewed-by: Ewan D. Milne <emilne@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/qla2xxx/qla_init.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/scsi/qla2xxx/qla_init.c
++++ b/drivers/scsi/qla2xxx/qla_init.c
+@@ -4236,6 +4236,7 @@ qla2x00_alloc_fcport(scsi_qla_host_t *vh
+ fcport->loop_id = FC_NO_LOOP_ID;
+ qla2x00_set_fcport_state(fcport, FCS_UNCONFIGURED);
+ fcport->supported_classes = FC_COS_UNSPECIFIED;
++ fcport->fp_speed = PORT_SPEED_UNKNOWN;
+
+ fcport->ct_desc.ct_sns = dma_alloc_coherent(&vha->hw->pdev->dev,
+ sizeof(struct ct_sns_pkt), &fcport->ct_desc.ct_sns_dma,
ovl-fix-recursive-oi-lock-in-ovl_link.patch
mips-loongson-3-fix-cpu-uart-irq-delivery-problem.patch
mips-loongson-3-fix-bridge-irq-delivery-problem.patch
+xtensa-add-notes-section-to-the-linker-script.patch
+xtensa-make-sure-bflt-stack-is-16-byte-aligned.patch
+xtensa-fix-boot-parameters-address-translation.patch
+um-drop-own-definition-of-ptrace_sysemu-_singlestep.patch
+clk-s2mps11-fix-matching-when-built-as-module-and-dt-node-contains-compatible.patch
+clk-at91-fix-division-by-zero-in-pll-recalc_rate.patch
+clk-rockchip-fix-static-checker-warning-in-rockchip_ddrclk_get_parent-call.patch
+clk-mvebu-use-correct-bit-for-98dx3236-nand.patch
+media-ov7670-make-xclk-clock-optional.patch
+libceph-bump-ceph_msg_max_data_len.patch
+revert-ceph-fix-dentry-leak-in-splice_dentry.patch
+thermal-enable-broadcom-menu-for-arm64-bcm2835.patch
+mach64-fix-display-corruption-on-big-endian-machines.patch
+mach64-fix-image-corruption-due-to-reading-accelerator-registers.patch
+reset-hisilicon-fix-potential-null-pointer-dereference.patch
+vhost-scsi-truncate-t10-pi-iov_iter-to-prot_bytes.patch
+scsi-qla2xxx-initialize-port-speed-to-avoid-setting-lower-speed.patch
+scsi-fix-queue-cleanup-race-before-queue-initialization-is-done.patch
+soc-ti-qmss-fix-usage-of-irq_set_affinity_hint.patch
+ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch
+ocfs2-free-up-write-context-when-direct-io-failed.patch
+mm-thp-relax-__gfp_thisnode-for-madv_hugepage-mappings.patch
+netfilter-conntrack-fix-calculation-of-next-bucket-number-in-early_drop.patch
+arm-8809-1-proc-v7-fix-thumb-annotation-of-cpu_v7_hvc_switch_mm.patch
+mtd-docg3-don-t-set-conflicting-bch_const_params-option.patch
+of-numa-validate-some-distance-map-rules.patch
--- /dev/null
+From 832ad0e3da4510fd17f98804abe512ea9a747035 Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Wed, 31 Oct 2018 08:41:34 +0000
+Subject: soc: ti: QMSS: Fix usage of irq_set_affinity_hint
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 832ad0e3da4510fd17f98804abe512ea9a747035 upstream.
+
+The Keystone QMSS driver is pretty damaged, in the sense that it
+does things like this:
+
+ irq_set_affinity_hint(irq, to_cpumask(&cpu_map));
+
+where cpu_map is a local variable. As we leave the function, this
+will point to nowhere-land, and things will end-up badly.
+
+Instead, let's use a proper cpumask that gets allocated, giving
+the driver a chance to actually work with things like irqbalance
+as well as have a hypothetical 64bit future.
+
+Cc: stable@vger.kernel.org
+Acked-by: Santosh Shilimkar <ssantosh@kernel.org>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Olof Johansson <olof@lixom.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/soc/ti/knav_qmss.h | 4 ++--
+ drivers/soc/ti/knav_qmss_acc.c | 10 +++++-----
+ drivers/soc/ti/knav_qmss_queue.c | 22 +++++++++++++++-------
+ 3 files changed, 22 insertions(+), 14 deletions(-)
+
+--- a/drivers/soc/ti/knav_qmss.h
++++ b/drivers/soc/ti/knav_qmss.h
+@@ -321,8 +321,8 @@ struct knav_range_ops {
+ };
+
+ struct knav_irq_info {
+- int irq;
+- u32 cpu_map;
++ int irq;
++ struct cpumask *cpu_mask;
+ };
+
+ struct knav_range_info {
+--- a/drivers/soc/ti/knav_qmss_acc.c
++++ b/drivers/soc/ti/knav_qmss_acc.c
+@@ -205,18 +205,18 @@ static int knav_range_setup_acc_irq(stru
+ {
+ struct knav_device *kdev = range->kdev;
+ struct knav_acc_channel *acc;
+- unsigned long cpu_map;
++ struct cpumask *cpu_mask;
+ int ret = 0, irq;
+ u32 old, new;
+
+ if (range->flags & RANGE_MULTI_QUEUE) {
+ acc = range->acc;
+ irq = range->irqs[0].irq;
+- cpu_map = range->irqs[0].cpu_map;
++ cpu_mask = range->irqs[0].cpu_mask;
+ } else {
+ acc = range->acc + queue;
+ irq = range->irqs[queue].irq;
+- cpu_map = range->irqs[queue].cpu_map;
++ cpu_mask = range->irqs[queue].cpu_mask;
+ }
+
+ old = acc->open_mask;
+@@ -239,8 +239,8 @@ static int knav_range_setup_acc_irq(stru
+ acc->name, acc->name);
+ ret = request_irq(irq, knav_acc_int_handler, 0, acc->name,
+ range);
+- if (!ret && cpu_map) {
+- ret = irq_set_affinity_hint(irq, to_cpumask(&cpu_map));
++ if (!ret && cpu_mask) {
++ ret = irq_set_affinity_hint(irq, cpu_mask);
+ if (ret) {
+ dev_warn(range->kdev->dev,
+ "Failed to set IRQ affinity\n");
+--- a/drivers/soc/ti/knav_qmss_queue.c
++++ b/drivers/soc/ti/knav_qmss_queue.c
+@@ -102,19 +102,17 @@ static int knav_queue_setup_irq(struct k
+ struct knav_queue_inst *inst)
+ {
+ unsigned queue = inst->id - range->queue_base;
+- unsigned long cpu_map;
+ int ret = 0, irq;
+
+ if (range->flags & RANGE_HAS_IRQ) {
+ irq = range->irqs[queue].irq;
+- cpu_map = range->irqs[queue].cpu_map;
+ ret = request_irq(irq, knav_queue_int_handler, 0,
+ inst->irq_name, inst);
+ if (ret)
+ return ret;
+ disable_irq(irq);
+- if (cpu_map) {
+- ret = irq_set_affinity_hint(irq, to_cpumask(&cpu_map));
++ if (range->irqs[queue].cpu_mask) {
++ ret = irq_set_affinity_hint(irq, range->irqs[queue].cpu_mask);
+ if (ret) {
+ dev_warn(range->kdev->dev,
+ "Failed to set IRQ affinity\n");
+@@ -1222,9 +1220,19 @@ static int knav_setup_queue_range(struct
+
+ range->num_irqs++;
+
+- if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3)
+- range->irqs[i].cpu_map =
+- (oirq.args[2] & 0x0000ff00) >> 8;
++ if (IS_ENABLED(CONFIG_SMP) && oirq.args_count == 3) {
++ unsigned long mask;
++ int bit;
++
++ range->irqs[i].cpu_mask = devm_kzalloc(dev,
++ cpumask_size(), GFP_KERNEL);
++ if (!range->irqs[i].cpu_mask)
++ return -ENOMEM;
++
++ mask = (oirq.args[2] & 0x0000ff00) >> 8;
++ for_each_set_bit(bit, &mask, BITS_PER_LONG)
++ cpumask_set_cpu(bit, range->irqs[i].cpu_mask);
++ }
+ }
+
+ range->num_irqs = min(range->num_irqs, range->num_queues);
--- /dev/null
+From fec3624f0bcdb6b20ef9ccf9d9d55d0d75d776f8 Mon Sep 17 00:00:00 2001
+From: Allen Wild <allenwild93@gmail.com>
+Date: Tue, 26 Sep 2017 19:37:44 +0200
+Subject: thermal: enable broadcom menu for arm64 bcm2835
+
+From: Allen Wild <allenwild93@gmail.com>
+
+commit fec3624f0bcdb6b20ef9ccf9d9d55d0d75d776f8 upstream.
+
+Moving the bcm2835 thermal driver to the broadcom directory prevented it
+from getting enabled for arm64 builds, since the broadcom directory is only
+available when 32-bit specific ARCH_BCM is set.
+
+Fix this by enabling the Broadcom menu for ARCH_BCM or ARCH_BCM2835.
+
+Fixes: 6892cf07e733 ("thermal: bcm2835: move to the broadcom subdirectory")
+Reviewed-by: Eric Anholt <eric@anholt.net>
+Signed-off-by: Allen Wild <allenwild93@gmail.com>
+Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
+Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/thermal/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/thermal/Kconfig
++++ b/drivers/thermal/Kconfig
+@@ -408,7 +408,7 @@ config MTK_THERMAL
+ controller present in Mediatek SoCs
+
+ menu "Broadcom thermal drivers"
+-depends on ARCH_BCM || COMPILE_TEST
++depends on ARCH_BCM || ARCH_BCM2835 || COMPILE_TEST
+ source "drivers/thermal/broadcom/Kconfig"
+ endmenu
+
--- /dev/null
+From 0676b957c24bfb6e495449ba7b7e72c5b5d79233 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Fri, 15 Jun 2018 16:42:54 +0200
+Subject: um: Drop own definition of PTRACE_SYSEMU/_SINGLESTEP
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 0676b957c24bfb6e495449ba7b7e72c5b5d79233 upstream.
+
+32bit UML used to define PTRACE_SYSEMU and PTRACE_SYSEMU_SINGLESTEP
+own its own because many years ago not all libcs had these request codes
+in their UAPI.
+These days PTRACE_SYSEMU/_SINGLESTEP is well known and part of glibc
+and our own define becomes problematic.
+
+With change c48831d0eebf ("linux/x86: sync sys/ptrace.h with Linux 4.14
+[BZ #22433]") glibc turned PTRACE_SYSEMU/_SINGLESTEP into a enum and
+UML failed to build.
+
+Let's drop our define and rely on the fact that every libc has
+PTRACE_SYSEMU/_SINGLESTEP.
+
+Cc: <stable@vger.kernel.org>
+Cc: Ritesh Raj Sarraf <rrs@researchut.com>
+Reported-and-tested-by: Ritesh Raj Sarraf <rrs@researchut.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/um/shared/sysdep/ptrace_32.h | 10 ----------
+ 1 file changed, 10 deletions(-)
+
+--- a/arch/x86/um/shared/sysdep/ptrace_32.h
++++ b/arch/x86/um/shared/sysdep/ptrace_32.h
+@@ -10,20 +10,10 @@
+
+ static inline void update_debugregs(int seq) {}
+
+-/* syscall emulation path in ptrace */
+-
+-#ifndef PTRACE_SYSEMU
+-#define PTRACE_SYSEMU 31
+-#endif
+-
+ void set_using_sysemu(int value);
+ int get_using_sysemu(void);
+ extern int sysemu_supported;
+
+-#ifndef PTRACE_SYSEMU_SINGLESTEP
+-#define PTRACE_SYSEMU_SINGLESTEP 32
+-#endif
+-
+ #define UPT_SYSCALL_ARG1(r) UPT_BX(r)
+ #define UPT_SYSCALL_ARG2(r) UPT_CX(r)
+ #define UPT_SYSCALL_ARG3(r) UPT_DX(r)
--- /dev/null
+From 4542d623c7134bc1738f8a68ccb6dd546f1c264f Mon Sep 17 00:00:00 2001
+From: Greg Edwards <gedwards@ddn.com>
+Date: Wed, 22 Aug 2018 13:21:53 -0600
+Subject: vhost/scsi: truncate T10 PI iov_iter to prot_bytes
+
+From: Greg Edwards <gedwards@ddn.com>
+
+commit 4542d623c7134bc1738f8a68ccb6dd546f1c264f upstream.
+
+Commands with protection information included were not truncating the
+protection iov_iter to the number of protection bytes in the command.
+This resulted in vhost_scsi mis-calculating the size of the protection
+SGL in vhost_scsi_calc_sgls(), and including both the protection and
+data SG entries in the protection SGL.
+
+Fixes: 09b13fa8c1a1 ("vhost/scsi: Add ANY_LAYOUT support in vhost_scsi_handle_vq")
+Signed-off-by: Greg Edwards <gedwards@ddn.com>
+Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
+Fixes: 09b13fa8c1a1093e9458549ac8bb203a7c65c62a
+Cc: stable@vger.kernel.org
+Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vhost/scsi.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/drivers/vhost/scsi.c
++++ b/drivers/vhost/scsi.c
+@@ -993,7 +993,8 @@ vhost_scsi_handle_vq(struct vhost_scsi *
+ prot_bytes = vhost32_to_cpu(vq, v_req_pi.pi_bytesin);
+ }
+ /*
+- * Set prot_iter to data_iter, and advance past any
++ * Set prot_iter to data_iter and truncate it to
++ * prot_bytes, and advance data_iter past any
+ * preceeding prot_bytes that may be present.
+ *
+ * Also fix up the exp_data_len to reflect only the
+@@ -1002,6 +1003,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *
+ if (prot_bytes) {
+ exp_data_len -= prot_bytes;
+ prot_iter = data_iter;
++ iov_iter_truncate(&prot_iter, prot_bytes);
+ iov_iter_advance(&data_iter, prot_bytes);
+ }
+ tag = vhost64_to_cpu(vq, v_req_pi.tag);
--- /dev/null
+From 4119ba211bc4f1bf638f41e50b7a0f329f58aa16 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Mon, 29 Oct 2018 18:30:13 -0700
+Subject: xtensa: add NOTES section to the linker script
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit 4119ba211bc4f1bf638f41e50b7a0f329f58aa16 upstream.
+
+This section collects all source .note.* sections together in the
+vmlinux image. Without it .note.Linux section may be placed at address
+0, while the rest of the kernel is at its normal address, resulting in a
+huge vmlinux.bin image that may not be linked into the xtensa Image.elf.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/xtensa/boot/Makefile | 2 +-
+ arch/xtensa/kernel/vmlinux.lds.S | 1 +
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/xtensa/boot/Makefile
++++ b/arch/xtensa/boot/Makefile
+@@ -34,7 +34,7 @@ boot-elf boot-redboot: $(addprefix $(obj
+ $(addprefix $(obj)/,$(host-progs))
+ $(Q)$(MAKE) $(build)=$(obj)/$@ $(MAKECMDGOALS)
+
+-OBJCOPYFLAGS = --strip-all -R .comment -R .note.gnu.build-id -O binary
++OBJCOPYFLAGS = --strip-all -R .comment -R .notes -O binary
+
+ vmlinux.bin: vmlinux FORCE
+ $(call if_changed,objcopy)
+--- a/arch/xtensa/kernel/vmlinux.lds.S
++++ b/arch/xtensa/kernel/vmlinux.lds.S
+@@ -146,6 +146,7 @@ SECTIONS
+ .fixup : { *(.fixup) }
+
+ EXCEPTION_TABLE(16)
++ NOTES
+ /* Data section */
+
+ _sdata = .;
--- /dev/null
+From 40dc948f234b73497c3278875eb08a01d5854d3f Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Tue, 13 Nov 2018 23:46:42 -0800
+Subject: xtensa: fix boot parameters address translation
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit 40dc948f234b73497c3278875eb08a01d5854d3f upstream.
+
+The bootloader may pass physical address of the boot parameters structure
+to the MMUv3 kernel in the register a2. Code in the _SetupMMU block in
+the arch/xtensa/kernel/head.S is supposed to map that physical address to
+the virtual address in the configured virtual memory layout.
+
+This code haven't been updated when additional 256+256 and 512+512
+memory layouts were introduced and it may produce wrong addresses when
+used with these layouts.
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/xtensa/kernel/head.S | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/arch/xtensa/kernel/head.S
++++ b/arch/xtensa/kernel/head.S
+@@ -88,9 +88,12 @@ _SetupMMU:
+ initialize_mmu
+ #if defined(CONFIG_MMU) && XCHAL_HAVE_PTP_MMU && XCHAL_HAVE_SPANNING_WAY
+ rsr a2, excsave1
+- movi a3, 0x08000000
++ movi a3, XCHAL_KSEG_PADDR
++ bltu a2, a3, 1f
++ sub a2, a2, a3
++ movi a3, XCHAL_KSEG_SIZE
+ bgeu a2, a3, 1f
+- movi a3, 0xd0000000
++ movi a3, XCHAL_KSEG_CACHED_VADDR
+ add a2, a2, a3
+ wsr a2, excsave1
+ 1:
--- /dev/null
+From 0773495b1f5f1c5e23551843f87b5ff37e7af8f7 Mon Sep 17 00:00:00 2001
+From: Max Filippov <jcmvbkbc@gmail.com>
+Date: Sun, 4 Nov 2018 01:46:00 -0700
+Subject: xtensa: make sure bFLT stack is 16 byte aligned
+
+From: Max Filippov <jcmvbkbc@gmail.com>
+
+commit 0773495b1f5f1c5e23551843f87b5ff37e7af8f7 upstream.
+
+Xtensa ABI requires stack alignment to be at least 16. In noMMU
+configuration ARCH_SLAB_MINALIGN is used to align stack. Make it at
+least 16.
+
+This fixes the following runtime error in noMMU configuration, caused by
+interaction between insufficiently aligned stack and alloca function,
+that results in corruption of on-stack variable in the libc function
+glob:
+
+ Caught unhandled exception in 'sh' (pid = 47, pc = 0x02d05d65)
+ - should not happen
+ EXCCAUSE is 15
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/xtensa/include/asm/processor.h | 6 +++++-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+--- a/arch/xtensa/include/asm/processor.h
++++ b/arch/xtensa/include/asm/processor.h
+@@ -24,7 +24,11 @@
+ # error Linux requires the Xtensa Windowed Registers Option.
+ #endif
+
+-#define ARCH_SLAB_MINALIGN XCHAL_DATA_WIDTH
++/* Xtensa ABI requires stack alignment to be at least 16 */
++
++#define STACK_ALIGN (XCHAL_DATA_WIDTH > 16 ? XCHAL_DATA_WIDTH : 16)
++
++#define ARCH_SLAB_MINALIGN STACK_ALIGN
+
+ /*
+ * User space process size: 1 GB.
projects / thirdparty / kernel / stable-queue.git / commitdiff
