From 61d0a3e2ced69fc2b0c860b6dae66aadb34eedcd Mon Sep 17 00:00:00 2001 From: Sasha Levin Date: Mon, 22 Jun 2020 18:44:14 -0400 Subject: [PATCH] Fixes for 4.9 Signed-off-by: Sasha Levin --- ...mst-increase-act-retry-timeout-to-3s.patch | 135 ++++++++++++++++++ ...-cluster-initialization-when-splitti.patch | 122 ++++++++++++++++ queue-4.9/series | 3 + ...sed-relax-sed-symbol-type-regex-for-.patch | 69 +++++++++ 4 files changed, 329 insertions(+) create mode 100644 queue-4.9/drm-dp_mst-increase-act-retry-timeout-to-3s.patch create mode 100644 queue-4.9/ext4-fix-partial-cluster-initialization-when-splitti.patch create mode 100644 queue-4.9/x86-boot-compressed-relax-sed-symbol-type-regex-for-.patch diff --git a/queue-4.9/drm-dp_mst-increase-act-retry-timeout-to-3s.patch b/queue-4.9/drm-dp_mst-increase-act-retry-timeout-to-3s.patch new file mode 100644 index 00000000000..8ab6f414dbd --- /dev/null +++ b/queue-4.9/drm-dp_mst-increase-act-retry-timeout-to-3s.patch @@ -0,0 +1,135 @@ +From fabbd0b5b9ee8ec8317fa90c9746402a77c52a9f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 3 Apr 2020 15:47:15 -0400 +Subject: drm/dp_mst: Increase ACT retry timeout to 3s +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Lyude Paul + +[ Upstream commit 873a95e0d59ac06901ae261dda0b7165ffd002b8 ] + +Currently we only poll for an ACT up to 30 times, with a busy-wait delay +of 100µs between each attempt - giving us a timeout of 2900µs. While +this might seem sensible, it would appear that in certain scenarios it +can take dramatically longer then that for us to receive an ACT. On one +of the EVGA MST hubs that I have available, I observed said hub +sometimes taking longer then a second before signalling the ACT. These +delays mostly seem to occur when previous sideband messages we've sent +are NAKd by the hub, however it wouldn't be particularly surprising if +it's possible to reproduce times like this simply by introducing branch +devices with large LCTs since payload allocations have to take effect on +every downstream device up to the payload's target. + +So, instead of just retrying 30 times we poll for the ACT for up to 3ms, +and additionally use usleep_range() to avoid a very long and rude +busy-wait. Note that the previous retry count of 30 appears to have been +arbitrarily chosen, as I can't find any mention of a recommended timeout +or retry count for ACTs in the DisplayPort 2.0 specification. This also +goes for the range we were previously using for udelay(), although I +suspect that was just copied from the recommended delay for link +training on SST devices. + +Changes since v1: +* Use readx_poll_timeout() instead of open-coding timeout loop - Sean + Paul +Changes since v2: +* Increase poll interval to 200us - Sean Paul +* Print status in hex when we timeout waiting for ACT - Sean Paul + +Signed-off-by: Lyude Paul +Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") +Cc: Sean Paul +Cc: # v3.17+ +Reviewed-by: Sean Paul +Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/drm_dp_mst_topology.c | 54 ++++++++++++++++----------- + 1 file changed, 32 insertions(+), 22 deletions(-) + +diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c +index 528d6575b01e3..bb70c5272fe8e 100644 +--- a/drivers/gpu/drm/drm_dp_mst_topology.c ++++ b/drivers/gpu/drm/drm_dp_mst_topology.c +@@ -29,6 +29,7 @@ + #include + #include + #include ++#include + + #include + +@@ -2673,6 +2674,17 @@ static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr, + return ret; + } + ++static int do_get_act_status(struct drm_dp_aux *aux) ++{ ++ int ret; ++ u8 status; ++ ++ ret = drm_dp_dpcd_readb(aux, DP_PAYLOAD_TABLE_UPDATE_STATUS, &status); ++ if (ret < 0) ++ return ret; ++ ++ return status; ++} + + /** + * drm_dp_check_act_status() - Check ACT handled status. +@@ -2682,30 +2694,28 @@ static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr, + */ + int drm_dp_check_act_status(struct drm_dp_mst_topology_mgr *mgr) + { +- int count = 0, ret; +- u8 status; +- +- do { +- ret = drm_dp_dpcd_readb(mgr->aux, +- DP_PAYLOAD_TABLE_UPDATE_STATUS, +- &status); +- if (ret < 0) { +- DRM_DEBUG_KMS("failed to read payload table status %d\n", +- ret); +- return ret; +- } +- +- if (status & DP_PAYLOAD_ACT_HANDLED) +- break; +- count++; +- udelay(100); +- } while (count < 30); +- +- if (!(status & DP_PAYLOAD_ACT_HANDLED)) { +- DRM_DEBUG_KMS("failed to get ACT bit %d after %d retries\n", +- status, count); ++ /* ++ * There doesn't seem to be any recommended retry count or timeout in ++ * the MST specification. Since some hubs have been observed to take ++ * over 1 second to update their payload allocations under certain ++ * conditions, we use a rather large timeout value. ++ */ ++ const int timeout_ms = 3000; ++ int ret, status; ++ ++ ret = readx_poll_timeout(do_get_act_status, mgr->aux, status, ++ status & DP_PAYLOAD_ACT_HANDLED || status < 0, ++ 200, timeout_ms * USEC_PER_MSEC); ++ if (ret < 0 && status >= 0) { ++ DRM_DEBUG_KMS("Failed to get ACT after %dms, last status: %02x\n", ++ timeout_ms, status); + return -EINVAL; ++ } else if (status < 0) { ++ DRM_DEBUG_KMS("Failed to read payload table status: %d\n", ++ status); ++ return status; + } ++ + return 0; + } + EXPORT_SYMBOL(drm_dp_check_act_status); +-- +2.25.1 + diff --git a/queue-4.9/ext4-fix-partial-cluster-initialization-when-splitti.patch b/queue-4.9/ext4-fix-partial-cluster-initialization-when-splitti.patch new file mode 100644 index 00000000000..948ad8232c9 --- /dev/null +++ b/queue-4.9/ext4-fix-partial-cluster-initialization-when-splitti.patch @@ -0,0 +1,122 @@ +From b030db91ff089a64ad82816502608d3ebaf5089d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 22 May 2020 12:18:44 +0800 +Subject: ext4: fix partial cluster initialization when splitting extent + +From: Jeffle Xu + +[ Upstream commit cfb3c85a600c6aa25a2581b3c1c4db3460f14e46 ] + +Fix the bug when calculating the physical block number of the first +block in the split extent. + +This bug will cause xfstests shared/298 failure on ext4 with bigalloc +enabled occasionally. Ext4 error messages indicate that previously freed +blocks are being freed again, and the following fsck will fail due to +the inconsistency of block bitmap and bg descriptor. + +The following is an example case: + +1. First, Initialize a ext4 filesystem with cluster size '16K', block size +'4K', in which case, one cluster contains four blocks. + +2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent +tree of this file is like: + +... +36864:[0]4:220160 +36868:[0]14332:145408 +51200:[0]2:231424 +... + +3. Then execute PUNCH_HOLE fallocate on this file. The hole range is +like: + +.. +ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 +ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 +ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 +... + +4. Then the extent tree of this file after punching is like + +... +49507:[0]37:158047 +49547:[0]58:158087 +... + +5. Detailed procedure of punching hole [49544, 49546] + +5.1. The block address space: +``` +lblk ~49505 49506 49507~49543 49544~49546 49547~ + ---------+------+-------------+----------------+-------- + extent | hole | extent | hole | extent + ---------+------+-------------+----------------+-------- +pblk ~158045 158046 158047~158083 158084~158086 158087~ +``` + +5.2. The detailed layout of cluster 39521: +``` + cluster 39521 + <-------------------------------> + + hole extent + <----------------------><-------- + +lblk 49544 49545 49546 49547 + +-------+-------+-------+-------+ + | | | | | + +-------+-------+-------+-------+ +pblk 158084 1580845 158086 158087 +``` + +5.3. The ftrace output when punching hole [49544, 49546]: +- ext4_ext_remove_space (start 49544, end 49546) + - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) + - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] + - ext4_free_blocks: (block 158084 count 4) + - ext4_mballoc_free (extent 1/6753/1) + +5.4. Ext4 error message in dmesg: +EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. +EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters + +In this case, the whole cluster 39521 is freed mistakenly when freeing +pblock 158084~158086 (i.e., the first three blocks of this cluster), +although pblock 158087 (the last remaining block of this cluster) has +not been freed yet. + +The root cause of this isuue is that, the pclu of the partial cluster is +calculated mistakenly in ext4_ext_remove_space(). The correct +partial_cluster.pclu (i.e., the cluster number of the first block in the +next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather +than 39522. + +Fixes: f4226d9ea400 ("ext4: fix partial cluster initialization") +Signed-off-by: Jeffle Xu +Reviewed-by: Eric Whitney +Cc: stable@kernel.org # v3.19+ +Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.com +Signed-off-by: Theodore Ts'o +Signed-off-by: Sasha Levin +--- + fs/ext4/extents.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c +index 51c2713a615a1..ab19f61bd04bc 100644 +--- a/fs/ext4/extents.c ++++ b/fs/ext4/extents.c +@@ -2916,7 +2916,7 @@ int ext4_ext_remove_space(struct inode *inode, ext4_lblk_t start, + * in use to avoid freeing it when removing blocks. + */ + if (sbi->s_cluster_ratio > 1) { +- pblk = ext4_ext_pblock(ex) + end - ee_block + 2; ++ pblk = ext4_ext_pblock(ex) + end - ee_block + 1; + partial_cluster = + -(long long) EXT4_B2C(sbi, pblk); + } +-- +2.25.1 + diff --git a/queue-4.9/series b/queue-4.9/series index f7fded8b11d..8523ba20a23 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -83,3 +83,6 @@ drm-encoder_slave-fix-refcouting-error-for-modules.patch drm-dp_mst-reformat-drm_dp_check_act_status-a-bit.patch drm-qxl-use-correct-notify-port-address-when-creating-cursor-ring.patch selinux-fix-double-free.patch +ext4-fix-partial-cluster-initialization-when-splitti.patch +drm-dp_mst-increase-act-retry-timeout-to-3s.patch +x86-boot-compressed-relax-sed-symbol-type-regex-for-.patch diff --git a/queue-4.9/x86-boot-compressed-relax-sed-symbol-type-regex-for-.patch b/queue-4.9/x86-boot-compressed-relax-sed-symbol-type-regex-for-.patch new file mode 100644 index 00000000000..ba1e6b25a9f --- /dev/null +++ b/queue-4.9/x86-boot-compressed-relax-sed-symbol-type-regex-for-.patch @@ -0,0 +1,69 @@ +From b72f0d677d1d74f8ba2395f10737ea1fd33409fc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 22 Jun 2020 19:56:39 +0000 +Subject: x86/boot/compressed: Relax sed symbol type regex for LLVM ld.lld + +From: Ard Biesheuvel + +commit bc310baf2ba381c648983c7f4748327f17324562 upstream. + +The final build stage of the x86 kernel captures some symbol +addresses from the decompressor binary and copies them into zoffset.h. +It uses sed with a regular expression that matches the address, symbol +type and symbol name, and mangles the captured addresses and the names +of symbols of interest into #define directives that are added to +zoffset.h + +The symbol type is indicated by a single letter, which we match +strictly: only letters in the set 'ABCDGRSTVW' are matched, even +though the actual symbol type is relevant and therefore ignored. + +Commit bc7c9d620 ("efi/libstub/x86: Force 'hidden' visibility for +extern declarations") made a change to the way external symbol +references are classified, resulting in 'startup_32' now being +emitted as a hidden symbol. This prevents the use of GOT entries to +refer to this symbol via its absolute address, which recent toolchains +(including Clang based ones) already avoid by default, making this +change a no-op in the majority of cases. + +However, as it turns out, the LLVM linker classifies such hidden +symbols as symbols with static linkage in fully linked ELF binaries, +causing tools such as NM to output a lowercase 't' rather than an upper +case 'T' for the type of such symbols. Since our sed expression only +matches upper case letters for the symbol type, the line describing +startup_32 is disregarded, resulting in a build error like the following + + arch/x86/boot/header.S:568:18: error: symbol 'ZO_startup_32' can not be + undefined in a subtraction expression + init_size: .long (0x00000000008fd000 - ZO_startup_32 + + (((0x0000000001f6361c + ((0x0000000001f6361c >> 8) + 65536) + - 0x00000000008c32e5) + 4095) & ~4095)) # kernel initialization size + +Given that we are only interested in the value of the symbol, let's match +any character in the set 'a-zA-Z' instead. + +Signed-off-by: Ard Biesheuvel +Signed-off-by: Ingo Molnar +Tested-by: Nathan Chancellor +Signed-off-by: Nathan Chancellor +Signed-off-by: Sasha Levin +--- + arch/x86/boot/Makefile | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile +index 3b16935b22bcc..d1df7d2e31b1e 100644 +--- a/arch/x86/boot/Makefile ++++ b/arch/x86/boot/Makefile +@@ -87,7 +87,7 @@ $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE + + SETUP_OBJS = $(addprefix $(obj)/,$(setup-y)) + +-sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [ABCDGRSTVW] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p' ++sed-zoffset := -e 's/^\([0-9a-fA-F]*\) [a-zA-Z] \(startup_32\|startup_64\|efi32_stub_entry\|efi64_stub_entry\|efi_pe_entry\|input_data\|_end\|_ehead\|_text\|z_.*\)$$/\#define ZO_\2 0x\1/p' + + quiet_cmd_zoffset = ZOFFSET $@ + cmd_zoffset = $(NM) $< | sed -n $(sed-zoffset) > $@ +-- +2.25.1 + -- 2.47.3