From: Greg Kroah-Hartman Date: Mon, 19 Nov 2018 11:04:57 +0000 (+0100) Subject: 4.14-stable patches X-Git-Tag: v4.19.3~28 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=93a67d70f76fc42e7efb653c4421ae184066b005;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: arm-8809-1-proc-v7-fix-thumb-annotation-of-cpu_v7_hvc_switch_mm.patch clk-at91-fix-division-by-zero-in-pll-recalc_rate.patch clk-mvebu-use-correct-bit-for-98dx3236-nand.patch clk-rockchip-fix-static-checker-warning-in-rockchip_ddrclk_get_parent-call.patch clk-s2mps11-fix-matching-when-built-as-module-and-dt-node-contains-compatible.patch libceph-bump-ceph_msg_max_data_len.patch mach64-fix-display-corruption-on-big-endian-machines.patch mach64-fix-image-corruption-due-to-reading-accelerator-registers.patch media-ov7670-make-xclk-clock-optional.patch mm-thp-relax-__gfp_thisnode-for-madv_hugepage-mappings.patch mtd-docg3-don-t-set-conflicting-bch_const_params-option.patch netfilter-conntrack-fix-calculation-of-next-bucket-number-in-early_drop.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 of-numa-validate-some-distance-map-rules.patch reset-hisilicon-fix-potential-null-pointer-dereference.patch revert-ceph-fix-dentry-leak-in-splice_dentry.patch scsi-fix-queue-cleanup-race-before-queue-initialization-is-done.patch scsi-qla2xxx-initialize-port-speed-to-avoid-setting-lower-speed.patch soc-ti-qmss-fix-usage-of-irq_set_affinity_hint.patch thermal-enable-broadcom-menu-for-arm64-bcm2835.patch um-drop-own-definition-of-ptrace_sysemu-_singlestep.patch vhost-scsi-truncate-t10-pi-iov_iter-to-prot_bytes.patch xtensa-add-notes-section-to-the-linker-script.patch xtensa-fix-boot-parameters-address-translation.patch xtensa-make-sure-bflt-stack-is-16-byte-aligned.patch --- diff --git a/queue-4.14/arm-8809-1-proc-v7-fix-thumb-annotation-of-cpu_v7_hvc_switch_mm.patch b/queue-4.14/arm-8809-1-proc-v7-fix-thumb-annotation-of-cpu_v7_hvc_switch_mm.patch new file mode 100644 index 00000000000..f12c95ae8e9 --- /dev/null +++ b/queue-4.14/arm-8809-1-proc-v7-fix-thumb-annotation-of-cpu_v7_hvc_switch_mm.patch @@ -0,0 +1,57 @@ +From 6282e916f774e37845c65d1eae9f8c649004f033 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +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 + +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 : [] lr : [] 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: +Fixes: 10115105cb3a ("ARM: spectre-v2: add firmware based hardening") +Reviewed-by: Dave Martin +Acked-by: Marc Zyngier +Signed-off-by: Ard Biesheuvel +Signed-off-by: Russell King +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.14/clk-at91-fix-division-by-zero-in-pll-recalc_rate.patch b/queue-4.14/clk-at91-fix-division-by-zero-in-pll-recalc_rate.patch new file mode 100644 index 00000000000..4aa88a70e69 --- /dev/null +++ b/queue-4.14/clk-at91-fix-division-by-zero-in-pll-recalc_rate.patch @@ -0,0 +1,37 @@ +From 0f5cb0e6225cae2f029944cb8c74617aab6ddd49 Mon Sep 17 00:00:00 2001 +From: Ronald Wahl +Date: Wed, 10 Oct 2018 15:54:54 +0200 +Subject: clk: at91: Fix division by zero in PLL recalc_rate() + +From: Ronald Wahl + +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: +Signed-off-by: Ronald Wahl +Acked-by: Ludovic Desroches +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } + diff --git a/queue-4.14/clk-mvebu-use-correct-bit-for-98dx3236-nand.patch b/queue-4.14/clk-mvebu-use-correct-bit-for-98dx3236-nand.patch new file mode 100644 index 00000000000..7eacf0a779a --- /dev/null +++ b/queue-4.14/clk-mvebu-use-correct-bit-for-98dx3236-nand.patch @@ -0,0 +1,32 @@ +From 00c5a926af12a9f0236928dab3dc9faf621406a1 Mon Sep 17 00:00:00 2001 +From: Chris Packham +Date: Thu, 24 May 2018 17:23:41 +1200 +Subject: clk: mvebu: use correct bit for 98DX3236 NAND + +From: Chris Packham + +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 +Signed-off-by: Stephen Boyd +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/clk-rockchip-fix-static-checker-warning-in-rockchip_ddrclk_get_parent-call.patch b/queue-4.14/clk-rockchip-fix-static-checker-warning-in-rockchip_ddrclk_get_parent-call.patch new file mode 100644 index 00000000000..d6a28fcaad7 --- /dev/null +++ b/queue-4.14/clk-rockchip-fix-static-checker-warning-in-rockchip_ddrclk_get_parent-call.patch @@ -0,0 +1,45 @@ +From 665636b2940d0897c4130253467f5e8c42eea392 Mon Sep 17 00:00:00 2001 +From: Enric Balletbo i Serra +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 + +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 +Reviewed-by: Stephen Boyd +Signed-off-by: Heiko Stuebner +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + diff --git a/queue-4.14/clk-s2mps11-fix-matching-when-built-as-module-and-dt-node-contains-compatible.patch b/queue-4.14/clk-s2mps11-fix-matching-when-built-as-module-and-dt-node-contains-compatible.patch new file mode 100644 index 00000000000..2c7ec1e29a4 --- /dev/null +++ b/queue-4.14/clk-s2mps11-fix-matching-when-built-as-module-and-dt-node-contains-compatible.patch @@ -0,0 +1,77 @@ +From 8985167ecf57f97061599a155bb9652c84ea4913 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +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 + +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:NclocksTCsamsung,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: +Fixes: 53c31b3437a6 ("mfd: sec-core: Add of_compatible strings for clock MFD cells") +Signed-off-by: Krzysztof Kozlowski +Acked-by: Stephen Boyd +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + 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", diff --git a/queue-4.14/libceph-bump-ceph_msg_max_data_len.patch b/queue-4.14/libceph-bump-ceph_msg_max_data_len.patch new file mode 100644 index 00000000000..a82ab560b2e --- /dev/null +++ b/queue-4.14/libceph-bump-ceph_msg_max_data_len.patch @@ -0,0 +1,42 @@ +From 94e6992bb560be8bffb47f287194adf070b57695 Mon Sep 17 00:00:00 2001 +From: Ilya Dryomov +Date: Wed, 26 Sep 2018 18:03:16 +0200 +Subject: libceph: bump CEPH_MSG_MAX_DATA_LEN + +From: Ilya Dryomov + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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" + diff --git a/queue-4.14/mach64-fix-display-corruption-on-big-endian-machines.patch b/queue-4.14/mach64-fix-display-corruption-on-big-endian-machines.patch new file mode 100644 index 00000000000..cc0e1552593 --- /dev/null +++ b/queue-4.14/mach64-fix-display-corruption-on-big-endian-machines.patch @@ -0,0 +1,59 @@ +From 3c6c6a7878d00a3ac997a779c5b9861ff25dfcc8 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +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 + +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 +Reviewed-by: Ville Syrjälä +Cc: stable@vger.kernel.org +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.14/mach64-fix-image-corruption-due-to-reading-accelerator-registers.patch b/queue-4.14/mach64-fix-image-corruption-due-to-reading-accelerator-registers.patch new file mode 100644 index 00000000000..ac20fa3171e --- /dev/null +++ b/queue-4.14/mach64-fix-image-corruption-due-to-reading-accelerator-registers.patch @@ -0,0 +1,114 @@ +From c09bcc91bb94ed91f1391bffcbe294963d605732 Mon Sep 17 00:00:00 2001 +From: Mikulas Patocka +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 + +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 +Reviewed-by: Ville Syrjälä +Cc: stable@vger.kernel.org +Signed-off-by: Bartlomiej Zolnierkiewicz +Signed-off-by: Greg Kroah-Hartman + +--- + 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); + } diff --git a/queue-4.14/media-ov7670-make-xclk-clock-optional.patch b/queue-4.14/media-ov7670-make-xclk-clock-optional.patch new file mode 100644 index 00000000000..4613c20168f --- /dev/null +++ b/queue-4.14/media-ov7670-make-xclk-clock-optional.patch @@ -0,0 +1,71 @@ +From 786fa584eda86d6598db3b87c61dc81f68808d11 Mon Sep 17 00:00:00 2001 +From: Lubomir Rintel +Date: Thu, 4 Oct 2018 17:29:03 -0400 +Subject: media: ov7670: make "xclk" clock optional + +From: Lubomir Rintel + +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 +Signed-off-by: Sakari Ailus +Signed-off-by: Mauro Carvalho Chehab +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-4.14/mm-thp-relax-__gfp_thisnode-for-madv_hugepage-mappings.patch b/queue-4.14/mm-thp-relax-__gfp_thisnode-for-madv_hugepage-mappings.patch new file mode 100644 index 00000000000..b805c3e2790 --- /dev/null +++ b/queue-4.14/mm-thp-relax-__gfp_thisnode-for-madv_hugepage-mappings.patch @@ -0,0 +1,228 @@ +From ac5b2c18911ffe95c08d69273917f90212cf5659 Mon Sep 17 00:00:00 2001 +From: Andrea Arcangeli +Date: Fri, 2 Nov 2018 15:47:59 -0700 +Subject: mm: thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings + +From: Andrea Arcangeli + +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 0000001 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 +Signed-off-by: Michal Hocko +Reported-by: Stefan Priebe +Debugged-by: Andrea Arcangeli +Reported-by: Alex Williamson +Reviewed-by: Mel Gorman +Tested-by: Mel Gorman +Cc: Zi Yan +Cc: Vlastimil Babka +Cc: David Rientjes +Cc: "Kirill A. Shutemov" +Cc: [4.1+] +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } + } diff --git a/queue-4.14/mtd-docg3-don-t-set-conflicting-bch_const_params-option.patch b/queue-4.14/mtd-docg3-don-t-set-conflicting-bch_const_params-option.patch new file mode 100644 index 00000000000..1d55f7c2b40 --- /dev/null +++ b/queue-4.14/mtd-docg3-don-t-set-conflicting-bch_const_params-option.patch @@ -0,0 +1,51 @@ +From be2e1c9dcf76886a83fb1c433a316e26d4ca2550 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Thu, 11 Oct 2018 13:06:16 +0200 +Subject: mtd: docg3: don't set conflicting BCH_CONST_PARAMS option + +From: Arnd Bergmann + +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 +Signed-off-by: Arnd Bergmann +Signed-off-by: Boris Brezillon +Signed-off-by: Greg Kroah-Hartman + +--- + 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 diff --git a/queue-4.14/netfilter-conntrack-fix-calculation-of-next-bucket-number-in-early_drop.patch b/queue-4.14/netfilter-conntrack-fix-calculation-of-next-bucket-number-in-early_drop.patch new file mode 100644 index 00000000000..83c63c585f0 --- /dev/null +++ b/queue-4.14/netfilter-conntrack-fix-calculation-of-next-bucket-number-in-early_drop.patch @@ -0,0 +1,59 @@ +From f393808dc64149ccd0e5a8427505ba2974a59854 Mon Sep 17 00:00:00 2001 +From: Vasily Khoruzhick +Date: Thu, 25 Oct 2018 12:15:43 -0700 +Subject: netfilter: conntrack: fix calculation of next bucket number in early_drop + +From: Vasily Khoruzhick + +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: # v4.7+ +Signed-off-by: Vasily Khoruzhick +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Greg Kroah-Hartman + +--- + 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) { diff --git a/queue-4.14/ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch b/queue-4.14/ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch new file mode 100644 index 00000000000..aca9e6944a9 --- /dev/null +++ b/queue-4.14/ocfs2-fix-a-misuse-a-of-brelse-after-failing-ocfs2_check_dir_entry.patch @@ -0,0 +1,54 @@ +From 29aa30167a0a2e6045a0d6d2e89d8168132333d5 Mon Sep 17 00:00:00 2001 +From: Changwei Ge +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 + +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 +Suggested-by: Changkuo Shi +Reviewed-by: Andrew Morton +Cc: Mark Fasheh +Cc: Joel Becker +Cc: Junxiao Bi +Cc: Joseph Qi +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.14/ocfs2-free-up-write-context-when-direct-io-failed.patch b/queue-4.14/ocfs2-free-up-write-context-when-direct-io-failed.patch new file mode 100644 index 00000000000..92ebef786d7 --- /dev/null +++ b/queue-4.14/ocfs2-free-up-write-context-when-direct-io-failed.patch @@ -0,0 +1,85 @@ +From 5040f8df56fb90c7919f1c9b0b6e54c843437456 Mon Sep 17 00:00:00 2001 +From: Wengang Wang +Date: Fri, 16 Nov 2018 15:08:25 -0800 +Subject: ocfs2: free up write context when direct IO failed + +From: Wengang Wang + +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 +Reviewed-by: Junxiao Bi +Reviewed-by: Changwei Ge +Reviewed-by: Joseph Qi +Cc: Mark Fasheh +Cc: Joel Becker +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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 && \ diff --git a/queue-4.14/of-numa-validate-some-distance-map-rules.patch b/queue-4.14/of-numa-validate-some-distance-map-rules.patch new file mode 100644 index 00000000000..79f4be765d2 --- /dev/null +++ b/queue-4.14/of-numa-validate-some-distance-map-rules.patch @@ -0,0 +1,80 @@ +From 89c38422e072bb453e3045b8f1b962a344c3edea Mon Sep 17 00:00:00 2001 +From: John Garry +Date: Thu, 8 Nov 2018 18:17:03 +0800 +Subject: of, numa: Validate some distance map rules + +From: John Garry + +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 +Acked-by: Will Deacon +Signed-off-by: Rob Herring +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/reset-hisilicon-fix-potential-null-pointer-dereference.patch b/queue-4.14/reset-hisilicon-fix-potential-null-pointer-dereference.patch new file mode 100644 index 00000000000..f1d79e6aed8 --- /dev/null +++ b/queue-4.14/reset-hisilicon-fix-potential-null-pointer-dereference.patch @@ -0,0 +1,42 @@ +From e9a2310fb689151166df7fd9971093362d34bd79 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Wed, 25 Jul 2018 19:47:19 -0500 +Subject: reset: hisilicon: fix potential NULL pointer dereference + +From: Gustavo A. R. Silva + +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 +Signed-off-by: Stephen Boyd +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/revert-ceph-fix-dentry-leak-in-splice_dentry.patch b/queue-4.14/revert-ceph-fix-dentry-leak-in-splice_dentry.patch new file mode 100644 index 00000000000..a123e2a4a20 --- /dev/null +++ b/queue-4.14/revert-ceph-fix-dentry-leak-in-splice_dentry.patch @@ -0,0 +1,41 @@ +From efe328230dc01aa0b1269aad0b5fae73eea4677a Mon Sep 17 00:00:00 2001 +From: "Yan, Zheng" +Date: Thu, 27 Sep 2018 21:16:05 +0800 +Subject: Revert "ceph: fix dentry leak in splice_dentry()" + +From: Yan, Zheng + +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" +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman + +--- + 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) " diff --git a/queue-4.14/scsi-fix-queue-cleanup-race-before-queue-initialization-is-done.patch b/queue-4.14/scsi-fix-queue-cleanup-race-before-queue-initialization-is-done.patch new file mode 100644 index 00000000000..1c0679befc3 --- /dev/null +++ b/queue-4.14/scsi-fix-queue-cleanup-race-before-queue-initialization-is-done.patch @@ -0,0 +1,87 @@ +From 8dc765d438f1e42b3e8227b3b09fad7d73f4ec9a Mon Sep 17 00:00:00 2001 +From: Ming Lei +Date: Wed, 14 Nov 2018 16:25:51 +0800 +Subject: SCSI: fix queue cleanup race before queue initialization is done + +From: Ming Lei + +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 +Cc: Bart Van Assche +Cc: linux-scsi@vger.kernel.org +Cc: Martin K. Petersen +Cc: Christoph Hellwig +Cc: James E.J. Bottomley +Cc: stable +Cc: jianchao.wang +Signed-off-by: Ming Lei +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + diff --git a/queue-4.14/scsi-qla2xxx-initialize-port-speed-to-avoid-setting-lower-speed.patch b/queue-4.14/scsi-qla2xxx-initialize-port-speed-to-avoid-setting-lower-speed.patch new file mode 100644 index 00000000000..e3273b6275f --- /dev/null +++ b/queue-4.14/scsi-qla2xxx-initialize-port-speed-to-avoid-setting-lower-speed.patch @@ -0,0 +1,35 @@ +From f635e48e866ee1a47d2d42ce012fdcc07bf55853 Mon Sep 17 00:00:00 2001 +From: Quinn Tran +Date: Tue, 6 Nov 2018 00:51:21 -0800 +Subject: scsi: qla2xxx: Initialize port speed to avoid setting lower speed + +From: Quinn Tran + +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: +Signed-off-by: Quinn Tran +Signed-off-by: Himanshu Madhani +Tested-by: Laurence Oberman +Reviewed-by: Ewan D. Milne +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + 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, diff --git a/queue-4.14/series b/queue-4.14/series index 994a25efdf4..f3ffb6594e2 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -34,3 +34,29 @@ fuse-set-fr_sent-while-locked.patch 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 diff --git a/queue-4.14/soc-ti-qmss-fix-usage-of-irq_set_affinity_hint.patch b/queue-4.14/soc-ti-qmss-fix-usage-of-irq_set_affinity_hint.patch new file mode 100644 index 00000000000..bba97d67e8e --- /dev/null +++ b/queue-4.14/soc-ti-qmss-fix-usage-of-irq_set_affinity_hint.patch @@ -0,0 +1,128 @@ +From 832ad0e3da4510fd17f98804abe512ea9a747035 Mon Sep 17 00:00:00 2001 +From: Marc Zyngier +Date: Wed, 31 Oct 2018 08:41:34 +0000 +Subject: soc: ti: QMSS: Fix usage of irq_set_affinity_hint + +From: Marc Zyngier + +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 +Signed-off-by: Marc Zyngier +Signed-off-by: Olof Johansson +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/thermal-enable-broadcom-menu-for-arm64-bcm2835.patch b/queue-4.14/thermal-enable-broadcom-menu-for-arm64-bcm2835.patch new file mode 100644 index 00000000000..06df4593f67 --- /dev/null +++ b/queue-4.14/thermal-enable-broadcom-menu-for-arm64-bcm2835.patch @@ -0,0 +1,38 @@ +From fec3624f0bcdb6b20ef9ccf9d9d55d0d75d776f8 Mon Sep 17 00:00:00 2001 +From: Allen Wild +Date: Tue, 26 Sep 2017 19:37:44 +0200 +Subject: thermal: enable broadcom menu for arm64 bcm2835 + +From: Allen Wild + +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 +Signed-off-by: Allen Wild +Signed-off-by: Stefan Wahren +Signed-off-by: Eduardo Valentin +Signed-off-by: Sudip Mukherjee +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + diff --git a/queue-4.14/um-drop-own-definition-of-ptrace_sysemu-_singlestep.patch b/queue-4.14/um-drop-own-definition-of-ptrace_sysemu-_singlestep.patch new file mode 100644 index 00000000000..6a824ab811c --- /dev/null +++ b/queue-4.14/um-drop-own-definition-of-ptrace_sysemu-_singlestep.patch @@ -0,0 +1,55 @@ +From 0676b957c24bfb6e495449ba7b7e72c5b5d79233 Mon Sep 17 00:00:00 2001 +From: Richard Weinberger +Date: Fri, 15 Jun 2018 16:42:54 +0200 +Subject: um: Drop own definition of PTRACE_SYSEMU/_SINGLESTEP + +From: Richard Weinberger + +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: +Cc: Ritesh Raj Sarraf +Reported-and-tested-by: Ritesh Raj Sarraf +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman + +--- + 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) diff --git a/queue-4.14/vhost-scsi-truncate-t10-pi-iov_iter-to-prot_bytes.patch b/queue-4.14/vhost-scsi-truncate-t10-pi-iov_iter-to-prot_bytes.patch new file mode 100644 index 00000000000..d938f0d6918 --- /dev/null +++ b/queue-4.14/vhost-scsi-truncate-t10-pi-iov_iter-to-prot_bytes.patch @@ -0,0 +1,47 @@ +From 4542d623c7134bc1738f8a68ccb6dd546f1c264f Mon Sep 17 00:00:00 2001 +From: Greg Edwards +Date: Wed, 22 Aug 2018 13:21:53 -0600 +Subject: vhost/scsi: truncate T10 PI iov_iter to prot_bytes + +From: Greg Edwards + +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 +Signed-off-by: Michael S. Tsirkin +Fixes: 09b13fa8c1a1093e9458549ac8bb203a7c65c62a +Cc: stable@vger.kernel.org +Reviewed-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + 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); diff --git a/queue-4.14/xtensa-add-notes-section-to-the-linker-script.patch b/queue-4.14/xtensa-add-notes-section-to-the-linker-script.patch new file mode 100644 index 00000000000..4a6ae505699 --- /dev/null +++ b/queue-4.14/xtensa-add-notes-section-to-the-linker-script.patch @@ -0,0 +1,44 @@ +From 4119ba211bc4f1bf638f41e50b7a0f329f58aa16 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Mon, 29 Oct 2018 18:30:13 -0700 +Subject: xtensa: add NOTES section to the linker script + +From: Max Filippov + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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 = .; diff --git a/queue-4.14/xtensa-fix-boot-parameters-address-translation.patch b/queue-4.14/xtensa-fix-boot-parameters-address-translation.patch new file mode 100644 index 00000000000..906f7206e2a --- /dev/null +++ b/queue-4.14/xtensa-fix-boot-parameters-address-translation.patch @@ -0,0 +1,43 @@ +From 40dc948f234b73497c3278875eb08a01d5854d3f Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Tue, 13 Nov 2018 23:46:42 -0800 +Subject: xtensa: fix boot parameters address translation + +From: Max Filippov + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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: diff --git a/queue-4.14/xtensa-make-sure-bflt-stack-is-16-byte-aligned.patch b/queue-4.14/xtensa-make-sure-bflt-stack-is-16-byte-aligned.patch new file mode 100644 index 00000000000..9b0d5850299 --- /dev/null +++ b/queue-4.14/xtensa-make-sure-bflt-stack-is-16-byte-aligned.patch @@ -0,0 +1,45 @@ +From 0773495b1f5f1c5e23551843f87b5ff37e7af8f7 Mon Sep 17 00:00:00 2001 +From: Max Filippov +Date: Sun, 4 Nov 2018 01:46:00 -0700 +Subject: xtensa: make sure bFLT stack is 16 byte aligned + +From: Max Filippov + +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 +Signed-off-by: Greg Kroah-Hartman + +--- + 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.