Hi,
While testing an unrelated patch on the arm64 for-next/core branch, I
spotted an issue in the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD
workaround. The first patch fixes that issue, and the second patch
cleans up the remaining logic.
The issue has existed since the workaround was introduced in commit:
471470bc7052d28c ("arm64: errata: Add Cortex-A520 speculative unprivileged load workaround")
As that logic has recently been reworked in the arm64 for-next/core
branch, these patches are based atop that rework, specifically atop
commit:
546b7cde9b1dd360 ("arm64: Rename ARM64_WORKAROUND_2966298")
As the patches alter the KPTI exception return logic, I've given this
testing with KPTI forced on, forced off, and disabled at build time,
which all appear to be fine. I don't have any hardware requiring the
ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround, but as the
resulting logic for this is very simple I do not expect any issues with
that part of the logic.
Mark.
Mark Rutland (2):
arm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD
arm64: entry: simplify kernel_exit logic
arch/arm64/kernel/entry.S | 25 ++++++++++++++-----------
1 file changed, 14 insertions(+), 11 deletions(-)
--
2.30.2
The patch titled
Subject: selftests/mm: Update va_high_addr_switch.sh to check CPU for la57 flag
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
selftests-mm-update-va_high_addr_switchsh-to-check-cpu-for-la57-flag.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Audra Mitchell <audra(a)redhat.com>
Subject: selftests/mm: Update va_high_addr_switch.sh to check CPU for la57 flag
Date: Fri, 19 Jan 2024 15:58:01 -0500
In order for the page table level 5 to be in use, the CPU must have the
setting enabled in addition to the CONFIG option. Check for the flag to be
set to avoid false test failures on systems that do not have this cpu flag
set.
Link: https://lkml.kernel.org/r/20240119205801.62769-1-audra@redhat.com
Fixes: 4f2930c6718a ("selftests/vm: only run 128TBswitch with 5-level paging")
Signed-off-by: Audra Mitchell <audra(a)redhat.com>
Cc: Rafael Aquini <raquini(a)redhat.com>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Adam Sindelar <adam(a)wowsignal.io>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
tools/testing/selftests/mm/va_high_addr_switch.sh | 6 ++++++
1 file changed, 6 insertions(+)
--- a/tools/testing/selftests/mm/va_high_addr_switch.sh~selftests-mm-update-va_high_addr_switchsh-to-check-cpu-for-la57-flag
+++ a/tools/testing/selftests/mm/va_high_addr_switch.sh
@@ -29,9 +29,15 @@ check_supported_x86_64()
# See man 1 gzip under '-f'.
local pg_table_levels=$(gzip -dcfq "${config}" | grep PGTABLE_LEVELS | cut -d'=' -f 2)
+ local cpu_supports_pl5=$(awk '/^flags/ {if (/la57/) {print 0;}
+ else {print 1}; exit}' /proc/cpuinfo 2>/dev/null)
+
if [[ "${pg_table_levels}" -lt 5 ]]; then
echo "$0: PGTABLE_LEVELS=${pg_table_levels}, must be >= 5 to run this test"
exit $ksft_skip
+ elif [[ "${cpu_supports_pl5}" -ne 0 ]]; then
+ echo "$0: CPU does not have the necessary la57 flag to support page table level 5"
+ exit $ksft_skip
fi
}
_
Patches currently in -mm which might be from audra(a)redhat.com are
selftests-mm-update-va_high_addr_switchsh-to-check-cpu-for-la57-flag.patch
The patch titled
Subject: selftests: mm: fix map_hugetlb failure on 64K page size systems
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Nico Pache <npache(a)redhat.com>
Subject: selftests: mm: fix map_hugetlb failure on 64K page size systems
Date: Fri, 19 Jan 2024 06:14:29 -0700
On systems with 64k page size and 512M huge page sizes, the allocation and
test succeeds but errors out at the munmap. As the comment states, munmap
will failure if its not HUGEPAGE aligned. This is due to the length of
the mapping being 1/2 the size of the hugepage causing the munmap to not
be hugepage aligned. Fix this by making the mapping length the full
hugepage if the hugepage is larger than the length of the mapping.
Link: https://lkml.kernel.org/r/20240119131429.172448-1-npache@redhat.com
Fixes: fa7b9a805c79 ("tools/selftest/vm: allow choosing mem size and page size in map_hugetlb")
Signed-off-by: Nico Pache <npache(a)redhat.com>
Cc: Donet Tom <donettom(a)linux.vnet.ibm.com>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Christophe Leroy <christophe.leroy(a)c-s.fr>
Cc: Michael Ellerman <mpe(a)ellerman.id.au>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
tools/testing/selftests/mm/map_hugetlb.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/tools/testing/selftests/mm/map_hugetlb.c~selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems
+++ a/tools/testing/selftests/mm/map_hugetlb.c
@@ -15,6 +15,7 @@
#include <unistd.h>
#include <sys/mman.h>
#include <fcntl.h>
+#include "vm_util.h"
#define LENGTH (256UL*1024*1024)
#define PROTECTION (PROT_READ | PROT_WRITE)
@@ -58,10 +59,16 @@ int main(int argc, char **argv)
{
void *addr;
int ret;
+ size_t hugepage_size;
size_t length = LENGTH;
int flags = FLAGS;
int shift = 0;
+ hugepage_size = default_huge_page_size();
+ /* munmap with fail if the length is not page aligned */
+ if (hugepage_size > length)
+ length = hugepage_size;
+
if (argc > 1)
length = atol(argv[1]) << 20;
if (argc > 2) {
_
Patches currently in -mm which might be from npache(a)redhat.com are
selftests-mm-fix-map_hugetlb-failure-on-64k-page-size-systems.patch
selftests-mm-perform-some-system-cleanup-before-using-hugepages.patch