From patchwork Fri Jul 15 09:03:16 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Lieven X-Patchwork-Id: 9231363 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F2C6260574 for ; Fri, 15 Jul 2016 09:03:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DFC8A2816B for ; Fri, 15 Jul 2016 09:03:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D490228329; Fri, 15 Jul 2016 09:03:40 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 7003B2816B for ; Fri, 15 Jul 2016 09:03:40 +0000 (UTC) Received: from localhost ([::1]:59294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNz23-00053X-Ax for patchwork-qemu-devel@patchwork.kernel.org; Fri, 15 Jul 2016 05:03:39 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56161) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNz1o-0004lq-6J for qemu-devel@nongnu.org; Fri, 15 Jul 2016 05:03:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNz1j-0004tg-Rl for qemu-devel@nongnu.org; Fri, 15 Jul 2016 05:03:23 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:53576 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNz1j-0004tS-I3 for qemu-devel@nongnu.org; Fri, 15 Jul 2016 05:03:19 -0400 Received: (qmail 11668 invoked by uid 89); 15 Jul 2016 09:03:17 -0000 Received: from [195.62.97.28] by client-16-kamp (envelope-from , uid 89) with qmail-scanner-2010/03/19-MF (clamdscan: 0.99.2/21906. hbedv: 8.3.40.44/7.12.99.34. avast: 1.2.2/16071401. spamassassin: 3.4.1. Clear:RC:1(195.62.97.28):. Processed in 0.062401 secs); 15 Jul 2016 09:03:17 -0000 Received: from smtp.kamp.de (HELO submission.kamp.de) ([195.62.97.28]) by mx01.kamp.de with ESMTPS (DHE-RSA-AES256-GCM-SHA384 encrypted); 15 Jul 2016 09:03:16 -0000 X-GL_Whitelist: yes Received: (qmail 15742 invoked from network); 15 Jul 2016 09:03:16 -0000 Received: from ac62.vpn.kamp-intra.net (HELO ?172.20.250.62?) (pl@kamp.de@::ffff:172.20.250.62) by submission.kamp.de with ESMTPS (DHE-RSA-AES128-SHA encrypted) ESMTPA; 15 Jul 2016 09:03:16 -0000 Message-ID: <5788A6D4.5070804@kamp.de> Date: Fri, 15 Jul 2016 11:03:16 +0200 From: Peter Lieven User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Juergen Gross , xen-devel , "qemu-devel@nongnu.org" References: <57888385.1080403@suse.com> <57889319.3030609@kamp.de> <5788A308.5010909@suse.com> In-Reply-To: <5788A308.5010909@suse.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a02:248:0:51::16 Subject: Re: [Qemu-devel] Regression with commit 095497ffc66b7f031 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paolo Bonzini , Gerd Hoffmann Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Am 15.07.2016 um 10:47 schrieb Juergen Gross: > On 15/07/16 09:39, Peter Lieven wrote: >> Am 15.07.2016 um 08:32 schrieb Juergen Gross: >>> Commit 095497ffc66b7f031ff2a17f1e50f5cb105ce588 ("vnc-enc-tight: use >>> thread local storage for palette") introduced a regression with Xen: >>> Since this commit qemu used as a device model is no longer capable >>> to register Xenstore watches (that's the effect visible to a user). >>> Reverting this commit makes qemu behave well again. I have no idea >>> why that commit would have this effect with Xen, may be some memory >>> is clobbered? >> I personally have no idea, maybe @Paolo has? >> >> Maybe the corruption happens somewhere else and is just visible >> due to this change. >> >> Do you see sth when you ran qemu/xen in valgrind? > Nothing scaring and no real difference between working and not working > variant. > > Meanwhile I've been digging a little bit deeper and found the reason: > libxenstore is setting up a reader thread which is waiting for the > watch to fire. With above commit the stack size of that thread (16kB) > is too small. Setting it to 32kB made qemu work again. > > So I'd recommend to have just a thread local palette pointer and > allocate the palette when needed and don't free it after using it but > keep it for reuse. Do you want to write that patch or should I do it? As you like. But as I have introduced this regression, maybe I should fix it ;-) Actually I do not understand what libxenstore confuses about 16 and 32kB, but I have no knowledge about XEN. However, let me know if this here works for you: Peter Tested-by: Juergen Gross diff --git a/ui/vnc-enc-tight.c b/ui/vnc-enc-tight.c index b8581dd..5731cf6 100644 --- a/ui/vnc-enc-tight.c +++ b/ui/vnc-enc-tight.c @@ -1457,11 +1457,18 @@ static int send_sub_rect_jpeg(VncState *vs, int x, int y, int w, int h, } #endif -static __thread VncPalette color_count_palette; +static __thread VncPalette *color_count_palette = NULL; +static __thread Notifier vnc_tight_cleanup_notifier; + +static void vnc_tight_cleanup(Notifier *n, void *value) +{ + printf("thread %d: free tight palette %p\n", qemu_get_thread_id(), color_count_palette); + g_free(color_count_palette); + color_count_palette = NULL; +} static int send_sub_rect(VncState *vs, int x, int y, int w, int h) { - VncPalette *palette = &color_count_palette; uint32_t bg = 0, fg = 0; int colors; int ret = 0; @@ -1470,6 +1477,13 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) bool allow_jpeg = true; #endif + if (!color_count_palette) { + color_count_palette = g_malloc(sizeof(VncPalette)); + vnc_tight_cleanup_notifier.notify = vnc_tight_cleanup; + qemu_thread_atexit_add(&vnc_tight_cleanup_notifier); + printf("thread %d: alloc tight palette %p\n", qemu_get_thread_id(), color_count_palette); + } + vnc_framebuffer_update(vs, x, y, w, h, vs->tight.type); vnc_tight_start(vs); @@ -1490,17 +1504,17 @@ static int send_sub_rect(VncState *vs, int x, int y, int w, int h) } #endif - colors = tight_fill_palette(vs, x, y, w * h, &bg, &fg, palette); + colors = tight_fill_palette(vs, x, y, w * h, &bg, &fg, color_count_palette); #ifdef CONFIG_VNC_JPEG if (allow_jpeg && vs->tight.quality != (uint8_t)-1) { - ret = send_sub_rect_jpeg(vs, x, y, w, h, bg, fg, colors, palette, + ret = send_sub_rect_jpeg(vs, x, y, w, h, bg, fg, colors, color_count_palette, force_jpeg); } else { - ret = send_sub_rect_nojpeg(vs, x, y, w, h, bg, fg, colors, palette); + ret = send_sub_rect_nojpeg(vs, x, y, w, h, bg, fg, colors, color_count_palette); } #else - ret = send_sub_rect_nojpeg(vs, x, y, w, h, bg, fg, colors, palette); + ret = send_sub_rect_nojpeg(vs, x, y, w, h, bg, fg, colors, color_count_palette); #endif return ret;