From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:37383)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <laurent@vivier.eu>) id 1a9rXg-0004ZF-VI
	for qemu-devel@nongnu.org; Fri, 18 Dec 2015 04:41:41 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <laurent@vivier.eu>) id 1a9rXe-0001MQ-90
	for qemu-devel@nongnu.org; Fri, 18 Dec 2015 04:41:40 -0500
Received: from mout.kundenserver.de ([212.227.17.24]:54422)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <laurent@vivier.eu>) id 1a9rXd-0001MA-Vf
	for qemu-devel@nongnu.org; Fri, 18 Dec 2015 04:41:38 -0500
References: <5673A718.40103@emindsoft.com.cn>
	<5673ACFA.6060900@emindsoft.com.cn>
From: Laurent Vivier <laurent@vivier.eu>
Message-ID: <5673D4BD.4080305@vivier.eu>
Date: Fri, 18 Dec 2015 10:41:17 +0100
MIME-Version: 1.0
In-Reply-To: <5673ACFA.6060900@emindsoft.com.cn>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [Qemu-devel] [PATCH] linux-user/syscall.c: Notice about lock
 bitmask translation for fcntl
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Chen Gang <chengang@emindsoft.com.cn>, riku.voipio@iki.fi
Cc: Peter Maydell <peter.maydell@linaro.org>, qemu-devel <qemu-devel@nongnu.org>, Richard Henderson <rth@twiddle.net>



Le 18/12/2015 07:51, Chen Gang a écrit :
> 
> I found this issue during my working time, it is about sw_64 (almost the
> same as alpha) host running i386 wine programs.
> 
> I also found another issue, but I am not quite sure whether it is worth
> enough for our upstream: The related fix patch is below, which will let
> the initialization slower, but for most archs, they have no this issue.
> 
>     linux-user/mmap.c: Always zero MAP_ANONYMOUS memory in target_mmap()
>     
>     In some architectures, they have no policy to zero MAP_ANONYMOUS memory,
>     which will cause issue for qemu target_mmap.
>     
>     Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
> 
> diff --git a/linux-user/mmap.c b/linux-user/mmap.c
> index 7b459d5..9c9152d 100644
> --- a/linux-user/mmap.c
> +++ b/linux-user/mmap.c
> @@ -567,6 +567,10 @@ abi_long target_mmap(abi_ulong start, abi_ulong len, int prot,
>      printf("\n");
>  #endif
>      tb_invalidate_phys_range(start, start + len);
> +    if ((prot & PROT_WRITE) && (flags & MAP_ANONYMOUS)
> +        && ((flags & MAP_PRIVATE) || (fd == -1))) {
> +        memset(g2h(start), 0, len);
> +    }

IMHO, their kernel needs a fix, mmap(2):

MAP_ANONYMOUS
        The mapping is not backed by any file; its contents are initial‐
        ized to zero.


>      mmap_unlock();
>      return start;
>  fail:
> 
> 
> Thanks.

Laurent