From: Yi Liu <yi.l.liu@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: <jgg@nvidia.com>, <kevin.tian@intel.com>,
<baolu.lu@linux.intel.com>, <joro@8bytes.org>,
<eric.auger@redhat.com>, <nicolinc@nvidia.com>,
<kvm@vger.kernel.org>, <chao.p.peng@linux.intel.com>,
<iommu@lists.linux.dev>, <zhenzhong.duan@intel.com>,
<vasant.hegde@amd.com>, <will@kernel.org>
Subject: Re: [PATCH v5 4/5] vfio: Add vfio_copy_user_data()
Date: Wed, 13 Nov 2024 15:22:02 +0800 [thread overview]
Message-ID: <7808f8da-8932-486d-8d47-10a95bc5002d@intel.com> (raw)
In-Reply-To: <20241112065253.6c9a38ac.alex.williamson@redhat.com>
On 2024/11/12 21:52, Alex Williamson wrote:
>>>> +{
>>>> + unsigned long xend = minsz;
>>>> + struct user_header {
>>>> + u32 argsz;
>>>> + u32 flags;
>>>> + } *header;
>>>> + unsigned long flags;
>>>> + u32 flag;
>>>> +
>>>> + if (copy_from_user(buffer, arg, minsz))
>>>> + return -EFAULT;
>>>> +
>>>> + header = (struct user_header *)buffer;
>>>> + if (header->argsz < minsz)
>>>> + return -EINVAL;
>>>> +
>>>> + if (header->flags & ~flags_mask)
>>>> + return -EINVAL;
>>>
>>> I'm already wrestling with whether this is an over engineered solution
>>> to remove a couple dozen lines of mostly duplicate logic between attach
>>> and detach, but a couple points that could make it more versatile:
>>>
>>> (1) Test xend_array here:
>>>
>>> if (!xend_array)
>>> return 0;
>>
>> Perhaps we should return error if the header->flags has any bit set. Such
>> cases require a valid xend_array.
>
> I don't think that's true. For example if we want to drop this into
> existing cases where the structure size has not expanded and flags are
> used for other things, I don't think we want the overhead of declaring
> an xend_array.
I see. My thought was sticking with using it in the cases that have
extended fields. Given that would it be better to return minsz as you
suggested to return ssize_t to caller.
>
>>> (2) Return ssize_t/-errno for the caller to know the resulting copy
>>> size.
>>>
>>>> +
>>>> + /* Loop each set flag to decide the xend */
>>>> + flags = header->flags;
>>>> + for_each_set_bit(flag, &flags, BITS_PER_TYPE(u32)) {
>>>> + if (xend_array[flag] > xend)
>>>> + xend = xend_array[flag];
>>>
>>> Can we craft a BUILD_BUG in the wrapper to test that xend_array is at
>>> least long enough to match the highest bit in flags? Thanks,
>>
>> yes. I would add a BUILD_BUG like the below.
>>
>> BUILD_BUG_ON(ARRAY_SIZE(_xend_array) < ilog2(_flags_mask));
>
> So this would need to account that _xend_array can be NULL regardless
> of _flags_mask. Thanks,
yes, but I encounter a problem to account it. The below failed as when
the _xend_array is a null pointer. It's due to the usage of ARRAY_SIZE
macro. If it's not doable, perhaps we can have two wrappers, one for
copying user data with array, this should enforce the array num check
with flags. While, the another one is for copying user data without
array, no array num check. How about your opinion?
BUILD_BUG_ON((_xend_array != NULL) && (ARRAY_SIZE(_xend_array) <
ilog2(_flags_mask)));
Compiling fail snippet:
In file included from <command-line>:
./include/linux/array_size.h:11:38: warning: division ‘sizeof (long
unsigned int *) / sizeof (long unsigned int)’ does not compute the number
of array elements [-Wsizeof-pointer-div]
11 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) +
__must_be_array(arr))
| ^
././include/linux/compiler_types.h:497:23: note: in definition of macro
‘__compiletime_assert’
497 | if (!(condition))
\
| ^~~~~~~~~
././include/linux/compiler_types.h:517:9: note: in expansion of macro
‘_compiletime_assert’
517 | _compiletime_assert(condition, msg, __compiletime_assert_,
__COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro
‘compiletime_assert’
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
--
Regards,
Yi Liu
next prev parent reply other threads:[~2024-11-13 7:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 12:17 [PATCH v5 0/5] vfio-pci support pasid attach/detach Yi Liu
2024-11-08 12:17 ` [PATCH v5 1/5] ida: Add ida_find_first_range() Yi Liu
2024-11-08 12:17 ` [PATCH v5 2/5] vfio-iommufd: Support pasid [at|de]tach for physical VFIO devices Yi Liu
2024-11-08 12:17 ` [PATCH v5 3/5] vfio: VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT support pasid Yi Liu
2024-11-12 0:02 ` Alex Williamson
2024-11-12 1:53 ` Yi Liu
2024-11-08 12:17 ` [PATCH v5 4/5] vfio: Add vfio_copy_user_data() Yi Liu
2024-11-12 0:03 ` Alex Williamson
2024-11-12 9:18 ` Yi Liu
2024-11-12 13:52 ` Alex Williamson
2024-11-13 7:22 ` Yi Liu [this message]
2024-11-14 18:19 ` Alex Williamson
2024-11-15 12:10 ` Yi Liu
2024-11-08 12:17 ` [PATCH v5 5/5] iommufd: Extend IOMMU_GET_HW_INFO to report PASID capability Yi Liu
2024-12-11 2:43 ` Zhangfei Gao
2024-12-11 3:12 ` Yi Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7808f8da-8932-486d-8d47-10a95bc5002d@intel.com \
--to=yi.l.liu@intel.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=chao.p.peng@linux.intel.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=nicolinc@nvidia.com \
--cc=vasant.hegde@amd.com \
--cc=will@kernel.org \
--cc=zhenzhong.duan@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox