Re: [PATCH 06/20] x86/msr: Standardize on 'u32' MSR indices in <asm/msr.h>

[H. Peter Anvin]

On April 9, 2025 11:39:41 PM PDT, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
>
>* Xin Li <xin@xxxxxxxxx> wrote:
>
>> On 4/9/2025 8:29 PM, H. Peter Anvin wrote:
>> > On April 9, 2025 8:18:12 PM PDT, Xin Li <xin@xxxxxxxxx> wrote:
>> > > A question NOT related to this patch set, the MSR write API prototype
>> > > defined in struct pv_cpu_ops as:
>> > >     void (*write_msr)(unsigned int msr, unsigned low, unsigned high);
>> > > 
>> > > Will it be better to add "const" to its arguments?  I.e.,
>> > >     void (*write_msr)(const u32 msr, const u32 low, const u32 high);
>> > > 
>> > 
>> > No, that makes no sense (it would have absolutely no effect.)
>> > 
>> 
>> For the API definition, yes, it has no effect.
>> 
>> While it makes the API definition more explicit, and its implementations
>> for native and Xen would be:
>> 
>> void {native,xen}_write_msr(const u32 msr, const u32 low, const u32 high)
>> {
>>     ....
>> }
>> 
>> not worth it at all?
>
>No:
>
> - Using 'const' for input parameter pointers makes sense because it's 
>   easy to have a bug like this in a utility function:
>
>	obj_ptr->val = foo;
>
>   this has a side effect on the calling context, spreading the local 
>   rot, so to speak, corrupting the object not owned by this function.
>
> - Using 'const' for non-pointer input parameters makes little sense, 
>   because the worst a function can do is to corrupt it locally:
>
>	val_high = foo;
>
>   ... but this bug won't be able to spread via corrupting objects 
>   through a pointer, any bug will be limited to that function.
>
>So neither the kernel, nor any of the major libraries such as glibc 
>will typically use const for non-pointer function parameters, outside 
>of very specific exceptions that strengthen the rule.
>
>Thanks,
>
>	Ingo

And even so, there is no need to put the const in the prototype.