[Xen-changelog] [linux-2.6.18-xen] xenfb: Only start one xenfb kthread

["Xen patchbot-linux-2.6.18-xen" <patchbot-linux-2.6.18-xen@xxxxxxxxxxxxxxxxxxx>]

# HG changeset patch
# User Keir Fraser <keir.fraser@xxxxxxxxxx>
# Date 1259848386 0
# Node ID 2641f0d17eaa22811883aee22f399db46cbff06f
# Parent  ff5ea1801bd3f5857c095c760f04dfab787f8c1d
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 <clalance@xxxxxxxxxx>
---
 drivers/xen/fbfront/xenfb.c |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -r ff5ea1801bd3 -r 2641f0d17eaa drivers/xen/fbfront/xenfb.c
--- a/drivers/xen/fbfront/xenfb.c       Tue Dec 01 14:02:52 2009 +0000
+++ b/drivers/xen/fbfront/xenfb.c       Thu Dec 03 13:53:06 2009 +0000
@@ -831,7 +831,7 @@ static void xenfb_backend_changed(struct
                                 "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)) {

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog