search for: out_error

...blkdev->fileproto = blkdev->params; blkdev->filename = h+1; @@ -649,7 +651,7 @@ static int blk_init(struct XenDevice *xendev) blkdev->mode == NULL || blkdev->type == NULL || blkdev->dev == NULL) { - return -1; + goto out_error; } /* read-only ? */ @@ -672,10 +674,15 @@ static int blk_init(struct XenDevice *xendev) /* setup via xenbus -> create new block driver instance */ xen_be_printf(&blkdev->xendev, 2, "create new bdrv (xenbus setup)\n"); blkdev->bs = bdrv_...

...blkdev->fileproto = blkdev->params; blkdev->filename = h+1; @@ -649,7 +651,7 @@ static int blk_init(struct XenDevice *xendev) blkdev->mode == NULL || blkdev->type == NULL || blkdev->dev == NULL) { - return -1; + goto out_error; } /* read-only ? */ @@ -672,10 +674,15 @@ static int blk_init(struct XenDevice *xendev) /* setup via xenbus -> create new block driver instance */ xen_be_printf(&blkdev->xendev, 2, "create new bdrv (xenbus setup)\n"); blkdev->bs = bdrv_...

...->file_blk = BLOCK_SIZE; + + /* fill info + * blk_connect supplies sector-size and sectors + */ + xenstore_write_be_int(&blkdev->xendev, "feature-barrier", 1); + xenstore_write_be_int(&blkdev->xendev, "info", info); + return 0; + +out_error: + g_free(blkdev->params); + blkdev->params = NULL; + g_free(blkdev->mode); + blkdev->mode = NULL; + g_free(blkdev->type); + blkdev->type = NULL; + g_free(blkdev->dev); + blkdev->dev = NULL; + g_free(blkdev->devtype); + blkdev->devtype = N...

