[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: Jan Beulich <jbeulich@xxxxxxxx>
- From: Luca Fancellu <Luca.Fancellu@xxxxxxx>
- Date: Tue, 5 May 2026 10:07:46 +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=suse.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=rTdTpntTu8gQNXtZOEc4phtBrG77MBT7zFAnDu8JKF8=; b=OdG/Ezc6IGl5Awmi97rsAp16aH5P0HK2AbnDRW2fI2mRP3NlSrgqWWqCsgeAMPbN847yzMCbvBk1sv9Puo8SfS0kg0tVt0QCs9MG4aY3U3UxD0IMlUu0m92Lw0mBZtCkTF2wKSY291Eco5guWnOwfbBpfJXHx5jcYTq8nfoAW8PHIYOq5S/aVFrEPMqmPmGdUHwcZIzHHf1s6vXNEp0nwKl8iGLBR2jFKLjNTKPctYDaqV0Xcz0L0UCQ0zqkCKuwGYS0rGlZ+9ztG38cvhN+OnIfYj3ZRtYwHqDh4mKXD3VTsASIR3orVaRFanJKPJBCrNLsyG/rbKxoCdY1BMhXsg==
- 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=rTdTpntTu8gQNXtZOEc4phtBrG77MBT7zFAnDu8JKF8=; b=VyJqXYfi0G4KmdLhMakzZZ5l7oLbBsmTL5i96fCbdFjavhwo0+odTpwQyf8NR17KByU+DrfNE3gxXOtJ0oDaNJIz7rAM2+hWd6sVQoEYq3eECu+SrYZ/dJ8xjfAENqgtCHJxR0PtOi/2/kvuZUU6z3y7FNw9Vnv4PZS/pgE4B5FQ7V36c2m2ukHwKzFtWOyg7cqZdCffrjKmELyBm5DwcGjzyIkeICAkhu23apuykEUrYtSFrhmvNfFY9JMTEctZyOJ5HFK0Luqo4Julu1P4NP01hTCytxoN0kYqVbGf6v6ZG4qboZqgQb3tEaYqc0F2xzggPH726p8Yh4QToReKJQ==
- Arc-seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=AClbXW/MN3yaIiLsO8rpPsP3rDk2RACtPdfpFHbHzQcbBe7VfUYd1gowCe9XRsANIgOMz6/MjxfXBYCi2Mf/+GFwem/Ap8NWo0zWttJsyAiUS4vWj2jML8qZso+V82WkfcOrpCC0uwDnK9jOxgINhKUCSppawgPmig7xS+w0zNdGfsrkkPjB1uZ3NDluo5KmaVN4FVRWPlL+2jWi6KOfs1fAz02lG2VnVvpQxgFnqaLgCKpJYQl3YCNugY9qWkSHuw7x+Ih+dJBYygCmMQLdrENhBzbA+ToMkG1fD1DPwHd++4BNKWgweQzB7zkmpVjEa80AQkeh72cDK/E5Zja4AQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=f9OZhFCeM9EU65Ne3Pzi8fMbzczZGhA/+ZrKeDpJPRS5wWMAJ5B+qp8o1362gYJguMZSHFDYtEc//sUiqVPj9jIu5RHNPCDBx0iaBJrHMVaBJPwld8OSOQtXXU+Fk/JzhMuZ3xrdhf00txXY+TxrJ1HPF9IZ1nXhLmxI27oDz2ujbx2eJvQoL98I7qRDhLIoOQ6TnkLMkZ94dsQYoDOdaMxt75sIxUKDMpvAoVsbj7WeAOu7ljVVX8p1gXarFUUi5xYdX264+2baA+6m4cMlG7RqDZCXLKK/hbFnkPUs6pcYDxmos5NXgFVmPjJpo42AWABu6VFrWMfMTgdX9ZDYpw==
- 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>, Oleksii Kurochko <oleksii.kurochko@xxxxxxxxx>
- Delivery-date: Tue, 05 May 2026 10:09:11 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
- Nodisclaimer: true
- Thread-index: AQHc1xwXYYBcuLui0UypBKVcqnkF/bX10fCAgAeOAYCAAcPSgIAACp8AgAARTAA=
- Thread-topic: [PATCH v4 01/11] xen: arm: fix len type for guest copy functions
> 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.
I’m asking to understand your reasoning and calibrate my reviews accordingly.
When the reasoning is not stated, it is hard to tell whether
this is a general review rule I should apply in similar cases or just a
preference for this patch.
Cheers,
Luca
|
