Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32;
Date:   Thu, 16 Nov 2023 00:50:46 -0500
From:   "H. Peter Anvin" <hpa@zytor.com>
To:     Michael Roth <michael.roth@amd.com>,
        Dave Hansen <dave.hansen@intel.com>
CC:     x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        Joerg Roedel <jroedel@suse.de>, linux-kernel@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH_v2=5D_x86=3A_Ensure_input_to_pfn?= =?US-ASCII?Q?=5Fto=5Fkaddr=28=29_is_treated_as_a_64-bit_type?=
User-Agent: K-9 Mail for Android
In-Reply-To: <20231115224231.xmxfktqcb4sls3fb@amd.com>
References: <20231115201431.820278-1-michael.roth@amd.com> <e42524f9-87ef-47f4-9c79-bc06b4d71a58@intel.com> <20231115224231.xmxfktqcb4sls3fb@amd.com>
Message-ID: <CF5E01C9-3EC6-422C-BAD2-B8732E6FCE77@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On November 15, 2023 5:42:31 PM EST, Michael Roth <michael=2Eroth@amd=2Ecom=
> wrote:
>On Wed, Nov 15, 2023 at 12:48:58PM -0800, Dave Hansen wrote:
>> On 11/15/23 12:14, Michael Roth wrote:
>> > While it might be argued that the issue is on the caller side, other
>> > archs/macros have taken similar approaches to deal with instances lik=
e
>> > this, such as commit e48866647b48 ("ARM: 8396/1: use phys_addr_t in
>> > pfn_to_kaddr()")=2E
>>=20
>> Gah, I really hope nobody is arguing that for real, or is even thinking
>> about this as a valid argument=2E
>
>Not that I'm aware, but I did have my own doubts initially, which is
>why I thought it warranted a note in the commit just in case it came up
>from someone else=2E
>
>>=20
>> The helper should, well, help the caller=2E  It makes zero sense to me
>> that every single call site would need to know if the argument's type
>> was big enough to hold the _return_ value=2E  This nonsense can only ev=
en
>> happen with macros=2E  Type promotion would just do the right thing for
>> any sanely declared actual helper function=2E
>
>My thought was that it is easier to expect developers to know the pitfall=
s
>of bit-field types, since it is universally applicable to all C code,
>whereas expecting developers to anticipate such issues when writing simil=
ar
>macros is potentially harder to enforce/audit and could lead to similar
>issues popping up as things are refactored over time and new macros get
>added that don't take such usages into account=2E
>
>But neither argument seems to hold up in reality=2E Experienced developer=
s
>obviously do fall victim to the subtleties of of bit-field types, and
>kernel devs obviously do tend to address these instances in more robust
>ways based on the various pfn-related macros I looked through=2E
>
>-Mike

Now, if you are doing a cast, you are making the macro unusable for assemb=
ly anyway; any reason not to make it an inline function at that point?