On Tue, 2019-06-11 at 12:25 +0200, Juergen Gross wrote:
> On 11.06.19 12:18, George Dunlap wrote:
> > On 6/11/19 10:20 AM, Baodong Chen wrote:
> > > --- 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'm ok with it too, but...> I'd rather switch to PTR_ERR() here dropping the perr parameter. > ... I'd be even more ok with this! :-) Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
