Message ID | 5673ACFA.6060900@emindsoft.com.cn |
---|---|
State | New |
Headers | show |
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
On 2015年12月18日 17:41, Laurent Vivier wrote: > > > 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. > OK, Thanks.
On 2015年12月18日 18:47, Chen Gang wrote: > > On 2015年12月18日 17:41, Laurent Vivier wrote: >> >> Le 18/12/2015 07:51, Chen Gang a écrit : [...] >>> >>> +++ 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. >> Oh, sorry, after check again, it is not kernel's issue: mmap() will always zero the ANONYMOUS memory for kernel 3.8 in sw_64 arch. It is still our qemu's issue in mmap_frag (do not zero ANONYMOUS memory fragments), so I sent patch v2 for it, please help check. Thanks. > > OK, Thanks. > >
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); + } mmap_unlock(); return start; fail: