[Qemu-commits] [qemu/qemu] 4a5457: linux-user: ppc64: use the correct values for F_*L...

[GitHub]

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 4a5457616d5b3116a8ae76748f9c493a4b9e07f0
      
https://github.com/qemu/qemu/commit/4a5457616d5b3116a8ae76748f9c493a4b9e07f0
  Author: Shivaprasad G Bhat <address@hidden>
  Date:   2018-07-15 (Sun, 15 Jul 2018)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: ppc64: use the correct values for F_*LK64s

Qemu includes the glibc headers for the host defines and target headers are
part of the qemu source themselves. The glibc has the F_GETLK64, F_SETLK64
and F_SETLKW64 defined to 12, 13 and 14 for all archs in
sysdeps/unix/sysv/linux/bits/fcntl-linux.h. The linux kernel generic
definition for F_*LK is 5, 6 & 7 and F_*LK64* is 12,13, and 14 as seen in
include/uapi/asm-generic/fcntl.h. On 64bit machine, by default the kernel
assumes all F_*LK to 64bit calls and doesnt support use of F_*LK64* as
can be seen in include/linux/fcntl.h in linux source.

On x86_64 host, the values for F_*LK64* are set to 5, 6 and 7
explicitly in /usr/include/x86_64-linux-gnu/bits/fcntl.h by the glibc.
Whereas, a PPC64 host doesn't have such a definition in
/usr/include/powerpc64le-linux-gnu/bits/fcntl.h by the glibc. So,
the sources on PPC64 host sees the default value of F_*LK64*
as 12, 13 & 14(fcntl-linux.h).

Since the 64bit kernel doesnt support 12, 13 & 14; the glibc fcntl syscall
implementation(__libc_fcntl*(), __fcntl64_nocancel) does the F_*LK64* value
convertion back to F_*LK* values on PPC64 as seen in
sysdeps/unix/sysv/linux/powerpc/powerpc64/sysdep.h with FCNTL_ADJUST_CMD()
macro. Whereas on x86_64 host the values for F_*LK64* are set to 5, 6 and 7
and no adjustments are needed.

Since qemu doesnt use the glibc fcntl, but makes the safe_syscall* on its
own, the PPC64 qemu is calling the syscall with 12, 13, and 14(without
adjustment) and they all fail. The fcntl calls to F_GETLK/F_SETLK|W all
fail by all pplications run on PPC64 host user emulation.

The fix here could be to see why on PPC64 the glibc is still keeping
F_*LK64* different from F_*LK and why adjusting them to 5, 6 and 7 before
the syscall for PPC only. See if we can make the
/usr/include/powerpc64le-linux-gnu/bits/fcntl.h to have the values
5, 6 & 7 just like x86_64 and remove the adjustment code in glibc. That
way, qemu sources see the kernel supported values in glibc headers.

OR

On PPC64 host, qemu sources see both F_*LK & F_*LK64* as same and set to
12, 13 and 14 because __USE_FILE_OFFSET64 is defined in qemu
sources(also refer sysdeps/unix/sysv/linux/bits/fcntl-linux.h).
Do the value adjustment just like it is done by glibc source by using
F_GETLK value of 5. That way, we make the syscalls with the actual
supported values in Qemu. The patch is taking this approach.

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


  Commit: af8ab2bf223e1e4406108708b47476ef0d148a52
      
https://github.com/qemu/qemu/commit/af8ab2bf223e1e4406108708b47476ef0d148a52
  Author: Laurent Vivier <address@hidden>
  Date:   2018-07-15 (Sun, 15 Jul 2018)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  linux-user: convert remaining fcntl() to safe_fcntl()

Commit 435da5e709 didn't convert a fcntl() call to safe_fcntl()
for TARGET_NR_fcntl64 case. There is no reason to not use it
in this case.

Fixes: 435da5e709 linux-user: Use safe_syscall wrapper for fcntl
Signed-off-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>


  Commit: dc18baaef36d95e5a7b4fbc60daff3d92afe737c
      
https://github.com/qemu/qemu/commit/dc18baaef36d95e5a7b4fbc60daff3d92afe737c
  Author: Laurent Vivier <address@hidden>
  Date:   2018-07-15 (Sun, 15 Jul 2018)

  Changed paths:
    M linux-user/main.c

  Log Message:
  -----------
  linux-user: fix mmap_find_vma_reserved()

The value given by mmap_find_vma_reserved() is used with mmap(),
so it is needed to be aligned with the host page size.

Since commit 18e80c55bb, reserved_va is only aligned to TARGET_PAGE_SIZE,
and it works well if this size is greater or equal to the host page size.

But ppc64 hosts have 64kB page size and when we start a 4kiB page size
guest (like i386), it fails when it tries to mmap the stack:

    mmap stack: Invalid argument

Fixes: 18e80c55bb (linux-user: Tidy and enforce reserved_va initialization)
Signed-off-by: Laurent Vivier <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-Id: <address@hidden>


  Commit: 1d3d1b23e1c8f52ec431ddaa8deea1322bc25cbf
      
https://github.com/qemu/qemu/commit/1d3d1b23e1c8f52ec431ddaa8deea1322bc25cbf
  Author: Jonas Schievink <address@hidden>
  Date:   2018-07-15 (Sun, 15 Jul 2018)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  -----------
  Zero out the host's `msg_control` buffer

If this is not done, qemu would drop any control message after the first
one.

This is because glibc's `CMSG_NXTHDR` macro accesses the uninitialized
cmsghdr's length field in order to find out if the message fits into the
`msg_control` buffer, wrongly assuming that it doesn't because the
length field contains garbage. Accessing the length field is fine for
completed messages we receive from the kernel, but is - as far as I know
- not needed since the kernel won't return such an invalid cmsghdr in
the first place.

This is tracked as this glibc bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=13500

It's probably also a good idea to bail with an error if `CMSG_NXTHDR`
returns NULL but `TARGET_CMSG_NXTHDR` doesn't (ie. we still expect
cmsgs).

Signed-off-by: Jonas Schievink <address@hidden>
Reviewed-by: Laurent Vivier <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Laurent Vivier <address@hidden>


  Commit: b808d2001d41352948f84affa62be66910537107
      
https://github.com/qemu/qemu/commit/b808d2001d41352948f84affa62be66910537107
  Author: Peter Maydell <address@hidden>
  Date:   2018-07-16 (Mon, 16 Jul 2018)

  Changed paths:
    M linux-user/main.c
    M linux-user/syscall.c

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

Some fixes for linux-user:
- workaround for CMSG_NXTHDR bug
- two patches for ppc64/ppc64le host:
  fix fcntl() with *LK64 commands
  (seen when dpkg wants to lock the DB)
  fix reserved_va alignment (ppc64 needs
  a 64kB alignment)
- convert a forgotten fcntl() to safe_fcntl()

# gpg: Signature made Sun 15 Jul 2018 20:51:19 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.0-pull-request:
  Zero out the host's `msg_control` buffer
  linux-user: fix mmap_find_vma_reserved()
  linux-user: convert remaining fcntl() to safe_fcntl()
  linux-user: ppc64: use the correct values for F_*LK64s

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


Compare: https://github.com/qemu/qemu/compare/9277d81f5c2c...b808d2001d41
      **NOTE:** This service 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.