From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id ACFF7C83F09 for ; Wed, 9 Jul 2025 09:52:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 433F86B009E; Wed, 9 Jul 2025 05:52:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3E2D16B00BA; Wed, 9 Jul 2025 05:52:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D1E26B00BB; Wed, 9 Jul 2025 05:52:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 15A196B009E for ; Wed, 9 Jul 2025 05:52:05 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B3ED51A00EC for ; Wed, 9 Jul 2025 09:52:04 +0000 (UTC) X-FDA: 83644260168.12.83308C5 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf16.hostedemail.com (Postfix) with ESMTP id 49A9A180008 for ; Wed, 9 Jul 2025 09:52:02 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IEWkcPKQ; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752054722; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=l3z9m1ga9qqMcsb3+15z1baYDLQurVBnG98OgcMs6no=; b=2n5Wt/B2BhHYgFhr2ECWQWAzxuz2MvYZDHXoNUHF1xamuK79B/IhBD2CHKynx+a8S3l4fX m9AWYh3it76p7f71vccGrWGjMiaLZshRRV1XzmGnE2Tc7F0boQJu8T88uHl9ddFE4/I3VT GE2ZyE53re+WcXq1ClOjmACFyNGr2mM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=IEWkcPKQ; spf=none (imf16.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752054722; a=rsa-sha256; cv=none; b=jrWQ6ZNRcVr2UZVLdHwa58QDAl2UOfn2OIXv+X05qA+5xmreTizv5165ox7wxVCrJzjHBd BMBMlQkrG1SqwQlf1bGwNuc7Qh7iq0Duvs6GXaVtVt8Q3JR9qSn1faim4Fd59y0K7yU1bK LtotmUEVlQiXe4a5YNYbS0ZKT0hEYU0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1752054722; x=1783590722; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=VBcLNsfeXZegl7COkVWcleDsuUcTK+n6RSJLnd/zTo8=; b=IEWkcPKQDBa9y9In0DdqmqSwFSlQkVfEboIbZu8qIKFaNmIEz8wRZYAv xddng1bKO8f60Yen8ncx5UxDcFxxygDAIa91SNkeZsIJM03O64QS4HMyE qXE0UUox7wixeiN1ZcUYJo+MPR/fvIjSRYjg8IAW0RyPwMfBz2OBZAHPg O4kP+o30u7EzBWPG2X28OEj6BASoUyD8lzemd3+JAeUuAmsQd+XmxVAeD P6QmS3zCNQHejJio4b0ano43Y2dxSbUtS2y/pxnRKUZox+XagEZXURJ1s n6DyxBLK6OOk5eKe7qvSLLqhXAMqSADM7ZDppur8bRwVfneUkJ42MIZKL w==; X-CSE-ConnectionGUID: UbiUvv1URTObE6mpZFgPXg== X-CSE-MsgGUID: sTCxSTiRQlKYZFigRAO4CA== X-IronPort-AV: E=McAfee;i="6800,10657,11487"; a="76856434" X-IronPort-AV: E=Sophos;i="6.16,298,1744095600"; d="scan'208";a="76856434" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jul 2025 02:52:00 -0700 X-CSE-ConnectionGUID: 3utUuKnLRke5/wsgphZJPA== X-CSE-MsgGUID: lU1aHZW8SnK6zQVMF9uggw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.16,298,1744095600"; d="scan'208";a="156061509" Received: from black.fi.intel.com ([10.237.72.28]) by fmviesa009.fm.intel.com with ESMTP; 09 Jul 2025 02:51:50 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 75AB71B7; Wed, 09 Jul 2025 12:51:48 +0300 (EEST) Date: Wed, 9 Jul 2025 12:51:48 +0300 From: "Kirill A. Shutemov" To: Geert Uytterhoeven Cc: Sohil Mehta , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Peter Zijlstra , Ard Biesheuvel , "Paul E. McKenney" , Josh Poimboeuf , Xiongwei Song , Xin Li , "Mike Rapoport (IBM)" , Brijesh Singh , Michael Roth , Tony Luck , Alexey Kardashevskiy , Alexander Shishkin , Jonathan Corbet , Ingo Molnar , Pawan Gupta , Daniel Sneddon , Kai Huang , Sandipan Das , Breno Leitao , Rick Edgecombe , Alexei Starovoitov , Hou Tao , Juergen Gross , Vegard Nossum , Kees Cook , Eric Biggers , Jason Gunthorpe , "Masami Hiramatsu (Google)" , Andrew Morton , Luis Chamberlain , Yuntao Wang , Rasmus Villemoes , Christophe Leroy , Tejun Heo , Changbin Du , Huang Shijie , Geert Uytterhoeven , Namhyung Kim , Arnaldo Carvalho de Melo , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv9 11/16] x86/traps: Communicate a LASS violation in #GP message Message-ID: References: <20250707080317.3791624-1-kirill.shutemov@linux.intel.com> <20250707080317.3791624-12-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 49A9A180008 X-Stat-Signature: 8dwbbdjsx8t4z4y7of9yoepdgphqmsyx X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1752054722-449257 X-HE-Meta: U2FsdGVkX19tmIOkmNVApSCec3Bi/PQtch21DBt+xg3IEDsi2V9x+eM70X+xtJ18rBR+aDtGvNHYehBtv5wGyyqTWPsOkJR2IcRWjKmEbZQaAR8D8jzcFptljBWYwGbTFdMAkt8eEHpctQr9B1Vn6slB+I/KNKtWooN9D3YzlFopDZD2KnEBRx4cfv5wIVzTae3hpSGIkS9a9hL5SJqkFmayefdzpOnDR54vyf23bo6zoRRvO6diMSqc7LxWl+5bysIV9yF9r8OXOI5E93FEEY/NIqSjY6QJyMfqwmj+I6VZFBybTtV1LSpB38Of1aIC67s8S1rDcw+9I4J3xgac4Ng+Q5q3j1C4S9nZK+za86Xev3SIyeBwqKukK0Biaxx5MlRvXU8v4tY70u09S7Qxe1/Eg8GJvWKhpu0bTG+hkx1D6IqNX9EI1x/flEwg5nH5yYobKZ4hYfd8OYBIf/CmYZ4fpMELUIqJY0aJFHBU0ytoD8cjTkw1N2NNtVcQBx9MIRaY1KbZKKYU12++2X+v68iD5B0AW8mF8HXuOMbJxEWuFfH+srWNp2VLiYl4VX83cADejoSok+/72XMllWgQ7I/vJ4QS0mwmcMjFVjPdNO2dlR1n0kjCysJ9yMyk6hc7oTwJ2NuomDUn4CQ3oWqF3nYeUVogA2/aeozM2k2ZCHxAUqX425eZP0FIcPvXzckhn/Q5wpqdCpREFxi5Nk5ougySqvodGqviuqfBH4w7nplFU6wgQ92s+sIeNBA8C/wgRtrBKXjRWTpZNf5wsOWnuQCCkhOV8xZTlK1SdyFKf6Jk5iRIOdsK1/kCEunNuPBfRNjI0swHK3EnxZGf8RE0HEKSaMHY0mij7cv2ymKCYiMHuQY0uqbQ5/X3y1CuONoaRdI52R2Cs0jEOMSk3dT6hyEFLsAKquUTOGat3AaBBqwz054M1FDdyA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Jul 09, 2025 at 11:36:27AM +0200, Geert Uytterhoeven wrote: > Hi Kirill, > > On Wed, 9 Jul 2025 at 11:31, Kirill A. Shutemov > wrote: > > On Tue, Jul 08, 2025 at 07:40:35PM -0700, Sohil Mehta wrote: > > > > @@ -664,14 +673,23 @@ static enum kernel_gp_hint get_kernel_gp_address(struct pt_regs *regs, > > > > return GP_NO_HINT; > > > > > > > > #ifdef CONFIG_X86_64 > > > > > > Might as well get rid of the #ifdef in C code, if possible. > > > > > > if (!IS_ENABLED(CONFIG_X86_64) > > > return GP_CANONICAL; > > > > > > or combine it with the next check. > > > > I tried this before. It triggers compiler error on 32-bit: > > > > arch/x86/kernel/traps.c:673:16: error: shift count >= width of type [-Werror,-Wshift-count-overflow] > > 673 | if (*addr >= ~__VIRTUAL_MASK) > > | ^~~~~~~~~~~~~~ > > > > __VIRTUAL_MASK is not usable on 32-bit configs. > > arch/x86/include/asm/page_32_types.h:#define __VIRTUAL_MASK_SHIFT 32 > arch/x86/include/asm/page_32_types.h:#define __VIRTUAL_MASK_SHIFT 32 > arch/x86/include/asm/page_64_types.h:#define __VIRTUAL_MASK_SHIFT > (pgtable_l5_enabled() ? 56 : 47) > arch/x86/include/asm/page_types.h:#define __VIRTUAL_MASK > ((1UL << __VIRTUAL_MASK_SHIFT) - 1) > > Given __VIRTUAL_MASK_SHIFT is 32 on 32-bit platforms, perhaps > __VIRTUAL_MASK should just be changed to shift 1ULL instead? > Or better, use GENMASK(__VIRTUAL_MASK_SHIFT - 1, 0), so the > resulting type is still unsigned long. Making __VIRTUAL_MASK unsigned long long is no-go. Virtual address are unsigned long. I guess GENMASK() would work. I think re-defining __VIRTUAL_MASK is out-of-scope for the patchset. Feel free to prepare a separate patch to do it. -- Kiryl Shutsemau / Kirill A. Shutemov