From e189346f59dcb0140c211afb64c34571aaa47151 Mon Sep 17 00:00:00 2001 From: Keir Fraser Date: Thu, 3 Dec 2009 13:53:06 +0000 Subject: [PATCH] xenfb: Only start one xenfb kthread When doing save/restore testing with the linux-2.6.18-xen.hg tree it was discovered that every time a restore happened we would get a new xenfb thread. While the framebuffer continues to work, this is an obvious resource leak. The attached patch only starts up a new xenfb thread the first time the backend connects, and continues to re-use that in the future. Jeremy's upstream LKML tree doesn't suffer from this since it uses a completely different mechanism to do screen updates. Original patch from John Haxby @ Oracle; slightly modified by me to apply to the linux-2.6.18-xen.hg tree. Signed-off-by: Chris Lalancette --- drivers/xen/fbfront/xenfb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/xen/fbfront/xenfb.c b/drivers/xen/fbfront/xenfb.c index d6155a45..ce2d87a7 100644 --- a/drivers/xen/fbfront/xenfb.c +++ b/drivers/xen/fbfront/xenfb.c @@ -831,7 +831,7 @@ static void xenfb_backend_changed(struct xenbus_device *dev, "request-update", "%d", &val) < 0) val = 0; - if (val){ + if (val && !info->kthread) { info->kthread = kthread_run(xenfb_thread, info, "xenfb thread"); if (IS_ERR(info->kthread)) { -- 2.39.5