[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH] xen: superficial clean-ups
- To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Baodong Chen <chenbaodong@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- From: Juergen Gross <jgross@xxxxxxxx>
- Date: Tue, 11 Jun 2019 12:29:41 +0200
- Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Ian Jackson <ian.jackson@xxxxxxxxxxxxx>, Tim Deegan <tim@xxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Julien Grall <julien.grall@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>
- Delivery-date: Tue, 11 Jun 2019 10:29:49 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 11.06.19 12:27, Andrew Cooper wrote:
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.
I can add this to my list of scheduler cleanups to do.
Juergen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel
|