...eletions(-) diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c index 370c2f76016d..10f6ff1cf6a0 100644 --- a/drivers/block/zram/zram_drv.c +++ b/drivers/block/zram/zram_drv.c @@ -514,7 +514,8 @@ static struct zram_meta *zram_meta_alloc(char *pool_name, u64 disksize) goto out_error; } - meta->mem_pool = zs_create_pool(pool_name, GFP_NOIO | __GFP_HIGHMEM); + meta->mem_pool = zs_create_pool(pool_name, GFP_NOIO|__GFP_HIGHMEM + |__GFP_MOVABLE); if (!meta->mem_pool) { pr_err("Error creating memory pool\n"); goto out_error; diff --git a/mm/zsmall...

...RT_SYMBOL_GPL(xenbus_dev_cancel); /* A flag to determine if xenstored is 'ready' (i.e. has started) */ -int xenstored_ready = 0; +int xenstored_ready; int register_xenstore_notifier(struct notifier_block *nb) @@ -774,7 +773,7 @@ static int __init xenbus_init(void) return 0; - out_error: +out_error: if (page != 0) free_page(page); -- 1.7.4.1

...RT_SYMBOL_GPL(xenbus_dev_cancel); /* A flag to determine if xenstored is 'ready' (i.e. has started) */ -int xenstored_ready = 0; +int xenstored_ready; int register_xenstore_notifier(struct notifier_block *nb) @@ -774,7 +773,7 @@ static int __init xenbus_init(void) return 0; - out_error: +out_error: if (page != 0) free_page(page); -- 1.7.4.1

...RT_SYMBOL_GPL(xenbus_dev_cancel); /* A flag to determine if xenstored is 'ready' (i.e. has started) */ -int xenstored_ready = 0; +int xenstored_ready; int register_xenstore_notifier(struct notifier_block *nb) @@ -774,7 +773,7 @@ static int __init xenbus_init(void) return 0; - out_error: +out_error: if (page != 0) free_page(page); -- 1.7.4.1

Hi, This patch series fixes the S3 resume of a domain running xenstored and a frontend over xenbus (xen-netfront in my use case). As device resume is happening before process resume, the xenbus frontend resume is hanging if xenstored is not running, thus causing a deadlock. This patch series is fixing that issue by deferring the xenbus frontend resume when we are running xenstored in that same

From: Stefano Stabellini <stefano.stabellini@eu.citrix.com> When disk is a cdrom and the drive is empty the "params" node in xenstore might be missing completely: cope with it instead of segfaulting. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> --- hw/xen_disk.c | 16 +++++++++++----- 1 files changed, 11 insertions(+), 5 deletions(-) diff --git

...nit xenstored_local_init(void) return err; } +extern void xenbus_ring_ops_init(void); static int __init xenbus_init(void) { int err = 0; @@ -767,6 +768,8 @@ static int __init xenbus_init(void) proc_mkdir("xen", NULL); #endif + xenbus_ring_ops_init(); + out_error: return err; } diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h index e8c599b..cdbd948 100644 --- a/include/xen/xenbus.h +++ b/include/xen/xenbus.h @@ -195,15 +195,23 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch, const c...

...nit xenstored_local_init(void) return err; } +extern void xenbus_ring_ops_init(void); static int __init xenbus_init(void) { int err = 0; @@ -767,6 +768,8 @@ static int __init xenbus_init(void) proc_mkdir("xen", NULL); #endif + xenbus_ring_ops_init(); + out_error: return err; } diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h index e8c599b..cdbd948 100644 --- a/include/xen/xenbus.h +++ b/include/xen/xenbus.h @@ -195,15 +195,23 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch, const c...

...nit xenstored_local_init(void) return err; } +extern void xenbus_ring_ops_init(void); static int __init xenbus_init(void) { int err = 0; @@ -767,6 +768,8 @@ static int __init xenbus_init(void) proc_mkdir("xen", NULL); #endif + xenbus_ring_ops_init(); + out_error: return err; } diff --git a/include/xen/xenbus.h b/include/xen/xenbus.h index e8c599b..cdbd948 100644 --- a/include/xen/xenbus.h +++ b/include/xen/xenbus.h @@ -195,15 +195,23 @@ int xenbus_watch_pathfmt(struct xenbus_device *dev, struct xenbus_watch *watch, const c...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

..._segment(bv, req, iter) { - dst = page_address(bv->bv_page) + bv->bv_offset; + dst = page_address(bv.bv_page) + bv.bv_offset; last_tidaw = itcw_add_tidaw(itcw, 0x00, - dst, bv->bv_len); + dst, bv.bv_len); if (IS_ERR(last_tidaw)) { ret = -EINVAL; goto out_error; @@ -3276,7 +3276,7 @@ static struct dasd_ccw_req *dasd_raw_build_cp(struct dasd_device *startdev, struct dasd_ccw_req *cqr; struct ccw1 *ccw; struct req_iterator iter; - struct bio_vec *bv; + struct bio_vec bv; char *dst; unsigned char cmd; unsigned int trkcount; @@ -3376,8 +3376,8 @@...

..._segment(bv, req, iter) { - dst = page_address(bv->bv_page) + bv->bv_offset; + dst = page_address(bv.bv_page) + bv.bv_offset; last_tidaw = itcw_add_tidaw(itcw, 0x00, - dst, bv->bv_len); + dst, bv.bv_len); if (IS_ERR(last_tidaw)) { ret = -EINVAL; goto out_error; @@ -3276,7 +3276,7 @@ static struct dasd_ccw_req *dasd_raw_build_cp(struct dasd_device *startdev, struct dasd_ccw_req *cqr; struct ccw1 *ccw; struct req_iterator iter; - struct bio_vec *bv; + struct bio_vec bv; char *dst; unsigned char cmd; unsigned int trkcount; @@ -3376,8 +3376,8 @@...

..._segment(bv, req, iter) { - dst = page_address(bv->bv_page) + bv->bv_offset; + dst = page_address(bv.bv_page) + bv.bv_offset; last_tidaw = itcw_add_tidaw(itcw, 0x00, - dst, bv->bv_len); + dst, bv.bv_len); if (IS_ERR(last_tidaw)) { ret = -EINVAL; goto out_error; @@ -3276,7 +3276,7 @@ static struct dasd_ccw_req *dasd_raw_build_cp(struct dasd_device *startdev, struct dasd_ccw_req *cqr; struct ccw1 *ccw; struct req_iterator iter; - struct bio_vec *bv; + struct bio_vec bv; char *dst; unsigned char cmd; unsigned int trkcount; @@ -3376,8 +3376,8 @@...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and failed to fork easily. The problem was fragmentation caused by zram and GPU driver pages. Their pages cannot be migrated so compaction cannot work well, either so reclaimer ends up shrinking all of working set pages. It made system very slow and even to fail to fork easily.