From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJL7m-0001xn-Mk for qemu-devel@nongnu.org; Mon, 27 Nov 2017 10:15:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJL7h-0004by-2f for qemu-devel@nongnu.org; Mon, 27 Nov 2017 10:15:10 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38568) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJL7g-0004bV-Tf for qemu-devel@nongnu.org; Mon, 27 Nov 2017 10:15:05 -0500 References: <0c5530cd-6f56-bce6-9fdf-91c1468324e4@redhat.com> From: Paolo Bonzini Message-ID: Date: Mon, 27 Nov 2017 16:14:57 +0100 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] javac crash in user-mode emulation: races on page_unprotect() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , =?UTF-8?Q?Alex_Benn=c3=a9e?= , Richard Henderson On 27/11/2017 16:06, Peter Maydell wrote: > On 27 November 2017 at 15:53, Paolo Bonzini wrote= : >> On 27/11/2017 15:47, Peter Maydell wrote: >>> I have a patch from rth based on an idea he and I came up with: >>> we add a field to the PageDesc struct to store the thread id of >>> the thread that last touches the flags. If you come into the >>> segv handler and the page flags/last-modified-by field say "should be >>> writeable and somebody else updated it" then you mark the page as >>> "last modified by this thread" and retry the access. If the >>> flags say "should be writeable, last modified by this thread" >>> then you know the page state hasn't changed since this thread >>> last saw it as "definitely not causing segvs because of cached TBs", >>> and so that should be passed on as a guest SEGV. >> Clever, but why would si_code not work?... > Do we have a guarantee that it's absolutely never the case that > you can get a SEGV with si_code SEGV_ACCERR for an access to memory > that's mapped writeable (and conversely that we'll always get > SEGV_ACCERR for the "mapped nonwriteable" case)? If it's ever possible > then the guest will go into an infinite loop of taking segfaults that > should be delivered to the guest but which we just retry the failing > access for forever... At least for x86, yes. For ARM, the syndrome values that trigger SEGV_ACCERR are 9-11 and 13-15, which seems sane to me but I know much less about ARM than x86. So I would say "yes except for kernel bugs". Paolo