From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0889D3B389A for ; Mon, 20 Apr 2026 13:36:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776692181; cv=none; b=oHPQZKguXOZ0PWP5+5AIhyRFWjlo0O/32pOLztPagszflHnCr3iU++dGRIjtOWRhca/by2T0a1Ny9e56uhEHtq55lUc1rKo8xh2RrOc45BxFsus7UYZY8CKx1saReHdmYpRIcG+yjwF3nujw9iV/YcQyndiFQQgX6FLy27YFosI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776692181; c=relaxed/simple; bh=/T9u1OBu3RnPmdffOOjLVw5WQiCkhk8xPbI9fHnomtk=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=GDg3g/+kxu4wMOiQFOjNkrWdlAPx3SzNu/7/9YFc7njeeGFrTL4G79NDXBL24F29OaQIXEcs98f0+xLJMvgxHRh+uGhKtayoac19TW5Ih1LJMdJ5jDPt+Vc7N6wMxcUuHRfnxGQHUuuj/gzhFhaVmeO9oXTY4ffCRMhojZm1MwE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=KDmE0a1L; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="KDmE0a1L" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-c79744a2d99so1084817a12.1 for ; Mon, 20 Apr 2026 06:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776692179; x=1777296979; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=2icCSdhtFYr6JZTgZwrOHg4sAd4pPViB0mMNXcuFYXI=; b=KDmE0a1LvSu7cccqq4faL+8E+sMwwG+HJOn6hLcTbOQUaV3A0ZX7lfNKNE/vf+LTWX J3fUYSY+XxT7ACFuiM4s9UAg1SOox7+WDCoGlkG+qaGe7GZFmMBu6vu4QlCt4ZMeWr8b jaliuI+iJUUoTbyPUyuPmcr2otj8nzOZOjPgDpDg65TYw5Cxmcj9+DvHX7f9qV8vNZO2 PpkDN/HlcdKTpRgrHD8xgMCDSFm90IsgkujcIwtwtQoKuAyR52WkDsmIfsZVZrOqI+Nj kbzrb22+QBFW63bR/7weXW7P1PbrU8io8VGeA4VciExRC+709O3zbwMGAkNVAe9DbwEV bnqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776692179; x=1777296979; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=2icCSdhtFYr6JZTgZwrOHg4sAd4pPViB0mMNXcuFYXI=; b=EtFRHwSaQhGzr3bLseTIpXBsOUBsxhw2UrtxLF95DoQRTTG4MvnpMOA5jf1D/DXX72 mCWaNsj9uzEl7DLYZoK/8T7aAiLMA3Uo2R7uQInVvy5MuTWQCZUHSVUODMkT3zlXgRKS hxrHNveBpzO88+KzoybB8r+a/NtlMIwmrlLAjLb7ms7B0zn7F84Oi5QB23LvtMqmDWRw blloG3CwruZu05pHcoQlTeQ1Q59ucDQFi8TXp0yyMam0Y5fgPmMZVtw9mQCHEWsWvKng UmTHOYMGmNeXVaf03O457T4En05T9+MKM7jXdxFH3z4jLa0sFlbRB0JJOzvtJViIEHrc nkRg== X-Forwarded-Encrypted: i=1; AFNElJ8nFtb0wvpOrx0UYuSxSvMFjEdIu8JC+VBhVUMq8mlGEZhqGFXMQKbiGt5fs03DrGf8NpFZYgHbJxIpzLc=@vger.kernel.org X-Gm-Message-State: AOJu0Yw9bTDgjKk0rcqhnTIafokN8dJyu32P2SoRtIYivmxCtWAwNeW3 IGPXLQaTQ/uncf6MTEtSWUqD0lNniXuZ2zSM8bc2OD8VjJXmq4wjjJC068FrbkyPxKHC9lPpoPK LnreTsA== X-Received: from pgch35.prod.google.com ([2002:a05:6a02:50a3:b0:c79:83b3:cdf8]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a20:eec9:20b0:398:6ea8:21d2 with SMTP id adf61e73a8af0-3a08d732f3cmr8611429637.19.1776692179130; Mon, 20 Apr 2026 06:36:19 -0700 (PDT) Date: Mon, 20 Apr 2026 06:36:17 -0700 In-Reply-To: <20260420131020.GI3102624@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260420091634.128787-1-jgross@suse.com> <20260420113512.GG3102624@noisy.programming.kicks-ass.net> <74aa6707-356f-40d4-8611-5f6d116855ac@suse.com> <20260420123352.GH3102624@noisy.programming.kicks-ass.net> <7078f664-719c-42bc-9eb9-d6bc9ff1f57e@suse.com> <20260420131020.GI3102624@noisy.programming.kicks-ass.net> Message-ID: Subject: Re: [PATCH RFC 0/6] x86/msr: Rename MSR access functions From: Sean Christopherson To: Peter Zijlstra Cc: "=?utf-8?B?SsO8cmdlbiBHcm/Dnw==?=" , linux-kernel@vger.kernel.org, x86@kernel.org, linux-perf-users@vger.kernel.org, linux-edac@vger.kernel.org, "H. Peter Anvin" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Arnaldo Carvalho de Melo , Namhyung Kim , Mark Rutland , Alexander Shishkin , Jiri Olsa , Ian Rogers , Adrian Hunter , James Clark , Tony Luck Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Mon, Apr 20, 2026, Peter Zijlstra wrote: > On Mon, Apr 20, 2026 at 03:01:31PM +0200, J=C3=BCrgen Gro=C3=9F wrote: > > On 20.04.26 14:33, Peter Zijlstra wrote: > > > The only interesting question is what to do with the 'safe' aspect. T= he > > > instruction takes a fault, we do the extable, but rdmsr() above alrea= dy > > > has a return value, so that can't be used. > > >=20 > > > One option is to, like uaccess and the proposed overflow, is to use > > > labels like: > > >=20 > > > val =3D rdmsr(msr, label); > > >=20 > > > And then, even though the wrmsr*() functions have the return availabl= e, > > > do we want to be consistent and do: > > >=20 > > > wrmsr(msr, val, label); > > > wrmsrns(msr, val, label); > > >=20 > > > rather than be inconsistent and have them have a boolean return for > > > success. > > >=20 > > > What am I missing? > >=20 > > I like the idea to use a label, but this would result in the need to us= e > > macros instead of functions. So this is trading one aspect against anot= her. > > I'm not sure which is the better one here. > >=20 > > An alternative might be to switch rdmsr() to the interface used by rdms= r_safe(), > > i.e. let all the accessors return a bool for success/failure and use a = pointer > > for the MSR value in rdmsr(). >=20 > Yes, either way around works. Perhaps that is 'better' because mostly we > don't care about the faults since we've checked the 'feature' earlier. >=20 > Its just inconvenient to have return in argument crud, but whatever ;-) Why not do both? There are definitely flows where one is obviously more re= adable than the the other. E.g. if the RDMSR is being fed right back into a WRMSR= , the out-param version requires a local variable. And it can be visually jarrin= g if the surrounding code is a bunch of "val =3D xyz" expressions. On the other hand, the outparam with a 0/-errno return can be very useful t= oo, e.g. when wrapping the RDMSR in a multi-expression if-statement: if (rdmsrq_safe(MSR_IA32_CR_PAT, &host_pat) || (host_pat & GENMASK(2, 0)) !=3D 6) { As it avoids having to assign with '=3D' in the if-statement, and avoids ha= ving to define a label. It would be trivial to add a wrapper around the label version, the hard par= t is just the naming :-)