On 06. 03. 25, 12:57, Greg Kroah-Hartman wrote:
On Thu, Mar 06, 2025 at 11:49:15AM +0000, Ryan Roberts wrote:
On 06/03/2025 08:08, Jiri Slaby wrote:
On 06. 03. 25, 9:07, Jiri Slaby wrote:
On 05. 03. 25, 18:48, Greg Kroah-Hartman wrote:
6.13-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ryan Roberts <ryan.roberts@xxxxxxx>
commit 49c87f7677746f3c5bd16c81b23700bb6b88bfd4 upstream.
...
@@ -401,13 +393,8 @@ pte_t huge_ptep_get_and_clear(struct mm_
{
int ncontig;
size_t pgsize;
- pte_t orig_pte = __ptep_get(ptep);
-
- if (!pte_cont(orig_pte))
- return __ptep_get_and_clear(mm, addr, ptep);
-
- ncontig = find_num_contig(mm, addr, ptep, &pgsize);
+ ncontig = num_contig_ptes(sz, &pgsize);
This fails to build:
/usr/bin/gcc-current/gcc (SUSE Linux) 14.2.1 20250220 [revision
9ffecde121af883b60bbe60d00425036bc873048]
/usr/bin/aarch64-suse-linux-gcc (SUSE Linux) 14.2.1 20250220 [revision
9ffecde121af883b60bbe60d00425036bc873048]
run_oldconfig.sh --check... PASS
Build... FAIL
+ make -j48 -s -C /dev/shm/kbuild/linux.34170/current ARCH=arm64 HOSTCC=gcc
CROSS_COMPILE=aarch64-suse-linux- clean
arch/arm64/mm/hugetlbpage.c:397:35: error: 'sz' undeclared (first use in this
function); did you mean 's8'?
| s8
arch/arm64/mm/hugetlbpage.c:397:35: note: each undeclared identifier is
reported only once for each function it appears in
make[4]: *** [scripts/Makefile.build:197: arch/arm64/mm/hugetlbpage.o] Error 1
It looks like the stable tree is missing this pre-req:
commit 02410ac72ac3707936c07ede66e94360d0d65319
Author: Ryan Roberts <ryan.roberts@xxxxxxx>
Date: Wed Feb 26 12:06:51 2025 +0000
mm: hugetlb: Add huge page size param to huge_ptep_get_and_clear()
Although this patch is marked for stable there was a conflict so it wasn't
applied. I'll try to get the backport done in the next few days.
I'll just drop this one now, can you send me the backports for both of
these when they are ready?
FWIW, the series were three patches, not sure if later "101/157] arm64:
hugetlb: Fix flush_hugetlb_tlb_range() invalidation level" is affected
when either of the two discussed here is not present...
So perhaps drop both 100+101/157 for now?
thanks,
--
js
suse labs
