From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (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 5CF4F3612DB for ; Thu, 23 Jul 2026 23:13:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784848435; cv=none; b=LDrDZFiqunmgFoX4XQCUG+ZvqiAvpr9jTJaZy26A+vyOQfQ1Bv1Mira/4rQyQzkK4sKJM3+bbZi/CKeAauhVbC52hfCPTUbNoau42W/2SwyDBkS0MKj119BLwVTS+YdomOO91dXmyvlDB3FP7JjybTBIyP4i17yCPCC+/KvMlG8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784848435; c=relaxed/simple; bh=ku5o+48TavA199v97tQmuE0IH7rLrwOoNlisW01kIW0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=q8h0u/WM1LZtv2IYdm6RzAqu+f2VFWOe6do3f5ysNeJjQrPcjTZyHfsuAtj0DZVRqCu2ALyaB3R/JtqM1xNUyj5JqXPCod3pPgnF0FIc6n8j+WWUbTeT9RMAcjbcUPp7Ijvofgq20CaHA0CsWiWzNpLYTECF8SmDPXnIc8p7UrA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=Mgr/tfdG; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="Mgr/tfdG" Received: from [IPV6:2601:646:8081:7da1:14d6:374d:d1f7:d29c] ([IPv6:2601:646:8081:7da1:14d6:374d:d1f7:d29c]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 66NNCwoN3915882 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 23 Jul 2026 16:12:59 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 66NNCwoN3915882 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026062701; t=1784848380; bh=8PXTFQp+nc5iVg72qAvrsYZWp0ruRgVFKDvX1SpODZA=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Mgr/tfdGvfkXlD4MS+SPjW7hHK1yidys1xkpttHHbJUlxPm7b7xMyRLFnyMHxmYMW 51nrlM9UpGo2LnwQRysOl0IrVAmFvcHWLFQD1xBDpzz9MSWBuly8fp4gLvKn8VK1X3 lJ1KVRbhR5wK+OumlEjGzaXI8U9ReflDqRcaQmUBnyWwdD2GYy0yUrzMKc14YFgHPu D2YjJg9pBDCu7f3skgUYAltAJjuKtM1iHwKMOlLiXTuuL6knxnwaY8PA9IRkNg2tao jGrUiQ7Aiilb1VAFHI/ENrEu91vR36HX89vTrFuhDCwSNDkgTIfPk09woC6yEwOH24 bACxElX0CQXvA== Message-ID: <5e19b195-0ca2-4510-81cb-497b40e4aaf5@zytor.com> Date: Thu, 23 Jul 2026 16:12:53 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7 2/5] x86/asm: add volatile, clobbers and zero-length check in inline memcmp To: Jan Beulich , Mauricio Faria de Oliveira Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , x86@kernel.org, Juergen Gross , Alexey Dobriyan , Boris Ostrovsky , kernel-dev@igalia.com, linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org, Borislav Petkov References: <20260721-pvh-kasan-inline-v7-0-38979a50cef0@igalia.com> <20260721-pvh-kasan-inline-v7-2-38979a50cef0@igalia.com> <20260722170334.GCamD35gwrCng30WH1@fat_crate.local> <0F3A1121-208F-4F71-8C88-BEAE7CB50E75@zytor.com> <4daed8ac-b533-436f-9f86-6d297b87abbb@suse.com> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <4daed8ac-b533-436f-9f86-6d297b87abbb@suse.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 2026-07-22 23:59, Jan Beulich wrote: >> >> Also, this is silly. Instead of adding a whole separate test, just do "test %3,%3" before the repe to set ZF and let the REPE skip. > > Besides this, isn't the function effectively returning bool wrong anyway? This > way you can use it for equal / not-equal comparisons, but not for sorting and > alike. > There is no use case in the early code for sorting, and it seems rather broken to burden the code with that. That being said it probably should return bool explicitly (it makes no sense for the prototype to be different than the internal variable.) We could call it memneq() if someone really, really cares, I guess. The early code is very size-sensitive, so I'm really not fond of the idea of burdening it further. Perhaps something like: A memory clobber is ugly here since no memory is actually modified, although it probably doesn't affect code; "cc" is completely redundant with condition code output operand. static __always_inline bool __inline_memcmp(const void *s1, const void *s2, size_t len) { bool diff; if (__builtin_constant_p(len == 0)) { if (!len) return false; asm volatile("repe cmpsb" : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) : : "memory"); } else { /* Clear ZF beforehand in case len == 0 */ asm volatile("test %3,%3; repe cmpsb" : "=@ccnz" (diff), "+D" (s1), "+S" (s2), "+c" (len) : : "memory"); } return diff; }