From: Sasha Levin Date: Fri, 1 May 2020 04:38:56 +0000 (-0400) Subject: Fixes for 4.9 X-Git-Tag: v5.4.37~17 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=a9a32b4f131acaa58902292993f5493fb58dcaa9;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.9 Signed-off-by: Sasha Levin --- diff --git a/queue-4.9/bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch b/queue-4.9/bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch new file mode 100644 index 00000000000..65d41022c2c --- /dev/null +++ b/queue-4.9/bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch @@ -0,0 +1,79 @@ +From ad731d6486f4a6840b2880cddb89b7d93cd4ecad Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 18 Apr 2020 16:26:53 -0700 +Subject: bpf, x86: Fix encoding for lower 8-bit registers in BPF_STX BPF_B + +From: Luke Nelson + +[ Upstream commit aee194b14dd2b2bde6252b3acf57d36dccfc743a ] + +This patch fixes an encoding bug in emit_stx for BPF_B when the source +register is BPF_REG_FP. + +The current implementation for BPF_STX BPF_B in emit_stx saves one REX +byte when the operands can be encoded using Mod-R/M alone. The lower 8 +bits of registers %rax, %rbx, %rcx, and %rdx can be accessed without using +a REX prefix via %al, %bl, %cl, and %dl, respectively. Other registers, +(e.g., %rsi, %rdi, %rbp, %rsp) require a REX prefix to use their 8-bit +equivalents (%sil, %dil, %bpl, %spl). + +The current code checks if the source for BPF_STX BPF_B is BPF_REG_1 +or BPF_REG_2 (which map to %rdi and %rsi), in which case it emits the +required REX prefix. However, it misses the case when the source is +BPF_REG_FP (mapped to %rbp). + +The result is that BPF_STX BPF_B with BPF_REG_FP as the source operand +will read from register %ch instead of the correct %bpl. This patch fixes +the problem by fixing and refactoring the check on which registers need +the extra REX byte. Since no BPF registers map to %rsp, there is no need +to handle %spl. + +Fixes: 622582786c9e0 ("net: filter: x86: internal BPF JIT") +Signed-off-by: Xi Wang +Signed-off-by: Luke Nelson +Signed-off-by: Alexei Starovoitov +Link: https://lore.kernel.org/bpf/20200418232655.23870-1-luke.r.nels@gmail.com +Signed-off-by: Sasha Levin +--- + arch/x86/net/bpf_jit_comp.c | 18 +++++++++++++++--- + 1 file changed, 15 insertions(+), 3 deletions(-) + +diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c +index d9dabd0c31fc4..eb5734112cb49 100644 +--- a/arch/x86/net/bpf_jit_comp.c ++++ b/arch/x86/net/bpf_jit_comp.c +@@ -150,6 +150,19 @@ static bool is_ereg(u32 reg) + BIT(BPF_REG_AX)); + } + ++/* ++ * is_ereg_8l() == true if BPF register 'reg' is mapped to access x86-64 ++ * lower 8-bit registers dil,sil,bpl,spl,r8b..r15b, which need extra byte ++ * of encoding. al,cl,dl,bl have simpler encoding. ++ */ ++static bool is_ereg_8l(u32 reg) ++{ ++ return is_ereg(reg) || ++ (1 << reg) & (BIT(BPF_REG_1) | ++ BIT(BPF_REG_2) | ++ BIT(BPF_REG_FP)); ++} ++ + /* add modifiers if 'reg' maps to x64 registers r8..r15 */ + static u8 add_1mod(u8 byte, u32 reg) + { +@@ -771,9 +784,8 @@ st: if (is_imm8(insn->off)) + /* STX: *(u8*)(dst_reg + off) = src_reg */ + case BPF_STX | BPF_MEM | BPF_B: + /* emit 'mov byte ptr [rax + off], al' */ +- if (is_ereg(dst_reg) || is_ereg(src_reg) || +- /* have to add extra byte for x86 SIL, DIL regs */ +- src_reg == BPF_REG_1 || src_reg == BPF_REG_2) ++ if (is_ereg(dst_reg) || is_ereg_8l(src_reg)) ++ /* Add extra byte for eregs or SIL,DIL,BPL in src_reg */ + EMIT2(add_2mod(0x40, dst_reg, src_reg), 0x88); + else + EMIT1(0x88); +-- +2.20.1 + diff --git a/queue-4.9/ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch b/queue-4.9/ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch new file mode 100644 index 00000000000..872509aa004 --- /dev/null +++ b/queue-4.9/ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch @@ -0,0 +1,52 @@ +From 80e13ee55c284d484724b3dfe58ca55dfbcf5ef6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 13 Apr 2020 23:33:05 -0400 +Subject: ext4: convert BUG_ON's to WARN_ON's in mballoc.c + +From: Theodore Ts'o + +[ Upstream commit 907ea529fc4c3296701d2bfc8b831dd2a8121a34 ] + +If the in-core buddy bitmap gets corrupted (or out of sync with the +block bitmap), issue a WARN_ON and try to recover. In most cases this +involves skipping trying to allocate out of a particular block group. +We can end up declaring the file system corrupted, which is fair, +since the file system probably should be checked before we proceed any +further. + +Link: https://lore.kernel.org/r/20200414035649.293164-1-tytso@mit.edu +Google-Bug-Id: 34811296 +Google-Bug-Id: 34639169 +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/mballoc.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c +index c18668e3135e8..ac13de1a7e420 100644 +--- a/fs/ext4/mballoc.c ++++ b/fs/ext4/mballoc.c +@@ -1944,7 +1944,8 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac, + int free; + + free = e4b->bd_info->bb_free; +- BUG_ON(free <= 0); ++ if (WARN_ON(free <= 0)) ++ return; + + i = e4b->bd_info->bb_first_free; + +@@ -1965,7 +1966,8 @@ void ext4_mb_complex_scan_group(struct ext4_allocation_context *ac, + } + + mb_find_extent(e4b, i, ac->ac_g_ex.fe_len, &ex); +- BUG_ON(ex.fe_len <= 0); ++ if (WARN_ON(ex.fe_len <= 0)) ++ break; + if (free < ex.fe_len) { + ext4_grp_locked_error(sb, e4b->bd_group, 0, 0, + "%d free clusters as per " +-- +2.20.1 + diff --git a/queue-4.9/hwmon-jc42-fix-name-to-have-no-illegal-characters.patch b/queue-4.9/hwmon-jc42-fix-name-to-have-no-illegal-characters.patch new file mode 100644 index 00000000000..fa6fa859c23 --- /dev/null +++ b/queue-4.9/hwmon-jc42-fix-name-to-have-no-illegal-characters.patch @@ -0,0 +1,43 @@ +From ed1c0f578b5456a2ba80fdf36cc784084c3333fe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 17 Apr 2020 11:28:53 +0200 +Subject: hwmon: (jc42) Fix name to have no illegal characters + +From: Sascha Hauer + +[ Upstream commit c843b382e61b5f28a3d917712c69a344f632387c ] + +The jc42 driver passes I2C client's name as hwmon device name. In case +of device tree probed devices this ends up being part of the compatible +string, "jc-42.4-temp". This name contains hyphens and the hwmon core +doesn't like this: + +jc42 2-0018: hwmon: 'jc-42.4-temp' is not a valid name attribute, please fix + +This changes the name to "jc42" which doesn't have any illegal +characters. + +Signed-off-by: Sascha Hauer +Link: https://lore.kernel.org/r/20200417092853.31206-1-s.hauer@pengutronix.de +Signed-off-by: Guenter Roeck +Signed-off-by: Sasha Levin +--- + drivers/hwmon/jc42.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/hwmon/jc42.c b/drivers/hwmon/jc42.c +index 0f1f6421845fd..85435e110ecd9 100644 +--- a/drivers/hwmon/jc42.c ++++ b/drivers/hwmon/jc42.c +@@ -508,7 +508,7 @@ static int jc42_probe(struct i2c_client *client, const struct i2c_device_id *id) + } + data->config = config; + +- hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, ++ hwmon_dev = devm_hwmon_device_register_with_info(dev, "jc42", + data, &jc42_chip_info, + NULL); + return PTR_ERR_OR_ZERO(hwmon_dev); +-- +2.20.1 + diff --git a/queue-4.9/objtool-fix-config_ubsan_trap-unreachable-warnings.patch b/queue-4.9/objtool-fix-config_ubsan_trap-unreachable-warnings.patch new file mode 100644 index 00000000000..4443478ec41 --- /dev/null +++ b/queue-4.9/objtool-fix-config_ubsan_trap-unreachable-warnings.patch @@ -0,0 +1,69 @@ +From 6fc09fa31c551bea208145a06c14f75751cf23ef Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 1 Apr 2020 13:23:25 -0500 +Subject: objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings + +From: Josh Poimboeuf + +[ Upstream commit bd841d6154f5f41f8a32d3c1b0bc229e326e640a ] + +CONFIG_UBSAN_TRAP causes GCC to emit a UD2 whenever it encounters an +unreachable code path. This includes __builtin_unreachable(). Because +the BUG() macro uses __builtin_unreachable() after it emits its own UD2, +this results in a double UD2. In this case objtool rightfully detects +that the second UD2 is unreachable: + + init/main.o: warning: objtool: repair_env_string()+0x1c8: unreachable instruction + +We weren't able to figure out a way to get rid of the double UD2s, so +just silence the warning. + +Reported-by: Randy Dunlap +Signed-off-by: Josh Poimboeuf +Signed-off-by: Borislav Petkov +Reviewed-by: Kees Cook +Reviewed-by: Miroslav Benes +Acked-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/6653ad73c6b59c049211bd7c11ed3809c20ee9f5.1585761021.git.jpoimboe@redhat.com +Signed-off-by: Sasha Levin +--- + tools/objtool/check.c | 17 +++++++++++++++-- + 1 file changed, 15 insertions(+), 2 deletions(-) + +diff --git a/tools/objtool/check.c b/tools/objtool/check.c +index db105207757bc..360845926f665 100644 +--- a/tools/objtool/check.c ++++ b/tools/objtool/check.c +@@ -2035,14 +2035,27 @@ static bool ignore_unreachable_insn(struct instruction *insn) + !strcmp(insn->sec->name, ".altinstr_aux")) + return true; + ++ if (!insn->func) ++ return false; ++ ++ /* ++ * CONFIG_UBSAN_TRAP inserts a UD2 when it sees ++ * __builtin_unreachable(). The BUG() macro has an unreachable() after ++ * the UD2, which causes GCC's undefined trap logic to emit another UD2 ++ * (or occasionally a JMP to UD2). ++ */ ++ if (list_prev_entry(insn, list)->dead_end && ++ (insn->type == INSN_BUG || ++ (insn->type == INSN_JUMP_UNCONDITIONAL && ++ insn->jump_dest && insn->jump_dest->type == INSN_BUG))) ++ return true; ++ + /* + * Check if this (or a subsequent) instruction is related to + * CONFIG_UBSAN or CONFIG_KASAN. + * + * End the search at 5 instructions to avoid going into the weeds. + */ +- if (!insn->func) +- return false; + for (i = 0; i < 5; i++) { + + if (is_kasan_insn(insn) || is_ubsan_insn(insn)) +-- +2.20.1 + diff --git a/queue-4.9/objtool-support-clang-non-section-symbols-in-orc-dum.patch b/queue-4.9/objtool-support-clang-non-section-symbols-in-orc-dum.patch new file mode 100644 index 00000000000..26d318e392e --- /dev/null +++ b/queue-4.9/objtool-support-clang-non-section-symbols-in-orc-dum.patch @@ -0,0 +1,111 @@ +From 86719bb50a7968ebf82e6193038fc8d221025676 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 1 Apr 2020 13:23:26 -0500 +Subject: objtool: Support Clang non-section symbols in ORC dump + +From: Josh Poimboeuf + +[ Upstream commit 8782e7cab51b6bf01a5a86471dd82228af1ac185 ] + +Historically, the relocation symbols for ORC entries have only been +section symbols: + + .text+0: sp:sp+8 bp:(und) type:call end:0 + +However, the Clang assembler is aggressive about stripping section +symbols. In that case we will need to use function symbols: + + freezing_slow_path+0: sp:sp+8 bp:(und) type:call end:0 + +In preparation for the generation of such entries in "objtool orc +generate", add support for reading them in "objtool orc dump". + +Signed-off-by: Josh Poimboeuf +Signed-off-by: Borislav Petkov +Reviewed-by: Miroslav Benes +Acked-by: Peter Zijlstra (Intel) +Link: https://lkml.kernel.org/r/b811b5eb1a42602c3b523576dc5efab9ad1c174d.1585761021.git.jpoimboe@redhat.com +Signed-off-by: Sasha Levin +--- + tools/objtool/orc_dump.c | 44 ++++++++++++++++++++++++---------------- + 1 file changed, 27 insertions(+), 17 deletions(-) + +diff --git a/tools/objtool/orc_dump.c b/tools/objtool/orc_dump.c +index c3343820916a6..7cbbbdd932f1d 100644 +--- a/tools/objtool/orc_dump.c ++++ b/tools/objtool/orc_dump.c +@@ -78,7 +78,7 @@ int orc_dump(const char *_objname) + char *name; + size_t nr_sections; + Elf64_Addr orc_ip_addr = 0; +- size_t shstrtab_idx; ++ size_t shstrtab_idx, strtab_idx = 0; + Elf *elf; + Elf_Scn *scn; + GElf_Shdr sh; +@@ -139,6 +139,8 @@ int orc_dump(const char *_objname) + + if (!strcmp(name, ".symtab")) { + symtab = data; ++ } else if (!strcmp(name, ".strtab")) { ++ strtab_idx = i; + } else if (!strcmp(name, ".orc_unwind")) { + orc = data->d_buf; + orc_size = sh.sh_size; +@@ -150,7 +152,7 @@ int orc_dump(const char *_objname) + } + } + +- if (!symtab || !orc || !orc_ip) ++ if (!symtab || !strtab_idx || !orc || !orc_ip) + return 0; + + if (orc_size % sizeof(*orc) != 0) { +@@ -171,21 +173,29 @@ int orc_dump(const char *_objname) + return -1; + } + +- scn = elf_getscn(elf, sym.st_shndx); +- if (!scn) { +- WARN_ELF("elf_getscn"); +- return -1; +- } +- +- if (!gelf_getshdr(scn, &sh)) { +- WARN_ELF("gelf_getshdr"); +- return -1; +- } +- +- name = elf_strptr(elf, shstrtab_idx, sh.sh_name); +- if (!name || !*name) { +- WARN_ELF("elf_strptr"); +- return -1; ++ if (GELF_ST_TYPE(sym.st_info) == STT_SECTION) { ++ scn = elf_getscn(elf, sym.st_shndx); ++ if (!scn) { ++ WARN_ELF("elf_getscn"); ++ return -1; ++ } ++ ++ if (!gelf_getshdr(scn, &sh)) { ++ WARN_ELF("gelf_getshdr"); ++ return -1; ++ } ++ ++ name = elf_strptr(elf, shstrtab_idx, sh.sh_name); ++ if (!name) { ++ WARN_ELF("elf_strptr"); ++ return -1; ++ } ++ } else { ++ name = elf_strptr(elf, strtab_idx, sym.st_name); ++ if (!name) { ++ WARN_ELF("elf_strptr"); ++ return -1; ++ } + } + + printf("%s+%llx:", name, (unsigned long long)rela.r_addend); +-- +2.20.1 + diff --git a/queue-4.9/of-unittest-kmemleak-on-changeset-destroy.patch b/queue-4.9/of-unittest-kmemleak-on-changeset-destroy.patch new file mode 100644 index 00000000000..4d200441430 --- /dev/null +++ b/queue-4.9/of-unittest-kmemleak-on-changeset-destroy.patch @@ -0,0 +1,44 @@ +From bb9849a504169887b187abd32663f707005f5675 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 16 Apr 2020 16:42:46 -0500 +Subject: of: unittest: kmemleak on changeset destroy + +From: Frank Rowand + +[ Upstream commit b3fb36ed694b05738d45218ea72cf7feb10ce2b1 ] + +kmemleak reports several memory leaks from devicetree unittest. +This is the fix for problem 1 of 5. + +of_unittest_changeset() reaches deeply into the dynamic devicetree +functions. Several nodes were left with an elevated reference +count and thus were not properly cleaned up. Fix the reference +counts so that the memory will be freed. + +Fixes: 201c910bd689 ("of: Transactional DT support.") +Reported-by: Erhard F. +Signed-off-by: Frank Rowand +Signed-off-by: Rob Herring +Signed-off-by: Sasha Levin +--- + drivers/of/unittest.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c +index aeb6d3009ae92..144d123f6ea4f 100644 +--- a/drivers/of/unittest.c ++++ b/drivers/of/unittest.c +@@ -539,6 +539,10 @@ static void __init of_unittest_changeset(void) + unittest(!of_changeset_revert(&chgset), "revert failed\n"); + + of_changeset_destroy(&chgset); ++ ++ of_node_put(n1); ++ of_node_put(n2); ++ of_node_put(n21); + #endif + } + +-- +2.20.1 + diff --git a/queue-4.9/scsi-target-fix-pr-in-read-full-status-for-fc.patch b/queue-4.9/scsi-target-fix-pr-in-read-full-status-for-fc.patch new file mode 100644 index 00000000000..7acfb156758 --- /dev/null +++ b/queue-4.9/scsi-target-fix-pr-in-read-full-status-for-fc.patch @@ -0,0 +1,41 @@ +From a96a09163b2c1ec7bb94841e7e09846df3b92c2a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 8 Apr 2020 15:26:10 +0200 +Subject: scsi: target: fix PR IN / READ FULL STATUS for FC + +From: Bodo Stroesser + +[ Upstream commit 8fed04eb79a74cbf471dfaa755900a51b37273ab ] + +Creation of the response to READ FULL STATUS fails for FC based +reservations. Reason is the too high loop limit (< 24) in +fc_get_pr_transport_id(). The string representation of FC WWPN is 23 chars +long only ("11:22:33:44:55:66:77:88"). So when i is 23, the loop body is +executed a last time for the ending '\0' of the string and thus hex2bin() +reports an error. + +Link: https://lore.kernel.org/r/20200408132610.14623-3-bstroesser@ts.fujitsu.com +Signed-off-by: Bodo Stroesser +Reviewed-by: Mike Christie +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/target/target_core_fabric_lib.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/target/target_core_fabric_lib.c b/drivers/target/target_core_fabric_lib.c +index 6e75095af6818..2ecb2f7042a13 100644 +--- a/drivers/target/target_core_fabric_lib.c ++++ b/drivers/target/target_core_fabric_lib.c +@@ -75,7 +75,7 @@ static int fc_get_pr_transport_id( + * encoded TransportID. + */ + ptr = &se_nacl->initiatorname[0]; +- for (i = 0; i < 24; ) { ++ for (i = 0; i < 23; ) { + if (!strncmp(&ptr[i], ":", 1)) { + i++; + continue; +-- +2.20.1 + diff --git a/queue-4.9/series b/queue-4.9/series index e6e975762c0..7c72fa2c820 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -63,3 +63,12 @@ usb-gadget-udc-bdc-remove-unnecessary-null-checks-in-bdc_req_complete.patch nfsd-memory-corruption-in-nfsd4_lock.patch net-cxgb4-check-the-return-from-t4_query_params-properly.patch perf-core-fix-parent-pid-tid-in-task-exit-events.patch +bpf-x86-fix-encoding-for-lower-8-bit-registers-in-bp.patch +xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch +scsi-target-fix-pr-in-read-full-status-for-fc.patch +objtool-fix-config_ubsan_trap-unreachable-warnings.patch +objtool-support-clang-non-section-symbols-in-orc-dum.patch +xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch +ext4-convert-bug_on-s-to-warn_on-s-in-mballoc.c.patch +of-unittest-kmemleak-on-changeset-destroy.patch +hwmon-jc42-fix-name-to-have-no-illegal-characters.patch diff --git a/queue-4.9/xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch b/queue-4.9/xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch new file mode 100644 index 00000000000..4cac4e75da4 --- /dev/null +++ b/queue-4.9/xen-xenbus-ensure-xenbus_map_ring_valloc-returns-pro.patch @@ -0,0 +1,56 @@ +From db59e54366a5c69b435f58a31fa97a7ef35c126e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 26 Mar 2020 09:03:58 +0100 +Subject: xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant + status + +From: Juergen Gross + +[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ] + +xenbus_map_ring_valloc() maps a ring page and returns the status of the +used grant (0 meaning success). + +There are Xen hypervisors which might return the value 1 for the status +of a failed grant mapping due to a bug. Some callers of +xenbus_map_ring_valloc() test for errors by testing the returned status +to be less than zero, resulting in no error detected and crashing later +due to a not available ring page. + +Set the return value of xenbus_map_ring_valloc() to GNTST_general_error +in case the grant status reported by Xen is greater than zero. + +This is part of XSA-316. + +Signed-off-by: Juergen Gross +Reviewed-by: Wei Liu +Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com +Signed-off-by: Juergen Gross +Signed-off-by: Sasha Levin +--- + drivers/xen/xenbus/xenbus_client.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/xen/xenbus/xenbus_client.c b/drivers/xen/xenbus/xenbus_client.c +index 056da6ee1a357..df27cefb2fa35 100644 +--- a/drivers/xen/xenbus/xenbus_client.c ++++ b/drivers/xen/xenbus/xenbus_client.c +@@ -469,7 +469,14 @@ EXPORT_SYMBOL_GPL(xenbus_free_evtchn); + int xenbus_map_ring_valloc(struct xenbus_device *dev, grant_ref_t *gnt_refs, + unsigned int nr_grefs, void **vaddr) + { +- return ring_ops->map(dev, gnt_refs, nr_grefs, vaddr); ++ int err; ++ ++ err = ring_ops->map(dev, gnt_refs, nr_grefs, vaddr); ++ /* Some hypervisors are buggy and can return 1. */ ++ if (err > 0) ++ err = GNTST_general_error; ++ ++ return err; + } + EXPORT_SYMBOL_GPL(xenbus_map_ring_valloc); + +-- +2.20.1 + diff --git a/queue-4.9/xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch b/queue-4.9/xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch new file mode 100644 index 00000000000..ac9cfe079c0 --- /dev/null +++ b/queue-4.9/xfs-fix-partially-uninitialized-structure-in-xfs_ref.patch @@ -0,0 +1,39 @@ +From bc10e2fe2965cbb97e2f4188ed6430d1070ef455 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 12 Apr 2020 13:11:11 -0700 +Subject: xfs: fix partially uninitialized structure in + xfs_reflink_remap_extent + +From: Darrick J. Wong + +[ Upstream commit c142932c29e533ee892f87b44d8abc5719edceec ] + +In the reflink extent remap function, it turns out that uirec (the block +mapping corresponding only to the part of the passed-in mapping that got +unmapped) was not fully initialized. Specifically, br_state was not +being copied from the passed-in struct to the uirec. This could lead to +unpredictable results such as the reflinked mapping being marked +unwritten in the destination file. + +Signed-off-by: Darrick J. Wong +Reviewed-by: Brian Foster +Signed-off-by: Sasha Levin +--- + fs/xfs/xfs_reflink.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/xfs_reflink.c +index 17d3c964a2a23..6b753b969f7b8 100644 +--- a/fs/xfs/xfs_reflink.c ++++ b/fs/xfs/xfs_reflink.c +@@ -1162,6 +1162,7 @@ xfs_reflink_remap_extent( + uirec.br_startblock = irec->br_startblock + rlen; + uirec.br_startoff = irec->br_startoff + rlen; + uirec.br_blockcount = unmap_len - rlen; ++ uirec.br_state = irec->br_state; + unmap_len = rlen; + + /* If this isn't a real mapping, we're done. */ +-- +2.20.1 +