Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1578750
| From | Boris Ostrovsky <boris.ostrovsky@oracle.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP |
| Date | 2017-02-10 20:40 +0100 |
| Message-ID | <t9pcZ-7Ix-3@gated-at.bofh.it> (permalink) |
| References | <t9kn0-4wD-5@gated-at.bofh.it> <t9kn0-4wD-3@gated-at.bofh.it> <t9m5r-5JI-5@gated-at.bofh.it> <t9moN-5Rn-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 02/10/2017 11:28 AM, Paul Durrant wrote:
>> -----Original Message-----
>> From: Boris Ostrovsky [mailto:boris.ostrovsky@oracle.com]
>> Sent: 10 February 2017 16:18
>> To: Paul Durrant <Paul.Durrant@citrix.com>; xen-devel@lists.xenproject.org;
>> linux-kernel@vger.kernel.org
>> Cc: Juergen Gross <jgross@suse.com>
>> Subject: Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP
>>
>> On 02/10/2017 09:24 AM, Paul Durrant wrote:
>>> +static long privcmd_ioctl_dm_op(void __user *udata)
>>> +{
>>> + struct privcmd_dm_op kdata;
>>> + struct privcmd_dm_op_buf *kbufs;
>>> + unsigned int nr_pages = 0;
>>> + struct page **pages = NULL;
>>> + struct xen_dm_op_buf *xbufs = NULL;
>>> + unsigned int i;
>>> + long rc;
>>> +
>>> + if (copy_from_user(&kdata, udata, sizeof(kdata)))
>>> + return -EFAULT;
>>> +
>>> + if (kdata.num == 0)
>>> + return 0;
>>> +
>>> + /*
>>> + * Set a tolerable upper limit on the number of buffers
>>> + * without being overly restrictive, since we can't easily
>>> + * predict what future dm_ops may require.
>>> + */
>> I think this deserves its own macro since it really has nothing to do
>> with page size, has it? Especially since you are referencing it again
>> below too.
>>
>>
>>> + if (kdata.num * sizeof(*kbufs) > PAGE_SIZE)
>>> + return -E2BIG;
>>> +
>>> + kbufs = kcalloc(kdata.num, sizeof(*kbufs), GFP_KERNEL);
>>> + if (!kbufs)
>>> + return -ENOMEM;
>>> +
>>> + if (copy_from_user(kbufs, kdata.ubufs,
>>> + sizeof(*kbufs) * kdata.num)) {
>>> + rc = -EFAULT;
>>> + goto out;
>>> + }
>>> +
>>> + for (i = 0; i < kdata.num; i++) {
>>> + if (!access_ok(VERIFY_WRITE, kbufs[i].uptr,
>>> + kbufs[i].size)) {
>>> + rc = -EFAULT;
>>> + goto out;
>>> + }
>>> +
>>> + nr_pages += DIV_ROUND_UP(
>>> + offset_in_page(kbufs[i].uptr) + kbufs[i].size,
>>> + PAGE_SIZE);
>>> + }
>>> +
>>> + /*
>>> + * Again, set a tolerable upper limit on the number of pages
>>> + * needed to lock all the buffers without being overly
>>> + * restrictive, since we can't easily predict the size of
>>> + * buffers future dm_ops may use.
>>> + */
>> OTOH, these two cases describe different types of copying (the first one
>> is for buffer descriptors and the second is for buffers themselves). And
>> so should they be limited by the same value?
>>
> I think there needs to be some limit and limiting the allocation to a page was the best I came up with. Can you think of a better one?
How about something like (with rather arbitrary values)
#define PRIVCMD_DMOP_MAX_NUM_BUFFERS 16
#define PRIVCMD_DMOP_MAX_TOT_BUFFER_SZ 4096
and make them part of the interface (i.e. put them into privcmd.h)?
-boris
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Paul Durrant <paul.durrant@citrix.com> - 2017-02-10 15:30 +0100
Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-02-10 17:20 +0100
RE: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Paul Durrant <Paul.Durrant@citrix.com> - 2017-02-10 17:40 +0100
Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-02-10 20:40 +0100
RE: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Paul Durrant <Paul.Durrant@citrix.com> - 2017-02-13 10:10 +0100
Re: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Boris Ostrovsky <boris.ostrovsky@oracle.com> - 2017-02-13 15:10 +0100
RE: [PATCH v2 2/3] xen/privcmd: Add IOCTL_PRIVCMD_DM_OP Paul Durrant <Paul.Durrant@citrix.com> - 2017-02-13 15:20 +0100
csiph-web