From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from quickstop.soohrt.org (soohrt.org [85.131.130.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B258B40312F for ; Wed, 27 May 2026 14:43:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=85.131.130.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779893010; cv=none; b=ZnT4dPAFjpIDIIJPj6pu+vUBgUru7S8K6UFZtx5ooF7QEi2pAasNhrt77JFVK22PzagZYMDuA9cKLWjme9rJVPfU2Q69XYPNnXrAoBcQ2f9VmS6cult+X1IMYZ358OyQUFbISYIMj5bJasyF4HbiSFVVBImZDryj9oeUvuo5CEE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779893010; c=relaxed/simple; bh=qfowS+Q7rQVvDEhXvjoc5IlJ+wBrLS+9futrN4RzCew=; h=Date:From:To:Cc:Subject:Message-ID:MIME-Version:Content-Type: Content-Disposition; b=Widsex6joSZL0kofFePPtcQPiFgy2uIXQ+omIhdL+LNOQkLGTUQr6OFjK8tgLKByQbjrIwvuwy8bWdZFTGzj4J4qm6JBLteBhRctjx4lGZ7XOZ0yy+DyNu2Dv6QmTEGbcx0ICv7CRm3RFX5W+u0KpbPMam3zVp8yPIljWqHSO9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=soohrt.org; spf=pass smtp.mailfrom=soohrt.org; arc=none smtp.client-ip=85.131.130.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=soohrt.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=soohrt.org Received: (qmail 3837 invoked by uid 1000); 27 May 2026 14:36:43 -0000 Date: Wed, 27 May 2026 16:36:43 +0200 From: Karsten Desler To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: [REGRESSION] x86/hugetlb: AMD F15h VA alignment offset breaks MAP_HUGETLB alignment Message-ID: <20260527143643.GO31091@soohrt.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Hi, I found a reproducible hugetlb regression on an AMD Family 15h system. On some boots, mmap(MAP_HUGETLB) returns a virtual address that is not aligned to the hugepage size. The mapping is nevertheless installed as a hugetlb VMA. When the process exits, the kernel later BUGs in __unmap_hugepage_range(). 6.18.33 x86_64, AMD opteron 6238, 2M hugepages Example bad mapping captured from /proc/$pid/maps: 7fc67f604000-7fc67f804000 rw-p 00000000 00:0f 12340 /anon_hugepage (deleted) The address has offset 0x4000 within a 2 MiB hugepage. smaps confirms it is really hugetlb: KernelPageSize: 2048 kB MMUPageSize: 2048 kB Private_Hugetlb: 2048 kB VmFlags: rd wr mr mw me de ht Minimal reproducer: echo 1000 > /proc/sys/vm/nr_hugepages mmap(NULL, 1229824, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE|MAP_HUGETLB, -1, 0) On bad boots this returns e.g.: mmap returned 0x7fc67f604000 aligned=no offset=16384 and exiting the process triggers: Kernel BUG at __unmap_hugepage_range+0x5ef/0x640 RIP: __unmap_hugepage_range+0x5ef/0x640 Fixing recursive fault but reboot is needed! The following is AI work, sorry if that's total BS but at the very least, I can reproduce the kernelBUG and booting with align_va_addr=off works around the issue. This is boot-dependent. Some boots work, some fail. The reason appears to be the per-boot AMD F15h VA alignment offset. The old x86 hugetlb path in arch/x86/mm/hugetlbpage.c only set: info.align_mask = PAGE_MASK & ~huge_page_mask(h); It did not add the AMD F15h align offset. After the v6.13-rc1 hugetlb mmap rework, hugetlb mappings go through arch_get_unmapped_area*(), and x86 currently does: if (filp) { info.align_mask = get_align_mask(filp); info.align_offset += get_align_bits(); } For hugetlb, get_align_mask(filp) correctly returns the hugepage alignment mask, but get_align_bits() can still return the AMD F15h per-boot offset, e.g. 0x4000. That produces a non-hugepage-aligned hugetlb VMA. Likely introduced by the v6.13-rc1 series: 1317a5e7f7b1 arch/x86: teach arch_get_unmapped_area_vmflags to handle hugetlb mappings 7bd3f1e1a9ae mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags cc92882ee218 mm: drop hugetlb_get_unmapped_area{_*} functions AI suggests passing filp to get_align_bits and doing if (filp && is_file_hugepages(filp)) return 0; Best regards, Karsten