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 ABC11311959 for ; Thu, 28 May 2026 05:45:30 +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=1779947131; cv=none; b=o/Dmz8wc1zK7blYPvWI20qguohhUOfPTexr0sV1xFLi6sVOo6SHTsdHpLEQFbx40WdDEX1vn8q861/+CnaVqCBRYwunIQvMCPg08WVQJhHAdIHSZMgVNJzl9b6cnlUQb/6mI9/+iaUzAC25rdfy9gsABeTRjsbvehgVDvDQtbGo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779947131; c=relaxed/simple; bh=yrf6V2BFRgK+Y3IgoRfgbYg9VGmWQto6eFqblMj15kY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GVv+zimue9TOkiuzh8Piuvq4ABgoY1QjelhtFdl1/4cPlkrcToEm0Z0VsZlCo32q6BLc8QteeCbzagOIo+utVQIrQxbAAcb63luGd3G3qI/c8u+fY6PECJdP0uU/2eSgGUbGGvx6qS7JtcOWo3IVM1j+anrT05vKcdtS3VzglrI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EomFiBJ6; 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="EomFiBJ6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 479831F000E9; Thu, 28 May 2026 05:45:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779947130; bh=IfakfS8RRgOOidKTiKlmZXDO5zaiJlaw59yW5XZxCy4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EomFiBJ6qMIKdaH51IJowVJb+LsJKhSgjpKTETpHiowkp4BhqAZ+WHVGn74vtjX8G JTWeeUtFyXmS38J/PqmCnbmkB7ao6fXjrC1E37LQ5p09Kj055N0sBe/U6O0CkTw59m HLfrSEW0cG1AMmW24RsMZ5VvwnXvsS4Ok//hVT3kcKaumx/4Kn6bpTrXJIjuC6cGqS /7lWA3xwcto44YSIpr3Xd74XWELeKFMntXA/+XxJ7b43x03NCTAfHVLSrKZ1mLDa17 vir6Jvc+GnRzFMB1m3scmSTWWM2VFftrVDaI5Y+eZIUHDxu5ApokX6SzFSY/QBuEaW 6Ynj5PBEdIbYQ== Date: Thu, 28 May 2026 07:45:24 +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: <5f70e840-9d0e-4cef-8574-b355cf26e0c4@intel.com> 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; I would assume so, but something is definitely going in with the calculation, as I could reproduce this if I artificially set align_offset to 0x1000 for hugetlb mappings. I will find some time today to have a deep look. -- Oscar Salvador SUSE Labs