From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46742) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhNZK-0003S4-Sq for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:01:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZhNZG-0002ht-Qo for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:01:38 -0400 Received: from mail-pa0-x22d.google.com ([2607:f8b0:400e:c03::22d]:34523) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZhNZG-0002ho-KD for qemu-devel@nongnu.org; Wed, 30 Sep 2015 16:01:34 -0400 Received: by padhy16 with SMTP id hy16so49833310pad.1 for ; Wed, 30 Sep 2015 13:01:33 -0700 (PDT) Sender: Richard Henderson References: <1443589786-26929-1-git-send-email-rth@twiddle.net> <1443589786-26929-25-git-send-email-rth@twiddle.net> <20150930163355.GC17449@aurel32.net> From: Richard Henderson Message-ID: <560C3F94.1040400@twiddle.net> Date: Thu, 1 Oct 2015 06:01:24 +1000 MIME-Version: 1.0 In-Reply-To: <20150930163355.GC17449@aurel32.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v4 24/26] tcg: Allocate a guard page after code_gen_buffer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, peter.maydell@linaro.org On 10/01/2015 02:33 AM, Aurelien Jarno wrote: > On 2015-09-30 15:09, Richard Henderson wrote: >> This will catch any overflow of the buffer. >> >> Add a native win32 alternative for alloc_code_gen_buffer; >> remove the malloc alternative. >> >> Signed-off-by: Richard Henderson >> --- >> translate-all.c | 210 ++++++++++++++++++++++++++++++++------------------------ >> 1 file changed, 119 insertions(+), 91 deletions(-) > > I havent reviewed the patch in details, but I wonder if that could really > happen? Given the size of the code generation buffer (a few MB at > least), I don't think it's a problem if we don't use it to the last kB, > and thus we could keep some safe margin if needed. I don't believe that it can happen at the moment, given the size of the current "safe margin". But the subject came up during review, and I thought we should indeed do something about it. > Also what happens if an overflow really happens? In softmmu mode a > segmentation fault will happen. In user-mode I guess the fault will > be forwarded to the guest process, so this will likely wrongly > be interpreted as a bug in the guest code. You're right. I had thought that we tested page_check_range on the given address in user-mode before passing it on to the guest. In any case, that's how to fix the problem you indicate... r~