From: Greg Kroah-Hartman Date: Thu, 13 Jun 2024 08:05:04 +0000 (+0200) Subject: 6.1-stable patches X-Git-Tag: v4.19.316~63 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=beefe531727518952b24177dca5fe04d6569ec4e;p=thirdparty%2Fkernel%2Fstable-queue.git 6.1-stable patches added patches: cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch intel_th-pci-add-meteor-lake-s-cpu-support.patch kdb-fix-buffer-overflow-during-tab-complete.patch kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch kdb-merge-identical-case-statements-in-kdb_read.patch kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch sparc64-fix-number-of-online-cpus.patch watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch --- diff --git a/queue-6.1/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch b/queue-6.1/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch new file mode 100644 index 00000000000..a0608328ad6 --- /dev/null +++ b/queue-6.1/cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch @@ -0,0 +1,59 @@ +From e4731baaf29438508197d3a8a6d4f5a8c51663f8 Mon Sep 17 00:00:00 2001 +From: Dhananjay Ugwekar +Date: Mon, 27 May 2024 10:41:28 +0530 +Subject: cpufreq: amd-pstate: Fix the inconsistency in max frequency units + +From: Dhananjay Ugwekar + +commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream. + +The nominal frequency in cpudata is maintained in MHz whereas all other +frequencies are in KHz. This means we have to convert nominal frequency +value to KHz before we do any interaction with other frequency values. + +In amd_pstate_set_boost(), this conversion from MHz to KHz is missed, +fix that. + +Tested on a AMD Zen4 EPYC server + +Before: +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq +2151 +$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq +400000 +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq +2151 +409422 + +After: +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq +2151000 +$ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq +400000 +$ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq +2151000 +1799527 + +Fixes: ec437d71db77 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors") +Signed-off-by: Dhananjay Ugwekar +Acked-by: Mario Limonciello +Acked-by: Gautham R. Shenoy +Tested-by: Peter Jung +Cc: 5.17+ # 5.17+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/cpufreq/amd-pstate.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/cpufreq/amd-pstate.c ++++ b/drivers/cpufreq/amd-pstate.c +@@ -424,7 +424,7 @@ static int amd_pstate_set_boost(struct c + if (state) + policy->cpuinfo.max_freq = cpudata->max_freq; + else +- policy->cpuinfo.max_freq = cpudata->nominal_freq; ++ policy->cpuinfo.max_freq = cpudata->nominal_freq * 1000; + + policy->max = policy->cpuinfo.max_freq; + diff --git a/queue-6.1/intel_th-pci-add-meteor-lake-s-cpu-support.patch b/queue-6.1/intel_th-pci-add-meteor-lake-s-cpu-support.patch new file mode 100644 index 00000000000..87f3fc397e6 --- /dev/null +++ b/queue-6.1/intel_th-pci-add-meteor-lake-s-cpu-support.patch @@ -0,0 +1,34 @@ +From a4f813c3ec9d1c32bc402becd1f011b3904dd699 Mon Sep 17 00:00:00 2001 +From: Alexander Shishkin +Date: Mon, 29 Apr 2024 16:01:18 +0300 +Subject: intel_th: pci: Add Meteor Lake-S CPU support + +From: Alexander Shishkin + +commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream. + +Add support for the Trace Hub in Meteor Lake-S CPU. + +Signed-off-by: Alexander Shishkin +Reviewed-by: Andy Shevchenko +Cc: stable@kernel.org +Link: https://lore.kernel.org/r/20240429130119.1518073-15-alexander.shishkin@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hwtracing/intel_th/pci.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/hwtracing/intel_th/pci.c ++++ b/drivers/hwtracing/intel_th/pci.c +@@ -290,6 +290,11 @@ static const struct pci_device_id intel_ + .driver_data = (kernel_ulong_t)&intel_th_2x, + }, + { ++ /* Meteor Lake-S CPU */ ++ PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xae24), ++ .driver_data = (kernel_ulong_t)&intel_th_2x, ++ }, ++ { + /* Raptor Lake-S */ + PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x7a26), + .driver_data = (kernel_ulong_t)&intel_th_2x, diff --git a/queue-6.1/kdb-fix-buffer-overflow-during-tab-complete.patch b/queue-6.1/kdb-fix-buffer-overflow-during-tab-complete.patch new file mode 100644 index 00000000000..652b4415615 --- /dev/null +++ b/queue-6.1/kdb-fix-buffer-overflow-during-tab-complete.patch @@ -0,0 +1,64 @@ +From e9730744bf3af04cda23799029342aa3cddbc454 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:34 +0100 +Subject: kdb: Fix buffer overflow during tab-complete + +From: Daniel Thompson + +commit e9730744bf3af04cda23799029342aa3cddbc454 upstream. + +Currently, when the user attempts symbol completion with the Tab key, kdb +will use strncpy() to insert the completed symbol into the command buffer. +Unfortunately it passes the size of the source buffer rather than the +destination to strncpy() with predictably horrible results. Most obviously +if the command buffer is already full but cp, the cursor position, is in +the middle of the buffer, then we will write past the end of the supplied +buffer. + +Fix this by replacing the dubious strncpy() calls with memmove()/memcpy() +calls plus explicit boundary checks to make sure we have enough space +before we start moving characters around. + +Reported-by: Justin Stitt +Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziUJLpw@mail.gmail.com/ +Cc: stable@vger.kernel.org +Reviewed-by: Douglas Anderson +Reviewed-by: Justin Stitt +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 21 +++++++++++++-------- + 1 file changed, 13 insertions(+), 8 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -353,14 +353,19 @@ poll_again: + kdb_printf(kdb_prompt_str); + kdb_printf("%s", buffer); + } else if (tab != 2 && count > 0) { +- len_tmp = strlen(p_tmp); +- strncpy(p_tmp+len_tmp, cp, lastchar-cp+1); +- len_tmp = strlen(p_tmp); +- strncpy(cp, p_tmp+len, len_tmp-len + 1); +- len = len_tmp - len; +- kdb_printf("%s", cp); +- cp += len; +- lastchar += len; ++ /* How many new characters do we want from tmpbuffer? */ ++ len_tmp = strlen(p_tmp) - len; ++ if (lastchar + len_tmp >= bufend) ++ len_tmp = bufend - lastchar; ++ ++ if (len_tmp) { ++ /* + 1 ensures the '\0' is memmove'd */ ++ memmove(cp+len_tmp, cp, (lastchar-cp) + 1); ++ memcpy(cp, p_tmp+len, len_tmp); ++ kdb_printf("%s", cp); ++ cp += len_tmp; ++ lastchar += len_tmp; ++ } + } + kdb_nextline = 1; /* reset output line number */ + break; diff --git a/queue-6.1/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch b/queue-6.1/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch new file mode 100644 index 00000000000..91d117bfd07 --- /dev/null +++ b/queue-6.1/kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch @@ -0,0 +1,63 @@ +From db2f9c7dc29114f531df4a425d0867d01e1f1e28 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:36 +0100 +Subject: kdb: Fix console handling when editing and tab-completing commands + +From: Daniel Thompson + +commit db2f9c7dc29114f531df4a425d0867d01e1f1e28 upstream. + +Currently, if the cursor position is not at the end of the command buffer +and the user uses the Tab-complete functions, then the console does not +leave the cursor in the correct position. + +For example consider the following buffer with the cursor positioned +at the ^: + +md kdb_pro 10 + ^ + +Pressing tab should result in: + +md kdb_prompt_str 10 + ^ + +However this does not happen. Instead the cursor is placed at the end +(after then 10) and further cursor movement redraws incorrectly. The +same problem exists when we double-Tab but in a different part of the +code. + +Fix this by sending a carriage return and then redisplaying the text to +the left of the cursor. + +Cc: stable@vger.kernel.org +Reviewed-by: Douglas Anderson +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-3-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -369,6 +369,8 @@ poll_again: + kdb_printf("\n"); + kdb_printf(kdb_prompt_str); + kdb_printf("%s", buffer); ++ if (cp != lastchar) ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } else if (tab != 2 && count > 0) { + /* How many new characters do we want from tmpbuffer? */ + len_tmp = strlen(p_tmp) - len; +@@ -382,6 +384,9 @@ poll_again: + kdb_printf("%s", cp); + cp += len_tmp; + lastchar += len_tmp; ++ if (cp != lastchar) ++ kdb_position_cursor(kdb_prompt_str, ++ buffer, cp); + } + } + kdb_nextline = 1; /* reset output line number */ diff --git a/queue-6.1/kdb-merge-identical-case-statements-in-kdb_read.patch b/queue-6.1/kdb-merge-identical-case-statements-in-kdb_read.patch new file mode 100644 index 00000000000..68ca047445a --- /dev/null +++ b/queue-6.1/kdb-merge-identical-case-statements-in-kdb_read.patch @@ -0,0 +1,48 @@ +From 6244917f377bf64719551b58592a02a0336a7439 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:37 +0100 +Subject: kdb: Merge identical case statements in kdb_read() + +From: Daniel Thompson + +commit 6244917f377bf64719551b58592a02a0336a7439 upstream. + +The code that handles case 14 (down) and case 16 (up) has been copy and +pasted despite being byte-for-byte identical. Combine them. + +Cc: stable@vger.kernel.org # Not a bug fix but it is needed for later bug fixes +Reviewed-by: Douglas Anderson +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-4-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 10 +--------- + 1 file changed, 1 insertion(+), 9 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -303,6 +303,7 @@ poll_again: + } + break; + case 14: /* Down */ ++ case 16: /* Up */ + memset(tmpbuffer, ' ', + strlen(kdb_prompt_str) + (lastchar-buffer)); + *(tmpbuffer+strlen(kdb_prompt_str) + +@@ -317,15 +318,6 @@ poll_again: + ++cp; + } + break; +- case 16: /* Up */ +- memset(tmpbuffer, ' ', +- strlen(kdb_prompt_str) + (lastchar-buffer)); +- *(tmpbuffer+strlen(kdb_prompt_str) + +- (lastchar-buffer)) = '\0'; +- kdb_printf("\r%s\r", tmpbuffer); +- *lastchar = (char)key; +- *(lastchar+1) = '\0'; +- return lastchar; + case 9: /* Tab */ + if (tab < 2) + ++tab; diff --git a/queue-6.1/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch b/queue-6.1/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch new file mode 100644 index 00000000000..653dbdc4040 --- /dev/null +++ b/queue-6.1/kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch @@ -0,0 +1,46 @@ +From c9b51ddb66b1d96e4d364c088da0f1dfb004c574 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:38 +0100 +Subject: kdb: Use format-specifiers rather than memset() for padding in kdb_read() + +From: Daniel Thompson + +commit c9b51ddb66b1d96e4d364c088da0f1dfb004c574 upstream. + +Currently when the current line should be removed from the display +kdb_read() uses memset() to fill a temporary buffer with spaces. +The problem is not that this could be trivially implemented using a +format string rather than open coding it. The real problem is that +it is possible, on systems with a long kdb_prompt_str, to write past +the end of the tmpbuffer. + +Happily, as mentioned above, this can be trivially implemented using a +format string. Make it so! + +Cc: stable@vger.kernel.org +Reviewed-by: Douglas Anderson +Tested-by: Justin Stitt +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-5-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 8 +++----- + 1 file changed, 3 insertions(+), 5 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -304,11 +304,9 @@ poll_again: + break; + case 14: /* Down */ + case 16: /* Up */ +- memset(tmpbuffer, ' ', +- strlen(kdb_prompt_str) + (lastchar-buffer)); +- *(tmpbuffer+strlen(kdb_prompt_str) + +- (lastchar-buffer)) = '\0'; +- kdb_printf("\r%s\r", tmpbuffer); ++ kdb_printf("\r%*c\r", ++ (int)(strlen(kdb_prompt_str) + (lastchar - buffer)), ++ ' '); + *lastchar = (char)key; + *(lastchar+1) = '\0'; + return lastchar; diff --git a/queue-6.1/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch b/queue-6.1/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch new file mode 100644 index 00000000000..08deabcb8a4 --- /dev/null +++ b/queue-6.1/kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch @@ -0,0 +1,127 @@ +From 09b35989421dfd5573f0b4683c7700a7483c71f9 Mon Sep 17 00:00:00 2001 +From: Daniel Thompson +Date: Wed, 24 Apr 2024 15:03:35 +0100 +Subject: kdb: Use format-strings rather than '\0' injection in kdb_read() + +From: Daniel Thompson + +commit 09b35989421dfd5573f0b4683c7700a7483c71f9 upstream. + +Currently when kdb_read() needs to reposition the cursor it uses copy and +paste code that works by injecting an '\0' at the cursor position before +delivering a carriage-return and reprinting the line (which stops at the +'\0'). + +Tidy up the code by hoisting the copy and paste code into an appropriately +named function. Additionally let's replace the '\0' injection with a +proper field width parameter so that the string will be abridged during +formatting instead. + +Cc: stable@vger.kernel.org # Not a bug fix but it is needed for later bug fixes +Tested-by: Justin Stitt +Reviewed-by: Douglas Anderson +Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-2-f236dbe9828d@linaro.org +Signed-off-by: Daniel Thompson +Signed-off-by: Greg Kroah-Hartman +--- + kernel/debug/kdb/kdb_io.c | 55 ++++++++++++++++++++++++++++------------------ + 1 file changed, 34 insertions(+), 21 deletions(-) + +--- a/kernel/debug/kdb/kdb_io.c ++++ b/kernel/debug/kdb/kdb_io.c +@@ -171,6 +171,33 @@ char kdb_getchar(void) + unreachable(); + } + ++/** ++ * kdb_position_cursor() - Place cursor in the correct horizontal position ++ * @prompt: Nil-terminated string containing the prompt string ++ * @buffer: Nil-terminated string containing the entire command line ++ * @cp: Cursor position, pointer the character in buffer where the cursor ++ * should be positioned. ++ * ++ * The cursor is positioned by sending a carriage-return and then printing ++ * the content of the line until we reach the correct cursor position. ++ * ++ * There is some additional fine detail here. ++ * ++ * Firstly, even though kdb_printf() will correctly format zero-width fields ++ * we want the second call to kdb_printf() to be conditional. That keeps things ++ * a little cleaner when LOGGING=1. ++ * ++ * Secondly, we can't combine everything into one call to kdb_printf() since ++ * that renders into a fixed length buffer and the combined print could result ++ * in unwanted truncation. ++ */ ++static void kdb_position_cursor(char *prompt, char *buffer, char *cp) ++{ ++ kdb_printf("\r%s", kdb_prompt_str); ++ if (cp > buffer) ++ kdb_printf("%.*s", (int)(cp - buffer), buffer); ++} ++ + /* + * kdb_read + * +@@ -199,7 +226,6 @@ static char *kdb_read(char *buffer, size + * and null byte */ + char *lastchar; + char *p_tmp; +- char tmp; + static char tmpbuffer[CMD_BUFLEN]; + int len = strlen(buffer); + int len_tmp; +@@ -236,12 +262,8 @@ poll_again: + } + *(--lastchar) = '\0'; + --cp; +- kdb_printf("\b%s \r", cp); +- tmp = *cp; +- *cp = '\0'; +- kdb_printf(kdb_prompt_str); +- kdb_printf("%s", buffer); +- *cp = tmp; ++ kdb_printf("\b%s ", cp); ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } + break; + case 13: /* enter */ +@@ -258,19 +280,14 @@ poll_again: + memcpy(tmpbuffer, cp+1, lastchar - cp - 1); + memcpy(cp, tmpbuffer, lastchar - cp - 1); + *(--lastchar) = '\0'; +- kdb_printf("%s \r", cp); +- tmp = *cp; +- *cp = '\0'; +- kdb_printf(kdb_prompt_str); +- kdb_printf("%s", buffer); +- *cp = tmp; ++ kdb_printf("%s ", cp); ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } + break; + case 1: /* Home */ + if (cp > buffer) { +- kdb_printf("\r"); +- kdb_printf(kdb_prompt_str); + cp = buffer; ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } + break; + case 5: /* End */ +@@ -376,13 +393,9 @@ poll_again: + memcpy(cp+1, tmpbuffer, lastchar - cp); + *++lastchar = '\0'; + *cp = key; +- kdb_printf("%s\r", cp); ++ kdb_printf("%s", cp); + ++cp; +- tmp = *cp; +- *cp = '\0'; +- kdb_printf(kdb_prompt_str); +- kdb_printf("%s", buffer); +- *cp = tmp; ++ kdb_position_cursor(kdb_prompt_str, buffer, cp); + } else { + *++lastchar = '\0'; + *cp++ = key; diff --git a/queue-6.1/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch b/queue-6.1/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch new file mode 100644 index 00000000000..ab4733109f2 --- /dev/null +++ b/queue-6.1/kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch @@ -0,0 +1,68 @@ +From 2ef3cec44c60ae171b287db7fc2aa341586d65ba Mon Sep 17 00:00:00 2001 +From: Alexander Potapenko +Date: Tue, 28 May 2024 12:48:06 +0200 +Subject: kmsan: do not wipe out origin when doing partial unpoisoning + +From: Alexander Potapenko + +commit 2ef3cec44c60ae171b287db7fc2aa341586d65ba upstream. + +As noticed by Brian, KMSAN should not be zeroing the origin when +unpoisoning parts of a four-byte uninitialized value, e.g.: + + char a[4]; + kmsan_unpoison_memory(a, 1); + +This led to false negatives, as certain poisoned values could receive zero +origins, preventing those values from being reported. + +To fix the problem, check that kmsan_internal_set_shadow_origin() writes +zero origins only to slots which have zero shadow. + +Link: https://lkml.kernel.org/r/20240528104807.738758-1-glider@google.com +Fixes: f80be4571b19 ("kmsan: add KMSAN runtime core") +Signed-off-by: Alexander Potapenko +Reported-by: Brian Johannesmeyer + Link: https://lore.kernel.org/lkml/20240524232804.1984355-1-bjohannesmeyer@gmail.com/T/ +Reviewed-by: Marco Elver +Tested-by: Brian Johannesmeyer +Cc: Dmitry Vyukov +Cc: Kees Cook +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/kmsan/core.c | 15 +++++++++++---- + 1 file changed, 11 insertions(+), 4 deletions(-) + +--- a/mm/kmsan/core.c ++++ b/mm/kmsan/core.c +@@ -258,8 +258,7 @@ void kmsan_internal_set_shadow_origin(vo + u32 origin, bool checked) + { + u64 address = (u64)addr; +- void *shadow_start; +- u32 *origin_start; ++ u32 *shadow_start, *origin_start; + size_t pad = 0; + + KMSAN_WARN_ON(!kmsan_metadata_is_contiguous(addr, size)); +@@ -287,8 +286,16 @@ void kmsan_internal_set_shadow_origin(vo + origin_start = + (u32 *)kmsan_get_metadata((void *)address, KMSAN_META_ORIGIN); + +- for (int i = 0; i < size / KMSAN_ORIGIN_SIZE; i++) +- origin_start[i] = origin; ++ /* ++ * If the new origin is non-zero, assume that the shadow byte is also non-zero, ++ * and unconditionally overwrite the old origin slot. ++ * If the new origin is zero, overwrite the old origin slot iff the ++ * corresponding shadow slot is zero. ++ */ ++ for (int i = 0; i < size / KMSAN_ORIGIN_SIZE; i++) { ++ if (origin || !shadow_start[i]) ++ origin_start[i] = origin; ++ } + } + + struct page *kmsan_vmalloc_to_page_or_null(void *vaddr) diff --git a/queue-6.1/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch b/queue-6.1/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch new file mode 100644 index 00000000000..11a7d630cb2 --- /dev/null +++ b/queue-6.1/mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch @@ -0,0 +1,46 @@ +From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001 +From: Frank van der Linden +Date: Thu, 4 Apr 2024 16:25:14 +0000 +Subject: mm/cma: drop incorrect alignment check in cma_init_reserved_mem + +From: Frank van der Linden + +commit b174f139bdc8aaaf72f5b67ad1bd512c4868a87e upstream. + +cma_init_reserved_mem uses IS_ALIGNED to check if the size represented by +one bit in the cma allocation bitmask is aligned with +CMA_MIN_ALIGNMENT_BYTES (pageblock size). + +However, this is too strict, as this will fail if order_per_bit > +pageblock_order, which is a valid configuration. + +We could check IS_ALIGNED both ways, but since both numbers are powers of +two, no check is needed at all. + +Link: https://lkml.kernel.org/r/20240404162515.527802-1-fvdl@google.com +Fixes: de9e14eebf33 ("drivers: dma-contiguous: add initialization from device tree") +Signed-off-by: Frank van der Linden +Acked-by: David Hildenbrand +Cc: Marek Szyprowski +Cc: Muchun Song +Cc: Roman Gushchin +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/cma.c | 4 ---- + 1 file changed, 4 deletions(-) + +--- a/mm/cma.c ++++ b/mm/cma.c +@@ -186,10 +186,6 @@ int __init cma_init_reserved_mem(phys_ad + if (!size || !memblock_is_region_reserved(base, size)) + return -EINVAL; + +- /* alignment should be aligned with order_per_bit */ +- if (!IS_ALIGNED(CMA_MIN_ALIGNMENT_PAGES, 1 << order_per_bit)) +- return -EINVAL; +- + /* ensure minimal alignment required by mm core */ + if (!IS_ALIGNED(base | size, CMA_MIN_ALIGNMENT_BYTES)) + return -EINVAL; diff --git a/queue-6.1/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch b/queue-6.1/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch new file mode 100644 index 00000000000..8410744243e --- /dev/null +++ b/queue-6.1/mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch @@ -0,0 +1,58 @@ +From 55d134a7b499c77e7cfd0ee41046f3c376e791e5 Mon Sep 17 00:00:00 2001 +From: Frank van der Linden +Date: Thu, 4 Apr 2024 16:25:15 +0000 +Subject: mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid + +From: Frank van der Linden + +commit 55d134a7b499c77e7cfd0ee41046f3c376e791e5 upstream. + +The hugetlb_cma code passes 0 in the order_per_bit argument to +cma_declare_contiguous_nid (the alignment, computed using the page order, +is correctly passed in). + +This causes a bit in the cma allocation bitmap to always represent a 4k +page, making the bitmaps potentially very large, and slower. + +It would create bitmaps that would be pretty big. E.g. for a 4k page +size on x86, hugetlb_cma=64G would mean a bitmap size of (64G / 4k) / 8 +== 2M. With HUGETLB_PAGE_ORDER as order_per_bit, as intended, this +would be (64G / 2M) / 8 == 4k. So, that's quite a difference. + +Also, this restricted the hugetlb_cma area to ((PAGE_SIZE << +MAX_PAGE_ORDER) * 8) * PAGE_SIZE (e.g. 128G on x86) , since +bitmap_alloc uses normal page allocation, and is thus restricted by +MAX_PAGE_ORDER. Specifying anything about that would fail the CMA +initialization. + +So, correctly pass in the order instead. + +Link: https://lkml.kernel.org/r/20240404162515.527802-2-fvdl@google.com +Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") +Signed-off-by: Frank van der Linden +Acked-by: Roman Gushchin +Acked-by: David Hildenbrand +Cc: Marek Szyprowski +Cc: Muchun Song +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + mm/hugetlb.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/mm/hugetlb.c ++++ b/mm/hugetlb.c +@@ -7669,9 +7669,9 @@ void __init hugetlb_cma_reserve(int orde + * huge page demotion. + */ + res = cma_declare_contiguous_nid(0, size, 0, +- PAGE_SIZE << HUGETLB_PAGE_ORDER, +- 0, false, name, +- &hugetlb_cma[nid], nid); ++ PAGE_SIZE << HUGETLB_PAGE_ORDER, ++ HUGETLB_PAGE_ORDER, false, name, ++ &hugetlb_cma[nid], nid); + if (res) { + pr_warn("hugetlb_cma: reservation failed: err %d, node %d", + res, nid); diff --git a/queue-6.1/series b/queue-6.1/series index c8c13015f12..a52676d3b80 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -55,3 +55,15 @@ mm-fix-race-between-__split_huge_pmd_locked-and-gup-fast.patch scsi-core-handle-devices-which-return-an-unusually-large-vpd-page-count.patch net-ipv6-fix-route-deleting-failure-when-metric-equals-0.patch net-9p-fix-uninit-value-in-p9_client_rpc.patch +kmsan-do-not-wipe-out-origin-when-doing-partial-unpoisoning.patch +cpufreq-amd-pstate-fix-the-inconsistency-in-max-frequency-units.patch +intel_th-pci-add-meteor-lake-s-cpu-support.patch +sparc64-fix-number-of-online-cpus.patch +mm-cma-drop-incorrect-alignment-check-in-cma_init_reserved_mem.patch +mm-hugetlb-pass-correct-order_per_bit-to-cma_declare_contiguous_nid.patch +watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch +kdb-fix-buffer-overflow-during-tab-complete.patch +kdb-use-format-strings-rather-than-0-injection-in-kdb_read.patch +kdb-fix-console-handling-when-editing-and-tab-completing-commands.patch +kdb-merge-identical-case-statements-in-kdb_read.patch +kdb-use-format-specifiers-rather-than-memset-for-padding-in-kdb_read.patch diff --git a/queue-6.1/sparc64-fix-number-of-online-cpus.patch b/queue-6.1/sparc64-fix-number-of-online-cpus.patch new file mode 100644 index 00000000000..fed880d0048 --- /dev/null +++ b/queue-6.1/sparc64-fix-number-of-online-cpus.patch @@ -0,0 +1,123 @@ +From 98937707fea8375e8acea0aaa0b68a956dd52719 Mon Sep 17 00:00:00 2001 +From: Sam Ravnborg +Date: Sat, 30 Mar 2024 10:57:45 +0100 +Subject: sparc64: Fix number of online CPUs + +From: Sam Ravnborg + +commit 98937707fea8375e8acea0aaa0b68a956dd52719 upstream. + +Nick Bowler reported: + When using newer kernels on my Ultra 60 with dual 450MHz UltraSPARC-II + CPUs, I noticed that only CPU 0 comes up, while older kernels (including + 4.7) are working fine with both CPUs. + + I bisected the failure to this commit: + + 9b2f753ec23710aa32c0d837d2499db92fe9115b is the first bad commit + commit 9b2f753ec23710aa32c0d837d2499db92fe9115b + Author: Atish Patra + Date: Thu Sep 15 14:54:40 2016 -0600 + + sparc64: Fix cpu_possible_mask if nr_cpus is set + + This is a small change that reverts very easily on top of 5.18: there is + just one trivial conflict. Once reverted, both CPUs work again. + + Maybe this is related to the fact that the CPUs on this system are + numbered CPU0 and CPU2 (there is no CPU1)? + +The current code that adjust cpu_possible based on nr_cpu_ids do not +take into account that CPU's may not come one after each other. +Move the chech to the function that setup the cpu_possible mask +so there is no need to adjust it later. + +Signed-off-by: Sam Ravnborg +Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set") +Reported-by: Nick Bowler +Tested-by: Nick Bowler +Link: https://lore.kernel.org/sparclinux/20201009161924.c8f031c079dd852941307870@gmx.de/ +Link: https://lore.kernel.org/all/CADyTPEwt=ZNams+1bpMB1F9w_vUdPsGCt92DBQxxq_VtaLoTdw@mail.gmail.com/ +Cc: stable@vger.kernel.org # v4.8+ +Cc: Andreas Larsson +Cc: David S. Miller +Cc: Atish Patra +Cc: Bob Picco +Cc: Vijay Kumar +Cc: David S. Miller +Reviewed-by: Andreas Larsson +Acked-by: Arnd Bergmann +Link: https://lore.kernel.org/r/20240330-sparc64-warnings-v1-9-37201023ee2f@ravnborg.org +Signed-off-by: Andreas Larsson +Signed-off-by: Greg Kroah-Hartman +--- + arch/sparc/include/asm/smp_64.h | 2 -- + arch/sparc/kernel/prom_64.c | 4 +++- + arch/sparc/kernel/setup_64.c | 1 - + arch/sparc/kernel/smp_64.c | 14 -------------- + 4 files changed, 3 insertions(+), 18 deletions(-) + +--- a/arch/sparc/include/asm/smp_64.h ++++ b/arch/sparc/include/asm/smp_64.h +@@ -47,7 +47,6 @@ void arch_send_call_function_ipi_mask(co + int hard_smp_processor_id(void); + #define raw_smp_processor_id() (current_thread_info()->cpu) + +-void smp_fill_in_cpu_possible_map(void); + void smp_fill_in_sib_core_maps(void); + void cpu_play_dead(void); + +@@ -77,7 +76,6 @@ void __cpu_die(unsigned int cpu); + #define smp_fill_in_sib_core_maps() do { } while (0) + #define smp_fetch_global_regs() do { } while (0) + #define smp_fetch_global_pmu() do { } while (0) +-#define smp_fill_in_cpu_possible_map() do { } while (0) + #define smp_init_cpu_poke() do { } while (0) + #define scheduler_poke() do { } while (0) + +--- a/arch/sparc/kernel/prom_64.c ++++ b/arch/sparc/kernel/prom_64.c +@@ -483,7 +483,9 @@ static void *record_one_cpu(struct devic + ncpus_probed++; + #ifdef CONFIG_SMP + set_cpu_present(cpuid, true); +- set_cpu_possible(cpuid, true); ++ ++ if (num_possible_cpus() < nr_cpu_ids) ++ set_cpu_possible(cpuid, true); + #endif + return NULL; + } +--- a/arch/sparc/kernel/setup_64.c ++++ b/arch/sparc/kernel/setup_64.c +@@ -684,7 +684,6 @@ void __init setup_arch(char **cmdline_p) + + paging_init(); + init_sparc64_elf_hwcap(); +- smp_fill_in_cpu_possible_map(); + /* + * Once the OF device tree and MDESC have been setup and nr_cpus has + * been parsed, we know the list of possible cpus. Therefore we can +--- a/arch/sparc/kernel/smp_64.c ++++ b/arch/sparc/kernel/smp_64.c +@@ -1204,20 +1204,6 @@ void __init smp_setup_processor_id(void) + xcall_deliver_impl = hypervisor_xcall_deliver; + } + +-void __init smp_fill_in_cpu_possible_map(void) +-{ +- int possible_cpus = num_possible_cpus(); +- int i; +- +- if (possible_cpus > nr_cpu_ids) +- possible_cpus = nr_cpu_ids; +- +- for (i = 0; i < possible_cpus; i++) +- set_cpu_possible(i, true); +- for (; i < NR_CPUS; i++) +- set_cpu_possible(i, false); +-} +- + void smp_fill_in_sib_core_maps(void) + { + unsigned int i; diff --git a/queue-6.1/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch b/queue-6.1/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch new file mode 100644 index 00000000000..aa7097d3a14 --- /dev/null +++ b/queue-6.1/watchdog-rti_wdt-set-min_hw_heartbeat_ms-to-accommodate-a-safety-margin.patch @@ -0,0 +1,107 @@ +From cae58516534e110f4a8558d48aa4435e15519121 Mon Sep 17 00:00:00 2001 +From: Judith Mendez +Date: Wed, 17 Apr 2024 15:57:00 -0500 +Subject: watchdog: rti_wdt: Set min_hw_heartbeat_ms to accommodate a safety margin + +From: Judith Mendez + +commit cae58516534e110f4a8558d48aa4435e15519121 upstream. + +On AM62x, the watchdog is pet before the valid window is open. Fix +min_hw_heartbeat and accommodate a 2% + static offset safety margin. +The static offset accounts for max hardware error. + +Remove the hack in the driver which shifts the open window boundary, +since it is no longer necessary due to the fix mentioned above. + +cc: stable@vger.kernel.org +Fixes: 5527483f8f7c ("watchdog: rti-wdt: attach to running watchdog during probe") +Signed-off-by: Judith Mendez +Reviewed-by: Guenter Roeck +Link: https://lore.kernel.org/r/20240417205700.3947408-1-jm@ti.com +Signed-off-by: Guenter Roeck +Signed-off-by: Wim Van Sebroeck +Signed-off-by: Greg Kroah-Hartman +--- + drivers/watchdog/rti_wdt.c | 34 +++++++++++++++------------------- + 1 file changed, 15 insertions(+), 19 deletions(-) + +--- a/drivers/watchdog/rti_wdt.c ++++ b/drivers/watchdog/rti_wdt.c +@@ -52,6 +52,8 @@ + + #define DWDST BIT(1) + ++#define MAX_HW_ERROR 250 ++ + static int heartbeat = DEFAULT_HEARTBEAT; + + /* +@@ -90,7 +92,7 @@ static int rti_wdt_start(struct watchdog + * to be 50% or less than that; we obviouly want to configure the open + * window as large as possible so we select the 50% option. + */ +- wdd->min_hw_heartbeat_ms = 500 * wdd->timeout; ++ wdd->min_hw_heartbeat_ms = 520 * wdd->timeout + MAX_HW_ERROR; + + /* Generate NMI when wdt expires */ + writel_relaxed(RTIWWDRX_NMI, wdt->base + RTIWWDRXCTRL); +@@ -124,31 +126,33 @@ static int rti_wdt_setup_hw_hb(struct wa + * be petted during the open window; not too early or not too late. + * The HW configuration options only allow for the open window size + * to be 50% or less than that. ++ * To avoid any glitches, we accommodate 2% + max hardware error ++ * safety margin. + */ + switch (wsize) { + case RTIWWDSIZE_50P: +- /* 50% open window => 50% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 500 * heartbeat; ++ /* 50% open window => 52% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 520 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_25P: +- /* 25% open window => 75% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 750 * heartbeat; ++ /* 25% open window => 77% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 770 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_12P5: +- /* 12.5% open window => 87.5% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 875 * heartbeat; ++ /* 12.5% open window => 89.5% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 895 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_6P25: +- /* 6.5% open window => 93.5% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 935 * heartbeat; ++ /* 6.5% open window => 95.5% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 955 * heartbeat + MAX_HW_ERROR; + break; + + case RTIWWDSIZE_3P125: +- /* 3.125% open window => 96.9% min heartbeat */ +- wdd->min_hw_heartbeat_ms = 969 * heartbeat; ++ /* 3.125% open window => 98.9% min heartbeat */ ++ wdd->min_hw_heartbeat_ms = 989 * heartbeat + MAX_HW_ERROR; + break; + + default: +@@ -221,14 +225,6 @@ static int rti_wdt_probe(struct platform + return -EINVAL; + } + +- /* +- * If watchdog is running at 32k clock, it is not accurate. +- * Adjust frequency down in this case so that we don't pet +- * the watchdog too often. +- */ +- if (wdt->freq < 32768) +- wdt->freq = wdt->freq * 9 / 10; +- + pm_runtime_enable(dev); + ret = pm_runtime_resume_and_get(dev); + if (ret < 0) {