Re: [PATCH v4 01/11] xen: arm: fix len type for guest copy functions

[Jan Beulich <jbeulich@xxxxxxxx>]

On 05.05.2026 12:07, Luca Fancellu wrote:
> 
> 
>> On 5 May 2026, at 10:05, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>
>> On 05.05.2026 10:27, Luca Fancellu wrote:
>>>> On 4 May 2026, at 06:30, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>>> On 29.04.2026 12:08, Luca Fancellu wrote:
>>>>>> @@ -136,7 +136,7 @@ unsigned long raw_copy_from_guest(void *to, const 
>>>>>> void __user *from,
>>>>>> unsigned long copy_to_guest_phys_flush_dcache(struct domain *d,
>>>>>>                                             paddr_t gpa,
>>>>>>                                             void *buf,
>>>>>> -                                              unsigned int len)
>>>>>> +                                              unsigned long len)
>>>>>> {
>>>>>
>>>>> Now that we do this, potentially we could have truncation in the places 
>>>>> where we store its return value
>>>>> inside an int:
>>>>
>>>> Those would suffer from truncation before and after this change, wouldn't 
>>>> they?
>>>> Just that where the truncation occurs does move. I.e. if necessary they 
>>>> would
>>>> want dealing with separately.
>>>
>>> yes that’s true, truncation was already there in different places, do you 
>>> want to deal with it separately so that
>>> we have a Fixes tag for it?
>>
>> I already said I'd like that to be dealt with separately, didn't I?
> 
> I understood the “separately” part.
> 
> What I was asking is whether the reason is that this should be its own fix, 
> with its own Fixes tag, since the truncation predates this patch.

The reason isn't so much the Fixes: tag, but independent issues generally
wanting independent fixes. This also helps with backporting (in general;
maybe not so much here).

Jan