From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46395) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSs3G-0001ri-VA for qemu-devel@nongnu.org; Fri, 11 May 2012 11:46:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SSs3F-0001Ep-2p for qemu-devel@nongnu.org; Fri, 11 May 2012 11:46:42 -0400 Received: from mail-yw0-f45.google.com ([209.85.213.45]:41106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SSs3E-0001Ee-VT for qemu-devel@nongnu.org; Fri, 11 May 2012 11:46:41 -0400 Received: by yhoo21 with SMTP id o21so3513708yho.4 for ; Fri, 11 May 2012 08:46:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1336383010-28692-1-git-send-email-agraf@suse.de> Date: Fri, 11 May 2012 16:46:37 +0100 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] linux-user: Fix stale tbs after mmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Riku Voipio , qemu-devel Developers On 7 May 2012 12:38, Alexander Graf wrote: > > On 07.05.2012, at 13:32, Alexander Graf wrote: > >> >> On 07.05.2012, at 12:37, Peter Maydell wrote: >> >>> On 7 May 2012 10:30, Alexander Graf wrote: >>>> @@ -587,6 +587,7 @@ abi_long target_mmap(abi_ulong start, abi_ulong le= n, int prot, >>>> =C2=A0 =C2=A0page_dump(stdout); >>>> =C2=A0 =C2=A0printf("\n"); >>>> #endif >>>> + =C2=A0 =C2=A0tb_invalidate_phys_page_range(start, start + len, 0); >>>> =C2=A0 =C2=A0mmap_unlock(); >>>> =C2=A0 =C2=A0return start; >>> >>> The comment at the top of tb_invalidate_phys_page_range() says >>> "start and end must refer to the same physical page" -- is it >>> out of date or does that not apply to user-mode? >>> >>> Do you need to also invalidate the range on munmap() and >>> mprotect-to-not-executable in order to correctly fault on >>> the case of: >>> map something >>> execute it >>> unmap it >>> try to execute it again >>> >>> ? (haven't tested that case but it seems like it might be an issue) >> >> Yeah, the issue does exist: > > And the below patch on top of my revised patch fixes it. I think these two patches look correct (and as you pointed out on irc I was wrong about mprotect, which effectively already handles flushing the tb if needed). If you can roll them together into a single patch with a commit message and signed-off-by you can add my Reviewed-by: tag to it. thanks -- PMM