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 121642E9ED6 for ; Mon, 1 Jun 2026 20:03:00 +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=1780344182; cv=none; b=VLprzdE9fTtkxxltRAi2Wd9ZWgutaLzPbfDaZBGnO5Yd5Iixn2eEyLaoeibT4VJEoSoV1Gf+RfvlDrMVXShkjuMirAO5BE1VQdph+zSkxELLhMPuZuvRIO72OQ/i45YVgPUEDD1dsxVl7JBpy+dxS48RrWOD5GIZgAXHDgLqwlY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780344182; c=relaxed/simple; bh=Ogg0uSWk+SnMQOtl8L/bIn7uyJEkp2kZ4hs1PPsK2wc=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=XkK3UxHYow7KeFacIdoMyJgYGP3eww3S2+ic2TEeLV0DzBB6u+9Y+/8IQjI3kTq7nUoyh2u4hJlgYihaIzhU8DSTmHbnqoFYDxEkl7DcBVMKNSFQkfC6voYpve8ckXj4vhrzAAeiGygJUEM5AQeUK+IWEXFLnBFe/l42qVvHj0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=DCoLN5+0; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="DCoLN5+0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4161C1F00893; Mon, 1 Jun 2026 20:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1780344180; bh=iAqQ33Zmo2XOpsCnN70itqavnjXkkjUWiyAHthdaBDQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=DCoLN5+02nCJr5BvocelbIKKk9IhUD63ylOM/juDBrNeOAfHccgRu6RMEM2NHgzys tboDZvVVjfSecEGqevxps79znmAHa7Ba+zJyGmv+ANI544RT2y62nKVcKied18g0Ni HzpjzV4PJKDmWgiCk0xrVI48O7aBt+7OxYLCsnlE= Date: Mon, 1 Jun 2026 13:02:59 -0700 From: Andrew Morton To: Oscar Salvador Cc: Dave Hansen , Borislav Petkov , Karsten Desler , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] arch,x86: Skip setting align_offset for hugetlb mappings Message-Id: <20260601130259.08e03bd738cf40dfcd9744d5@linux-foundation.org> In-Reply-To: <20260601125015.216110-1-osalvador@suse.de> References: <20260601125015.216110-1-osalvador@suse.de> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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-Transfer-Encoding: 7bit On Mon, 1 Jun 2026 14:50:15 +0200 Oscar Salvador wrote: > On x86, arch_get_unmapped_area{_topdown} set align_offset in order to avoid > cache aliasing on I$ on AMD family 15h when 'align_va_addr' is enabled. > Prior to commit 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags"), > we did not have to worry about that because hugetlb specific code did not set > align_offset, but above commit got rid of hugetlb specific code and started to route > hugetlb mappings through the generic interface. > Doing that has the effect of handling non-aligned hugetlb mappings to userspace, > which is plain wrong. > > So, skip setting align_offset if we are dealing with a hugetlb mapping. Cool. > Fixes: 7bd3f1e1a9ae ("mm: make hugetlb mappings go through mm_get_unmapped_area_vmflags") > Reported-by: Karsten Desler > Closes: https://lore.kernel.org/linux-mm/20260527143643.GO31091@soohrt.org/ Ah, there it is. "the kernel later BUGs". We'd prefer it not do that so I'll cc:stable. Thanks for including the link. And thanks Karsten for reporting and testing. > So, let me say two things: > 1) Karsten tested below patch and reported it was working fine for him. > Did not stamp his Tested-by though, because it was not explicitly provided. This often happens - testers (well, confirmers) don't formally add the tag. Often these people aren't regular kernel developers and simply don't know the conventions. But if I see that email, I'll add the Tested-by: because that's what happened. > 2) This is a hack, I know, and I should probably be flagellated for this but > since this is a regression, I went for the quick/easy-to-apply fix, so it can > be easily backported. That works (the patch, not the flagellation). > Having said that, I already made my mind to fix this in a better way, which would > involve getting rid of hugetlb-specific code and do the masking off as we do for > THP, but for that I need to refactor the code and that would not be so easy > to backported. Just so you understand the reasoning behind. Great, thanks, flagellation is excused.