From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 5FA483EFFCC for ; Thu, 28 May 2026 12:45:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779972308; cv=none; b=bmbMhKILr11nRk3ka4afreJHyJJBdmm0NcbZeyb8O/0XPPdWNl6TAVctREfcCj60zX1VB0oXZ6jsNl24lpJajrlDdMreYETU7LLrYHWOOcLBWhoLxJFA24OucFU2MSWAJU8z6Z9u4jqJU3/xSM4xY6dro4G7cuK1E5B8QvKy9pY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779972308; c=relaxed/simple; bh=9Bgcju8Tg+7wUuoCCNlV/KDTLXdmbLbJvES2FDo9l0k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ouuzbiIH0esGXKTAwIgi6RebI1kGg2sh/5Azd2dGa+3AQxnelEN9zQVM6J84/GOV2s1amzNcipY2jauIIKNrFypcO9dWeWjJLY2Dzbrmicx8ebK8wfzPLboxRel/bz0EoxM4IwrEUYsJYmGw/Y3v7VMQ2sk89Qn1pey53oOhl9k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KvBdIusV; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KvBdIusV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 570A51F00A3C; Thu, 28 May 2026 12:45:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779972307; bh=YGCkHYlaxTOFZUyCB3RVYY+plkaf3HsUJr6zIiU9rC4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=KvBdIusVfuG+rSr77UEkcZ6KVcwGEc85pKwgLl42lw625N3EAUFSlBSRAMVaEfFIW S4PLHmQtxIkSWu1RHQuderc7YsYrNSfLliG2tA5ElX+QTYPInXsILnFWXBoUaL0m6b 43k6JJ67+SgWHb9nYF+uk4tbkt2Pz48cr6iOL+TbLhop+rk3GuHtuL5tWxmP0xW5KE 1y56F4q263hWyKgKoo2uf75w0uhHHKjupFKcdfueMPkBIjJTDLix8ACPdzghGEjdti RbwdIJxfObXt83/PpDpDSOnkjoVrwy+deILtkAdY3euWJL3dy1LwKoz4/IdLfjRYmZ 0cMkAR9s+ZfJQ== Date: Thu, 28 May 2026 14:45:01 +0200 From: "Oscar Salvador (SUSE)" To: Dave Hansen Cc: Karsten Desler , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" Subject: Re: [REGRESSION] x86/hugetlb: AMD F15h VA alignment offset breaks MAP_HUGETLB alignment Message-ID: References: <20260527143643.GO31091@soohrt.org> <5f70e840-9d0e-4cef-8574-b355cf26e0c4@intel.com> 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=us-ascii Content-Disposition: inline In-Reply-To: On Thu, May 28, 2026 at 07:45:24AM +0200, Oscar Salvador (SUSE) wrote: > On Wed, May 27, 2026 at 02:04:10PM -0700, Dave Hansen wrote: > > On 5/27/26 11:28, Oscar Salvador (SUSE) wrote: > > > if (filp) { > > > info.align_mask = get_align_mask(filp); > > > - info.align_offset += get_align_bits(); > > > + /* > > > + * Hugepages must remain hugepage-aligned, so skip adding an offset > > > + * in case we enabled 'align_va_addr'. > > > + */ > > > + if (!is_file_hugepages(filp)) > > > + info.align_offset += get_align_bits(); > > > } > > > > That's a good hack to show the scope of the problem. > > Haha, do not worry, I myself have 0 interestin spreading hugetlb-specific > code around (on the contrary), but I wanted to proof the point. > > > > > But I'd really rather this be dealt with in the arch-independent code, > > not by adding hugetlb hacks to arch code. It isn't even clear to me what > > exactly goes wrong when you set a tiny ->align_offset and have a larger > > ->align_mask. Shouldn't the tiny offset just get masked off? > > > > gap += (info->align_offset - gap) & info->align_mask; Ok, I finally got to it. So, let us assume we ask for a 2MB hugetlb page. ~huge_page_mask = 0x1fffff huge_page_mask_align = PAGE_MASK & ~huge_page_mask(hstate_file(file)) = 0x1ff000 unmapped_area_topdown() info->length = 0x200000 (2MB) info->align_mask = 0x1ff000 /* Adjust search length to account for worst case alignment overhead */ total_gap_lenght_requested = info->length + info->align_mask = 0x3ff000 We find a gap: 0x7f28cfb10000 - 0x7f28cfd10000 (2MB) and assuming align_offset is = 0: gap -= (gap - info->align_offset) & info->align_mask 0x7f28cfb10000 -= 0x7f28cfb10000 & 0x1ff000 = 7f28cfa00000 (2MB aligned) IIUC, we mask what we got with align_mask to know how much we need to substract in order to be properly aligned (and since we already accounted for extra length before, we are sure we do not overstep anything below). Now, I have to acknowledge that I had to look at the code several times, because it was not clear to me why we were not just masking off 2MB, but I guess if we do we lose whatever align_offset gives us (if smaller than align_mask). I mean, code was already like that before my refactoring, just that back then we did "align_offset = 0" unilaterally for hugetlb mappings. The only thing bugging is, should not the same happen for THP-file-backed mappings? -- Oscar Salvador SUSE Labs