--- /dev/null
+From e4731baaf29438508197d3a8a6d4f5a8c51663f8 Mon Sep 17 00:00:00 2001
+From: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
+Date: Mon, 27 May 2024 10:41:28 +0530
+Subject: cpufreq: amd-pstate: Fix the inconsistency in max frequency units
+
+From: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
+
+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 <Dhananjay.Ugwekar@amd.com>
+Acked-by: Mario Limonciello <mario.limonciello@amd.com>
+Acked-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
+Tested-by: Peter Jung <ptr1337@cachyos.org>
+Cc: 5.17+ <stable@vger.kernel.org> # 5.17+
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From a4f813c3ec9d1c32bc402becd1f011b3904dd699 Mon Sep 17 00:00:00 2001
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Date: Mon, 29 Apr 2024 16:01:18 +0300
+Subject: intel_th: pci: Add Meteor Lake-S CPU support
+
+From: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+
+commit a4f813c3ec9d1c32bc402becd1f011b3904dd699 upstream.
+
+Add support for the Trace Hub in Meteor Lake-S CPU.
+
+Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/r/20240429130119.1518073-15-alexander.shishkin@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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,
--- /dev/null
+From e9730744bf3af04cda23799029342aa3cddbc454 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:34 +0100
+Subject: kdb: Fix buffer overflow during tab-complete
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <justinstitt@google.com>
+Closes: https://lore.kernel.org/all/CAFhGd8qESuuifuHsNjFPR-Va3P80bxrw+LqvC8deA8GziUJLpw@mail.gmail.com/
+Cc: stable@vger.kernel.org
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Reviewed-by: Justin Stitt <justinstitt@google.com>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-1-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From db2f9c7dc29114f531df4a425d0867d01e1f1e28 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:36 +0100
+Subject: kdb: Fix console handling when editing and tab-completing commands
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <dianders@chromium.org>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-3-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 */
--- /dev/null
+From 6244917f377bf64719551b58592a02a0336a7439 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:37 +0100
+Subject: kdb: Merge identical case statements in kdb_read()
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <dianders@chromium.org>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-4-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From c9b51ddb66b1d96e4d364c088da0f1dfb004c574 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+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 <daniel.thompson@linaro.org>
+
+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 <dianders@chromium.org>
+Tested-by: Justin Stitt <justinstitt@google.com>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-5-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 09b35989421dfd5573f0b4683c7700a7483c71f9 Mon Sep 17 00:00:00 2001
+From: Daniel Thompson <daniel.thompson@linaro.org>
+Date: Wed, 24 Apr 2024 15:03:35 +0100
+Subject: kdb: Use format-strings rather than '\0' injection in kdb_read()
+
+From: Daniel Thompson <daniel.thompson@linaro.org>
+
+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 <justinstitt@google.com>
+Reviewed-by: Douglas Anderson <dianders@chromium.org>
+Link: https://lore.kernel.org/r/20240424-kgdb_read_refactor-v3-2-f236dbe9828d@linaro.org
+Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 2ef3cec44c60ae171b287db7fc2aa341586d65ba Mon Sep 17 00:00:00 2001
+From: Alexander Potapenko <glider@google.com>
+Date: Tue, 28 May 2024 12:48:06 +0200
+Subject: kmsan: do not wipe out origin when doing partial unpoisoning
+
+From: Alexander Potapenko <glider@google.com>
+
+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 <glider@google.com>
+Reported-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
+ Link: https://lore.kernel.org/lkml/20240524232804.1984355-1-bjohannesmeyer@gmail.com/T/
+Reviewed-by: Marco Elver <elver@google.com>
+Tested-by: Brian Johannesmeyer <bjohannesmeyer@gmail.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Kees Cook <keescook@chromium.org>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
--- /dev/null
+From b174f139bdc8aaaf72f5b67ad1bd512c4868a87e Mon Sep 17 00:00:00 2001
+From: Frank van der Linden <fvdl@google.com>
+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 <fvdl@google.com>
+
+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 <fvdl@google.com>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: Roman Gushchin <roman.gushchin@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 55d134a7b499c77e7cfd0ee41046f3c376e791e5 Mon Sep 17 00:00:00 2001
+From: Frank van der Linden <fvdl@google.com>
+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 <fvdl@google.com>
+
+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 <fvdl@google.com>
+Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
+Acked-by: David Hildenbrand <david@redhat.com>
+Cc: Marek Szyprowski <m.szyprowski@samsung.com>
+Cc: Muchun Song <muchun.song@linux.dev>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
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
--- /dev/null
+From 98937707fea8375e8acea0aaa0b68a956dd52719 Mon Sep 17 00:00:00 2001
+From: Sam Ravnborg <sam@ravnborg.org>
+Date: Sat, 30 Mar 2024 10:57:45 +0100
+Subject: sparc64: Fix number of online CPUs
+
+From: Sam Ravnborg <sam@ravnborg.org>
+
+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 <atish.patra@oracle.com>
+ 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 <sam@ravnborg.org>
+Fixes: 9b2f753ec237 ("sparc64: Fix cpu_possible_mask if nr_cpus is set")
+Reported-by: Nick Bowler <nbowler@draconx.ca>
+Tested-by: Nick Bowler <nbowler@draconx.ca>
+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 <andreas@gaisler.com>
+Cc: David S. Miller <davem@davemloft.net>
+Cc: Atish Patra <atish.patra@oracle.com>
+Cc: Bob Picco <bob.picco@oracle.com>
+Cc: Vijay Kumar <vijay.ac.kumar@oracle.com>
+Cc: David S. Miller <davem@davemloft.net>
+Reviewed-by: Andreas Larsson <andreas@gaisler.com>
+Acked-by: Arnd Bergmann <arnd@arndb.de>
+Link: https://lore.kernel.org/r/20240330-sparc64-warnings-v1-9-37201023ee2f@ravnborg.org
+Signed-off-by: Andreas Larsson <andreas@gaisler.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From cae58516534e110f4a8558d48aa4435e15519121 Mon Sep 17 00:00:00 2001
+From: Judith Mendez <jm@ti.com>
+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 <jm@ti.com>
+
+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 <jm@ti.com>
+Reviewed-by: Guenter Roeck <linux@roeck-us.net>
+Link: https://lore.kernel.org/r/20240417205700.3947408-1-jm@ti.com
+Signed-off-by: Guenter Roeck <linux@roeck-us.net>
+Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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) {
projects / thirdparty / kernel / stable-queue.git / commitdiff
