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 CC42AC021A4 for ; Thu, 13 Feb 2025 21:18:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 349AD6B0092; Thu, 13 Feb 2025 16:18:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F9826B0093; Thu, 13 Feb 2025 16:18:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1C1FE280001; Thu, 13 Feb 2025 16:18:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id F2BB86B0092 for ; Thu, 13 Feb 2025 16:18:01 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9D842B2139 for ; Thu, 13 Feb 2025 21:18:01 +0000 (UTC) X-FDA: 83116183962.14.77C2DD0 Received: from mail-lj1-f182.google.com (mail-lj1-f182.google.com [209.85.208.182]) by imf03.hostedemail.com (Postfix) with ESMTP id A644420008 for ; Thu, 13 Feb 2025 21:17:59 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eZbv8jSE; spf=pass (imf03.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739481479; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=F7rtUO+sYK4IquZRwkwuLyyE8F7H0KKEoRfcHPzdTk0=; b=6KmvMVfjHdSGlOqjO2eoGlyPH7q7vg7EjK7k4Tq/eSUrgUKFkMZqeqzM2fP/szPbuUs2iZ g4eN9ck02DFxtf399LflL60jk3aZPOlfGic4vojFWgW0s8lPLbTZbYIMdD6CfXYvptC/Cm VWVCqmEQyhzx9IzkIR1XEExRr+wXi1E= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=eZbv8jSE; spf=pass (imf03.hostedemail.com: domain of ubizjak@gmail.com designates 209.85.208.182 as permitted sender) smtp.mailfrom=ubizjak@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739481479; a=rsa-sha256; cv=none; b=o+hJh8/kY+qk1+TrCd4Uzf+wNFEPqptIVbQQVv1BBydZebIVUPb2JotsORSh1Cq6AEG0pC FvV0qClDgKuPXnuxqQcuIuT6tWajQvyX5tKJ/aWU8SiiPJ6LKOqcDkjldayqFVel41iNrc qdPv0ePCxOSxOcpqg/ebQdms+5rMbps= Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-30738a717ffso13607591fa.0 for ; Thu, 13 Feb 2025 13:17:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739481478; x=1740086278; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F7rtUO+sYK4IquZRwkwuLyyE8F7H0KKEoRfcHPzdTk0=; b=eZbv8jSEa9o8xxhtSE2fi+RBavhv02akc3EIiHkV38l3YRhjXuWEIE7L+CJKjdYu1g WwnIsLmVK3hAXFxkovKSOUZP5pxCVXL2rU8XUmRM94c3XAgBqaME54RibHN2pmwne6Cl LBKJl/CezGUK9Pq4wjrSIKHjX4NTcp2Jlb8PUIbLC41HssXDC6ogv5UCkaBfC/ZHxiCE 3ec4oHlRlqhFh9+w4JRTFuC33DRkRF/GzzaoCcYyZqR2913DHb8S7Feomt4y30pKGG3u jIpzJDVhww+Xc/XjjQ6YQNajiUZWIpqVztHfhZNGvAh2H24u3Ux9FagC/XttdEPFYq81 jKLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739481478; x=1740086278; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F7rtUO+sYK4IquZRwkwuLyyE8F7H0KKEoRfcHPzdTk0=; b=c1srFa7QpOhpGNC+W2NRhDx4bwU5GnQuWH7hAiEZoZ2Sh8BCT8Um+WXdFFG+t/ND43 7zGKgP7gnxrasHNuf3PSWr1x59qq7qP67bEbhGOxKXu6OxQ0CFZe2azG4WqmsU72LuQt KAVlAB+9qbCPhgvVGQhAG6rs6Wj0DWZgBCHJxG22cDbYwffpaqyKCOim6wARbgDSZum1 ZXgvi4xXxbLlar26tDTazUI7tzUrJb8c+fIyPcbRwWC5Ex3R+q8ioeLpRHg8KXCu1ses 0ORsOPYeCJ4nLc2CiOa7SlyVcYcXnBrb5XC8vd0qwTPKMLhSU/XG48SZdXmY5tUV6j6y NgZQ== X-Forwarded-Encrypted: i=1; AJvYcCU5tnplvXRP5aD5lYtjiu+Rx3dxKasTUQ5RCFeLLaK7n4qJvgw82/AJnZbkoKHrM9y0FGZ3WJzdrA==@kvack.org X-Gm-Message-State: AOJu0YwSMc8vHmhSi7Et0wlsjDTZR3t7os5y68/RJHdqxTHg4gPBDDfY x4Ma7rsXkLWUSBw8kZyy7tQuUeAftS6BCwiKIpMMgHA2yMosGybY6Dq1HiNLPt/cznr8HBeDlG0 h5zoCKiPOJm0qt03V3jm/zsDGSDs= X-Gm-Gg: ASbGnct4tnkRAUkFsBgjhGo1rASF4/6lSZNdyanBjIkfvsCGQs7Bypt7dx14wXGvBhJ eQQODQool5pfBMcT33x6T8VOLERBwlVWp8DTyrQu3SWQ+wxU/NZDCaFfweV57pYKVcIM1hovI X-Google-Smtp-Source: AGHT+IEvnBZVnHY++r9w+H+F+AX3dUBv/bc1/Z12RQwcp1pcz6fCp3zs5GOQA5mkjUz00oj0YxLPC0rUTqCIIzHMRno= X-Received: by 2002:a2e:a909:0:b0:307:e302:a34 with SMTP id 38308e7fff4ca-3090500af87mr36218881fa.20.1739481477421; Thu, 13 Feb 2025 13:17:57 -0800 (PST) MIME-Version: 1.0 References: <20250213191457.12377-1-ubizjak@gmail.com> <04adffd9-2900-4cdb-a557-1c486a87b522@intel.com> In-Reply-To: <04adffd9-2900-4cdb-a557-1c486a87b522@intel.com> From: Uros Bizjak Date: Thu, 13 Feb 2025 22:17:45 +0100 X-Gm-Features: AWEUYZlNLo7NNqMCySZKpk_F4CuhEY_hr8veiHVSaSPXExnCLmkQMrsiv5cCk1s Message-ID: Subject: Re: [PATCH RESEND 1/2] x86/locking: Use ALT_OUTPUT_SP() for percpu_{,try_}cmpxchg{64,128}_op() To: Dave Hansen Cc: x86@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , Dennis Zhou , Tejun Heo , Christoph Lameter , "Peter Zijlstra (Intel)" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: A644420008 X-Stat-Signature: z19r4ceb1izftwnrjfrad6e7iet7kosb X-HE-Tag: 1739481479-760927 X-HE-Meta: U2FsdGVkX18tN1DcvfspFkbHcwTA11UJgQ7tk4NOgXywOeCpgnqfrf6ysD53k+gsqZMJmCPdHodj4xTOSpFusK33MBFNK3+YybewQvFZwNSFrsKdttgwCQrAXMIBidQYGq1ixWZZaT3NhUcnkkVHLuAONc7bm8NmupE2KhM8sKrQUZ3tPEpyJgA1Xc03McPz1q2ddFbIwKCA7wdcPg3HbUGZh859Drw31pD9Hz+5lq4tSyFHszxTIQktCJbND0FhGZ0UMy7/lxe3c4otKvx7epHL0uig7Mu67IPjXv4IF2V0iH8cKohott7m/6kFv5doLs0OJoAkcd7sa/Y0JgkbMlY8UVsSKO6tB+y9i0lLnYVjarwuiFExEmKSPYxa/OuwyliLXHI9SJz0XrQH8xzc+e3q4yw8rzEVCWmKJ/0Di30L5Uiu2UXxX/ijWp83gLbe1EyblG2W+fDWB3mIL93m3w9wEt5YBBs7EVpxvtQMOIi8nZmIi/3TyXJC2rpFr7psysi9g5FRiEh4gY+MG7IaqSsCPoOS2ZObTeqwOakOc2K9QwR5SUeJAHmLEKWneDYfq7YWKZX3RMOqu7Kgw9B9VjMljrApeEJas05Zd5FcQI7LSgAxh6HmwbMYFf2P66dBu3EgmTfTl/ylsdjt74xYGIL3DXEo3qGHy2SSFmNDPozFAphwoyxgzb7lkaB+7ndtu+LTzYmj2JvBw9jaGsr5S7j+ArMyo9/BusTLS4ZgMGtc7NtS1Ocx2eIArBHrVRpV1BD9/Sa5Ove6WYov4vKpMyUQJgnn7cXj+bfRbH+k/XmIxs+W3gxfuSOKNpFRz9ZMeWlFcVWT/WfLI684gC7WpuXDCLTFZENl826Yc0ZJwWCZ4Ep7UTF/t/PNrZpOPtrwgjJSk9znqN6UbHHjh7UAgAK3VsZa8xhZsYrGMYLyH5CkqcO/vYuVgfKnPEO9/SYFFIEs4n7/rBSgd5hJF7B mKxkrPHd k2hDTBAdKZimEW4pXmDTDkmrnnipjpC+PkkIPsAnW5hvdDMu8aqXcZYh2lhcVI/NmX8xVcVJPAKGwViv4Mb8xsG25Nae2CP4P0fPx43PCyAaC23gpkvkBbnWK6j7UgQ2cNHdu1OvhsHVZ9KppbVLHioEP/k3kqFmxqnQFYdujPyXEkJRpVSz9jX+Ol5lW2paFwT7XaJgdvKFdJDSyzqVmf/YLAgy9jC4k9U69haBpAizCBRGaW2ZecgJEQ1TQ5zPI7RsGrFU5kVWxY0Qe/Q5rOSH+TWMBW5Ku9PXGKh4TLo0/JoukrYg64CaSuUWrt3vA5VtZIk5x29i2APMiRR6+q3EYijrsIeF6Vw8YTgH58pKCo6CKPRKlFNQnzf24hoWH03Umto00KDm1C/k= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000320, 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 Thu, Feb 13, 2025 at 9:43=E2=80=AFPM Dave Hansen = wrote: > > On 2/13/25 11:14, Uros Bizjak wrote: > > percpu_{,try_}cmpxchg{64,128}() macros use CALL instruction inside > > asm statement in one of their alternatives. Use ALT_OUTPUT_SP() > > macro to add required dependence on %esp register. > > Is this just a pedantic fix? Or is there an actual impact to end users > that needs to be considered? When call insn is embedded in the asm, then the compiler doesn't know that due to call insn asm now depends on stack pointer or frame pointer, so it is free to schedule the instruction outside the function frame prologue/epilogue. Currently, this only triggers objtool warning, but if we ever compile the kernel with redzone (IIRC, it was mentioned that this is possible with FRED enabled kernel), the call will clobber the redzone. Please note that alternative_call() family of functions, __alternative_atomic64() and __arch_{,try_}cmpxchg64_emu() all use the same macro exactly for the reason explained above. OTOH, all recent x86_64 processors support CMPXCHG128 insn, so the call alternative will be rarely used. > Basically, you've told me what the patch does, but not why anyone should > care or why it should be applied. This is actually explained at length in the comment for ASM_CALL_CONSTRAINT, which ALT_OUTPUT_SP macro uses. Uros.