--- /dev/null
+From ad731d6486f4a6840b2880cddb89b7d93cd4ecad Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <lukenels@cs.washington.edu>
+
+[ 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 <xi.wang@gmail.com>
+Signed-off-by: Luke Nelson <luke.r.nels@gmail.com>
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Link: https://lore.kernel.org/bpf/20200418232655.23870-1-luke.r.nels@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 80e13ee55c284d484724b3dfe58ca55dfbcf5ef6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+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 <tytso@mit.edu>
+
+[ 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 <tytso@mit.edu>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From ed1c0f578b5456a2ba80fdf36cc784084c3333fe Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 17 Apr 2020 11:28:53 +0200
+Subject: hwmon: (jc42) Fix name to have no illegal characters
+
+From: Sascha Hauer <s.hauer@pengutronix.de>
+
+[ 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 <s.hauer@pengutronix.de>
+Link: https://lore.kernel.org/r/20200417092853.31206-1-s.hauer@pengutronix.de
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 6fc09fa31c551bea208145a06c14f75751cf23ef Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 1 Apr 2020 13:23:25 -0500
+Subject: objtool: Fix CONFIG_UBSAN_TRAP unreachable warnings
+
+From: Josh Poimboeuf <jpoimboe@redhat.com>
+
+[ 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 <rdunlap@infradead.org>
+Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Kees Cook <keescook@chromium.org>
+Reviewed-by: Miroslav Benes <mbenes@suse.cz>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/6653ad73c6b59c049211bd7c11ed3809c20ee9f5.1585761021.git.jpoimboe@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From 86719bb50a7968ebf82e6193038fc8d221025676 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 1 Apr 2020 13:23:26 -0500
+Subject: objtool: Support Clang non-section symbols in ORC dump
+
+From: Josh Poimboeuf <jpoimboe@redhat.com>
+
+[ 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 <jpoimboe@redhat.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Reviewed-by: Miroslav Benes <mbenes@suse.cz>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Link: https://lkml.kernel.org/r/b811b5eb1a42602c3b523576dc5efab9ad1c174d.1585761021.git.jpoimboe@redhat.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From bb9849a504169887b187abd32663f707005f5675 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 16 Apr 2020 16:42:46 -0500
+Subject: of: unittest: kmemleak on changeset destroy
+
+From: Frank Rowand <frank.rowand@sony.com>
+
+[ 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. <erhard_f@mailbox.org>
+Signed-off-by: Frank Rowand <frank.rowand@sony.com>
+Signed-off-by: Rob Herring <robh@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From a96a09163b2c1ec7bb94841e7e09846df3b92c2a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 8 Apr 2020 15:26:10 +0200
+Subject: scsi: target: fix PR IN / READ FULL STATUS for FC
+
+From: Bodo Stroesser <bstroesser@ts.fujitsu.com>
+
+[ 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 <bstroesser@ts.fujitsu.com>
+Reviewed-by: Mike Christie <mchristi@redhat.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
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
--- /dev/null
+From db59e54366a5c69b435f58a31fa97a7ef35c126e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 26 Mar 2020 09:03:58 +0100
+Subject: xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant
+ status
+
+From: Juergen Gross <jgross@suse.com>
+
+[ 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 <jgross@suse.com>
+Reviewed-by: Wei Liu <wl@xen.org>
+Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
--- /dev/null
+From bc10e2fe2965cbb97e2f4188ed6430d1070ef455 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 12 Apr 2020 13:11:11 -0700
+Subject: xfs: fix partially uninitialized structure in
+ xfs_reflink_remap_extent
+
+From: Darrick J. Wong <darrick.wong@oracle.com>
+
+[ 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 <darrick.wong@oracle.com>
+Reviewed-by: Brian Foster <bfoster@redhat.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ 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
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
