On 11/06/2019 11:25, Juergen Gross wrote:
> On 11.06.19 12:18, George Dunlap wrote:
>> On 6/11/19 10:20 AM, Baodong Chen wrote:
>>> * Remove redundant set 'DOMDYING_dead'
>>> domain_create() will set this when fail, thus no need
>>> set in arch_domain_create().
>>>
>>> * Set error when really happened
>>
>>> diff --git a/xen/common/schedule.c b/xen/common/schedule.c
>>> index 86341bc..d6cdcf8 100644
>>> --- a/xen/common/schedule.c
>>> +++ b/xen/common/schedule.c
>>> @@ -1894,9 +1894,11 @@ struct scheduler *scheduler_alloc(unsigned
>>> int sched_id, int *perr)
>>> return NULL;
>>> found:
>>> - *perr = -ENOMEM;
>>> if ( (sched = xmalloc(struct scheduler)) == NULL )
>>> + {
>>> + *perr = -ENOMEM;
>>> return NULL;
>>> + }
>>> memcpy(sched, schedulers[i], sizeof(*sched));
>>> if ( (*perr = SCHED_OP(sched, init)) != 0 )
>>
>> I was going to say, this is a common idiom in the Xen code, and the
>> compiler will end up re-organizing things such that the write doesn't
>> happen anyway. But in this case, its' actually writing through a
>> pointer before and after a function call; I don't think the compiler
>> would actually be allowed to optimize this write away.
>>
>> So, I guess I'd be OK with this particular hunk. Dario, any opinions?
>
> I'd rather switch to PTR_ERR() here dropping the perr parameter.
+2 for this, but I was going to wait until core scheduling had gotten a
bit further before suggesting cleanup which is guaranteed to collide.
Sadly, it's fairly intrusive in the cpupool code as well.
~Andrew
_______________________________________________
Xen-devel mailing list
[email protected]
https://lists.xenproject.org/mailman/listinfo/xen-devel
