From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) (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 2C5BD1F12E0 for ; Tue, 25 Nov 2025 13:48:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=65.109.113.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764078505; cv=none; b=KNXbrKpjycra0uJp1xP4Tc4a1OnvruZAvG+SX1qC4QZRwAO4YNhRgKbJWnC1kvFSjqKTxtD2rqbQcMbtlSSy3H+L4eNyTxgMw5EZwL8X3om7I4rijAYcPX/6TBqGDgEW5xY5x9GQIi9XhOih1xRarDAbR2oKOzfJzWn3rcar03w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764078505; c=relaxed/simple; bh=AComPRZV1ohSeq0Iiva0SAck2yDMoRGINoywIjlJtUE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=F5C2tbY97pR1eh2C/QlX5wRCZQR4jN+VJGPQTgURpTvCvy2+WfanXmvAztjzfOVVaW8Zkblz19wsgaLuatnGHPjWMwn7qnZvLAY8re1UFPlTLG45lGvOXsKaXZy4sfb/dtNL0OvDjPEDB1hzJLrStVagDPww8lAzMoaq5zCCP+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de; spf=pass smtp.mailfrom=alien8.de; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b=KA6X2gA3; arc=none smtp.client-ip=65.109.113.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alien8.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b="KA6X2gA3" Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 04C1640E016E; Tue, 25 Nov 2025 13:48:19 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=pass (4096-bit key) header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kh811-bYK1OA; Tue, 25 Nov 2025 13:48:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1764078493; bh=KHz/4vbgS6sTT3o3BvksbAxXi7O2n+1XRJhlBaRAqSI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=KA6X2gA3VhjJRhvRHvwBHXP/jtHRH7U2BPitygYsS0EWwts1kzF84jsAgZGzYlKff S3e64yn40czjGuTnHbutythMrFYbXsq1cM/bhMiTZpCiNRZS5XXUklnyN8uU8w8CAT tV9tB9BHNcNkVskOD1SrAD5T50bTvZpS8Ke932FLzQb7PmjgEHvavujKEvJAkYbsMq tdFVCuO/paFvPo77JaQcbAQ3I68njbqAiZTAOjRxg7ykuY3f3thrI1QgKMyU+UzOYf bzO85ajCOaAP6hMxPovIz9izPK2Oks5TpMM1DPnKLvs1eljAloIO7CHV2zrTT6H+a1 pH2DnoynIS8T4UJwArTcaqw1UGy3Sl9qZptloMWZqMmbXOrpPC7IvmG6eGLTAQDAKB +e4pCFypfJFHPhyaVaWPKQSEYbU3OOZIhub7uHabqTPHgLCkya6FuXvUew2oTi4ob/ Tc1gJ/EgZ13SgpXbbJXPBSXBDtxrWjsuzv0VcvSPxPi1PwbDtNM6Owe5yKKCgedh83 AsFLvSVR5nzOqH0uDU4gCYqpkNzftJ2aNxFMSo4dz1jGXJrmGKFH2Fv/0eOhYSCRAL DafO/QK3DhY/v15yExEy0usZ/koz20Iut3v1vHLifCxrJhypVJToV5//v/UqRE779g nNdKP4+uzSiI6qG/Mfb/1IeM= Received: from zn.tnic (p57969402.dip0.t-ipconnect.de [87.150.148.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with UTF8SMTPSA id 4C30040E015B; Tue, 25 Nov 2025 13:47:56 +0000 (UTC) Date: Tue, 25 Nov 2025 14:47:55 +0100 From: Borislav Petkov To: Ankur Arora Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, david@kernel.org, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, mjguzik@gmail.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, willy@infradead.org, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH v9 4/7] x86/mm: Simplify clear_page_* Message-ID: <20251125134755.GMaSWzi-_vZwdkFcdp@fat_crate.local> References: <20251121202352.494700-1-ankur.a.arora@oracle.com> <20251121202352.494700-5-ankur.a.arora@oracle.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=utf-8 Content-Disposition: inline In-Reply-To: <20251121202352.494700-5-ankur.a.arora@oracle.com> On Fri, Nov 21, 2025 at 12:23:49PM -0800, Ankur Arora wrote: > +/** > + * clear_page() - clear a page using a kernel virtual address. > + * @addr: address of kernel page > + * > + * Switch between three implementations of page clearing based on CPU > + * capabilities: > + * > + * - __clear_pages_unrolled(): the oldest, slowest and universally > + * supported method. Zeroes via 8-byte MOV instructions unrolled 8x > + * to write a 64-byte cacheline in each loop iteration. > + * > + * - "REP; STOSQ": really old CPUs had crummy REP implementations. > + * Vendor CPU setup code sets 'REP_GOOD' on CPUs where REP can be > + * trusted. The instruction writes 8-byte per REP iteration but > + * CPUs can internally batch these together and do larger writes. > + * > + * - "REP; STOSB": CPUs that enumerate 'ERMS' have an improved STOS > + * implementation that is less picky about alignment and where > + * STOSB (1-byte at a time) is actually faster than STOSQ (8-bytes > + * at a time.) Please put here in BIG RED LETTERS something along the lines of: "The inline asm has a CALL instruction and usually that is a no-no due to the compiler not knowing that there's a CALL inside the asm and thus won't track callee-clobbered registers but in this case, all the callee clobbereds by __clear_pages_unrolled() are part of the inline asm register specification so that is fine. Just don't assume that you can call *any* function from inside asm due to the above." > + * > + * Does absolutely no exception handling. > + */ > +static inline void clear_page(void *addr) > { > + u64 len = PAGE_SIZE; > /* > * Clean up KMSAN metadata for the page being cleared. The assembly call > - * below clobbers @page, so we perform unpoisoning before it. > + * below clobbers @addr, so we perform unpoisoning before it. s/we // > */ > - kmsan_unpoison_memory(page, PAGE_SIZE); > - alternative_call_2(clear_page_orig, > - clear_page_rep, X86_FEATURE_REP_GOOD, > - clear_page_erms, X86_FEATURE_ERMS, > - "=D" (page), > - "D" (page), > - "cc", "memory", "rax", "rcx"); > + kmsan_unpoison_memory(addr, len); > + asm volatile(ALTERNATIVE_2("call __clear_pages_unrolled", > + "shrq $3, %%rcx; rep stosq", X86_FEATURE_REP_GOOD, > + "rep stosb", X86_FEATURE_ERMS) > + : "+c" (len), "+D" (addr), ASM_CALL_CONSTRAINT > + : "a" (0) > + : "cc", "memory"); > } With that: Reviewed-by: Borislav Petkov (AMD) Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette