qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] f7e6a4: linux-user: move TargetFdTrans functi


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] f7e6a4: linux-user: move TargetFdTrans functions to their ...
Date: Fri, 28 Sep 2018 05:34:58 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: f7e6a401fe3313e6d7dd0c56aa660e684f08e657
      
https://github.com/qemu/qemu/commit/f7e6a401fe3313e6d7dd0c56aa660e684f08e657
  Author: Laurent Vivier <address@hidden>
  Date:   2018-09-25 (Tue, 25 Sep 2018)

  Changed paths:
    M linux-user/Makefile.objs
    A linux-user/fd-trans.c
    A linux-user/fd-trans.h
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: move TargetFdTrans functions to their own file

This will ease to move out syscall functions from syscall.c

Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>


  Commit: 83eb6e509062b8907eb95a00170ef6dde8d264fd
      
https://github.com/qemu/qemu/commit/83eb6e509062b8907eb95a00170ef6dde8d264fd
  Author: Carlo Marcelo Arenas Belón <address@hidden>
  Date:   2018-09-25 (Tue, 25 Sep 2018)

  Changed paths:
    M linux-user/syscall.c
    M linux-user/syscall_defs.h

  Log Message:
  -----------
  linux-user: add SO_LINGER to {g,s}etsockopt

Original implementation for setsockopt by Chen Gang[1]; all bugs mine,
including removing assignment for optname which hopefully makes the
logic easier to follow and moving some variables to make the code
more selfcontained.

[1] http://patchwork.ozlabs.org/patch/565659/

Signed-off-by: Carlo Marcelo Arenas Belón <address@hidden>
Co-Authored-By: Chen Gang <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>


  Commit: 94894ff2d13c85a840f80387c573a34ed6c99063
      
https://github.com/qemu/qemu/commit/94894ff2d13c85a840f80387c573a34ed6c99063
  Author: Shivaprasad G Bhat <address@hidden>
  Date:   2018-09-25 (Tue, 25 Sep 2018)

  Changed paths:
    M linux-user/elfload.c

  Log Message:
  -----------
  linux-user: elf: mmap all the target-pages of hostpage for data segment

If the hostpage size is greater than the TARGET_PAGESIZE, the
target-pages of size TARGET_PAGESIZE are marked valid only till the
length requested during the elfload. The glibc attempts to consume unused
space in the last page of data segment(__libc_memalign() in
elf/dl-minimal.c). If PT_LOAD p_align is greater than or
equal to hostpage size, the GLRO(dl_pagesize) is actually the host pagesize
as set in the auxillary vectors. So, there is no explicit mmap request for
the remaining target-pages on the last hostpage. The glibc assumes that
particular space as available and subsequent attempts to use
those addresses lead to crash as the target_mmap has not marked them valid
for those target-pages.

The issue is seen when trying to chroot to 16.04-x86_64 ubuntu on a PPC64
host where the fork fails to access the thread_id as it is allocated on a
page not marked valid. The recent glibc doesn't have checks for thread-id in
fork, but the issue can manifest somewhere else, none the less.

The fix here is to map all the target-pages of the hostpage during the
elfload if the p_align is greater than or equal to hostpage size, for
data segment to allow the glibc for proper consumption.

Signed-off-by: Shivaprasad G Bhat <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>


  Commit: 58cfa6c2e6eb51b23cc98f81d16136b3ca929b31
      
https://github.com/qemu/qemu/commit/58cfa6c2e6eb51b23cc98f81d16136b3ca929b31
  Author: Tony Garnock-Jones <address@hidden>
  Date:   2018-09-25 (Tue, 25 Sep 2018)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: write(fd, NULL, 0) parity with linux's treatment of same

Bring linux-user write(2) handling into line with linux for the case
of a 0-byte write with a NULL buffer. Based on a patch originally
written by Zhuowei Zhang.

Addresses https://bugs.launchpad.net/qemu/+bug/1716292.

>From Zhuowei Zhang's patch 
>(https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg08073.html):

    Linux returns success for the special case of calling write with a
    zero-length NULL buffer: compiling and running

    int main() {
       ssize_t ret = write(STDOUT_FILENO, NULL, 0);
       fprintf(stderr, "write returned %ld\n", ret);
       return 0;
    }

    gives "write returned 0" when run directly, but "write returned
    -1" in QEMU.

    This commit checks for this situation and returns success if
    found.

Subsequent discussion raised the following questions (and my answers):

 - Q. Should TARGET_NR_read pass through to safe_read in this
      situation too?
   A. I'm wary of changing unrelated code to the specific problem I'm
      addressing. TARGET_NR_read is already consistent with Linux for
      this case.

 - Q. Do pread64/pwrite64 need to be changed similarly?
   A. Experiment suggests not: both linux and linux-user yield -1 for
      NULL 0-length reads/writes.

Signed-off-by: Tony Garnock-Jones <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>


  Commit: 5dfa88f7162f390463b227940e84a23af5407744
      
https://github.com/qemu/qemu/commit/5dfa88f7162f390463b227940e84a23af5407744
  Author: Max Filippov <address@hidden>
  Date:   2018-09-25 (Tue, 25 Sep 2018)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: do setrlimit selectively

setrlimit guest calls that affect memory resources
(RLIMIT_{AS,DATA,STACK}) may interfere with QEMU internal memory
management. They may result in QEMU lockup because mprotect call in
page_unprotect would fail with ENOMEM error code, causing infinite loop
of SIGSEGV. E.g. it happens when running libstdc++ testsuite for xtensa
target on x86_64 host.

Don't call host setrlimit for memory-related resources.

Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Max Filippov <address@hidden>
Message-Id: <address@hidden>
[lv: rebase on master]
Signed-off-by: Laurent Vivier <address@hidden>


  Commit: aa8e26de9617756febcbf794dda965df307fdaaa
      
https://github.com/qemu/qemu/commit/aa8e26de9617756febcbf794dda965df307fdaaa
  Author: Peter Maydell <address@hidden>
  Date:   2018-09-28 (Fri, 28 Sep 2018)

  Changed paths:
    M linux-user/Makefile.objs
    M linux-user/elfload.c
    A linux-user/fd-trans.c
    A linux-user/fd-trans.h
    M linux-user/syscall.c
    M linux-user/syscall_defs.h

  Log Message:
  -----------
  Merge remote-tracking branch 
'remotes/vivier2/tags/linux-user-for-3.1-pull-request' into staging

- some fixes for setrlimit() and write()
- fixes ELF loader when host page size is greater than target page size
- add SO_LINGER to getsockopt()/setsockopt()
- move TargetFdTrans from syscall.c
  v2: add "#include <linux/netlink.h>" in linux-user/fd-trans.c

# gpg: Signature made Tue 25 Sep 2018 21:51:13 BST
# gpg:                using RSA key F30C38BD3F2FBE3C
# gpg: Good signature from "Laurent Vivier <address@hidden>"
# gpg:                 aka "Laurent Vivier <address@hidden>"
# gpg:                 aka "Laurent Vivier (Red Hat) <address@hidden>"
# Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F  5173 F30C 38BD 3F2F BE3C

* remotes/vivier2/tags/linux-user-for-3.1-pull-request:
  linux-user: do setrlimit selectively
  linux-user: write(fd, NULL, 0) parity with linux's treatment of same
  linux-user: elf: mmap all the target-pages of hostpage for data segment
  linux-user: add SO_LINGER to {g,s}etsockopt
  linux-user: move TargetFdTrans functions to their own file

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/866ba8385466...aa8e26de9617
      **NOTE:** This service has been marked for deprecation: 
https://developer.github.com/changes/2018-04-25-github-services-deprecation/

      Functionality will be removed from GitHub.com on January 31st, 2019.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]