|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v18 01/10] x86: add generic resource (e.g. MSR) access hypercall
>>> On 01.10.14 at 12:04, <chao.p.peng@xxxxxxxxxxxxxxx> wrote:
> On Tue, Sep 30, 2014 at 01:12:42PM +0100, Jan Beulich wrote:
>> >>> On 30.09.14 at 12:49, <chao.p.peng@xxxxxxxxxxxxxxx> wrote:
>> > + case XENPF_resource_op:
>> > + {
>> > + struct xen_resource_access ra;
>> > + uint32_t cpu;
>> > + XEN_GUEST_HANDLE(xenpf_resource_entry_t) guest_entries;
>> > +
>> > + ra.nr_entries = op->u.resource_op.nr_entries;
>> > + if ( ra.nr_entries == 0 || ra.nr_entries >
>> > RESOURCE_ACCESS_MAX_ENTRIES )
>> > + {
>> > + ret = -EINVAL;
>>
>> I don't think ra.nr_entries == 0 is a reason to fail the hypercall.
> Do you mean 'ret = 0' ?
Sure.
>> > + break;
>> > + }
>> > +
>> > + ra.entries = xmalloc_array(xenpf_resource_entry_t, ra.nr_entries);
>> > + if ( !ra.entries )
>> > + {
>> > + ret = -ENOMEM;
>> > + break;
>> > + }
>> > +
>> > + guest_from_compat_handle(guest_entries,
>> > op->u.resource_op.entries);
>> > +
>> > + if ( copy_from_guest(ra.entries, guest_entries, ra.nr_entries) )
>> > + {
>> > + xfree(ra.entries);
>> > + ret = -EFAULT;
>> > + break;
>> > + }
>> > +
>> > + /* Do sanity check earlier to omit the potential IPI overhead. */
>> > + if ( check_resource_access(&ra) < ra.nr_entries )
>> > + {
>> > + /* Copy the return value for failed entry. */
>> > + if ( __copy_to_guest_offset(guest_entries, ret,
>> > + ra.entries + ret, 1) )
>> > + ret = -EFAULT;
>> > + else
>> > + ret = 0;
>>
>> This should be the index of the failed entry. I guess it would be
>> easier and more consistent if check_resource_access() too used
>> ra.ret for passing back the failed index (which btw should be
>> renamed to e.g. "done" - "ret" is no longer a suitable name).
>
> I agree to use ra.ret for check_resource_access(). But I insist that return
> 0
> here is more reasonable. As we use positive return value to indicate the
> number of successful operations. But here we just passed some check and
> have even not performed the access. Return index of the failed entry
> will lead the caller to think the data for entries earlier is valid.
No - really correct behavior would be to carry out the operations
that passed the validation checks rather than exiting early here.
>> > + on_selected_cpus(cpumask_of(cpu), resource_access, &ra, 1);
>> > + else
>> > + {
>> > + xfree(ra.entries);
>> > + ret = -ENODEV;
>> > + break;
>> > + }
>> > +
>> > + /* Copy all if succeeded or up to the failed entry. */
>> > + if ( __copy_to_guest_offset(guest_entries, 0, ra.entries,
>> > + min(ra.nr_entries, ra.ret + 1)) )
>>
>> I don't see a need for min() here - ra.ret mustn't be out of range.
>> If you're concerned, add an ASSERT().
>
> For fully-succeeded case, ra.ret will be ra.nr_entries and ra.ret + 1 is out
> of range.
I don't think I understand what you're trying to tell me.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |