[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v4 01/11] xen: arm: fix len type for guest copy functions
- To: Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Tue, 5 May 2026 10:16:27 +0000
- Accept-language: en-GB, en-US
- Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=gmail.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com])
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
- Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6uFyHf5/hq6YqtL7puLplGKtjI5wCkmPtCDmUXyg/2k=; b=D4ZJhB/gTTkVI51m9bPWw8R9uVEDGDOn9SE2/T5ta/1+qsPouJ/UudhNmJDFg7hDNKO0EzICVwDKw+a1vn2xhXRZVeSSNgaOHBINKrZifJYPLr3jgFgjwaQCqtfRCMfSHWawg05nAmaVDkL6jseST0w/yidggwSZWEccd+WNUNKrcGl+Lqq+d+j3IREz210YGN2MZSaFDIBLJjLVH11gElAmybRB8D4PGw9BkjejsCxCrLTYmkrEj806k7vNvAF6fxqSP4HbdVuGrCOmnoZUQCTcMT9WHQAlb0s9R/jyHrzhN1LmWLca4CNAU3s9M0AJll0HbAtW+e3BsfoHQrSgQA==
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6uFyHf5/hq6YqtL7puLplGKtjI5wCkmPtCDmUXyg/2k=; b=awpwRE9iMU/9ZKIoqdrdN7hAp1zUdBbsVeuFyxheMNaAqrggRvkrJf9iW+euAFF2/iFwBkK5gNqgsUY05Q31QTPGHnfoZyDcEm37+4Me9RMdbJFstMgLfJLbzUhXFWvJNofKaHo7IxUxf48HSJgoOfFbDc3C9l+3H1GG/SDG6MQTZbw93SzJZSE8Fs1Ot675UNZhC6qhjPnjLeiPPt1+ajh8RZVGhQJ/+2VBdcIaLz0Rlita0W7WEPFPuF5s4vsGxLObk2xydu53f0CDC9At1kbyHzAGh8drrxl9ZVeLUMZ0WCZIT61ydqnFU8dRM/fa/cAdctIZAcSN/z6jajshsA==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=QSNMVL6mEltWiugyZ4OK8Bx80LAq7MZMbZ7SD/CN+qJ8xU4AFi4xMzAQGQdCgND5SWCLYPc0//9hT+gXjpr43WIVvXJ1GCWaXiVLh50xrudSsoLwxBI5DrDg1ybY14P7/2+7ALKt7j8/iliX5WWc+2ppaobPCLPeGvnjLu6a4Zp4NhQ4I4kZlRkdr6WNcK6VqmAaI/MSnAbwT8rjZWA2C62+FMB5GHTFKknbIDXiSo5HKecZ3n3JEkRJH6hKLuhh3oMFBJBcuD6786jlfYXFriXssu/CbYqkCfsrQfqsN4wa1L1JAk9jFxiajmwrLnP/qL7ZyN7oH8+8fuaEodY8LA==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=uu8fiDOb6eHPPdejl9tK7R0z95vHl5EGgLMijz27OItoVDxqRD1Fru1lhWr9u5QvhDGuebqplts/nVzHLV8tHmDtGtb6X8BCwIvuvde/VkoJd7A+zJlYkJufTLd9/TudIMdotRht8H5wd/q+s0UCduYsPyuOtDQI4LHq8wXugxtaVUyRQU/ypTveTqN19fHIjQwNT+IYw/LUhQ0+dUw/pIjHNfdz+kowVI9dP352t4UMQmEzNrJlZGlQzTmnsHPz9RTzPc1XTLQPqZ2ZPnXMqXwkYk7C+UhKoDDa+8i8AfU9eA66pCiKtNdaGIdr2DrNqiITcj/BImFU7s+x0pqlLw==
- Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"; dkim=pass header.s=selector1 header.d=arm.com header.i="@arm.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
- Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
- Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Romain Caritey <Romain.Caritey@xxxxxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <Bertrand.Marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
- Delivery-date: Tue, 05 May 2026 10:17:42 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHc1xwXYYBcuLui0UypBKVcqnkF/bX10fCAgAeOAYCAAcPSgIAACp8AgAARTACAAAHQgIAAAJwA
- Thread-topic: [PATCH v4 01/11] xen: arm: fix len type for guest copy functions
> On 5 May 2026, at 11:13, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> 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).
Thanks.
Reviewed-by: Luca Fancellu <luca.fancellu@xxxxxxx>
Cheers,
Luca
|
