[Bug network/19682] s390x: Incorrect syscall definitions cause breakage with Linux 4.3 headers

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19682

--- Comment #8 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, gentoo/2.22 has been updated
       via  3f749c2e7b8226eb8c6f16fb180987dc7efe35ba (commit)
       via  1fd66a522e9262d7ff36b015090f3989f93ba468 (commit)
       via  78b80a22769f07fcd83763d5b8b3625fe4920574 (commit)
       via  e012eafca47020da292f828fe128f3aca50026e1 (commit)
      from  258e9043d8f1a2dafac3754c651b46da1ccb7dba (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=3f749c2e7b8226eb8c6f16fb180987dc7efe35ba

commit 3f749c2e7b8226eb8c6f16fb180987dc7efe35ba
Author: Hongjiu Zhang <noctuorare@gmail.com>
Date:   Sun Mar 6 20:18:21 2016 -0500

    sln: use stat64

    When using sln on some filesystems which return 64-bit inodes,
    the stat call might fail during install like so:
        .../elf/sln .../elf/symlink.list
        /lib32/libc.so.6: invalid destination: Value too large for defined data
type
        /lib32/ld-linux.so.2: invalid destination: Value too large for defined
data type
        Makefile:104: recipe for target 'install-symbolic-link' failed

    Switch to using stat64 all the time to avoid this.

    URL: https://bugs.gentoo.org/576396
    (cherry picked from commit f5e753c8c3a18a1e3c715dd11bf4dc341b5c481f)
    (cherry picked from commit d6778fc4b0039b2116f88218212618ca357fee2f)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1fd66a522e9262d7ff36b015090f3989f93ba468

commit 1fd66a522e9262d7ff36b015090f3989f93ba468
Author: Stefan Liebler <stli@linux.vnet.ibm.com>
Date:   Thu Mar 3 08:17:09 2016 +0100

    S390: Do not use direct socket syscalls if build on kernels >= 4.3. [BZ
#19682]

    Beginning with Linux 4.3, the kernel headers contain direct
    system call numbers __NR_socket etc. on s390x. On older kernels,
    the socket-multiplexer syscall __NR_socketcall was used.

    To enable these new syscalls, the patch
    "S390: Call direct system calls for socket operations."
   
(https://sourceware.org/git/?p=glibc.git;a=commit;h=016495b818cb61df7d0d10e6db54074271b3e3a5)
    was applied upstream.

    If glibc 2.23 is configured with --enable-kernel=4.3 and newer,
    the direct socket syscalls are used.
    For older kernels, the socket-multiplexer syscall is used instead.

    In glibc 2.22 and earlier, this patch is not applied.
    If you build glibc on a kernel < 4.3, the socket-multiplexer
    syscall is used. But if you build glibc on kernel >= 4.3, the
    direct socket-syscalls are used. If you install this glibc on a
    kernel < 4.3, all socket operations will fail.
    See "Bug 19682 - s390x: Incorrect syscall definitions cause
    breakage with Linux 4.3 headers"
    (https://sourceware.org/bugzilla/show_bug.cgi?id=19682)
    The configure switch --enable-kernel does not influence this
    behaviour on older glibc-releases.

    The solution is to remove the direct socket-syscalls in
    sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list
    (this patch) on older glibc-releases as it was done by the
    upstream patch, too. These entries were never used on s390x,
    but the c-files in sysdeps/unix/sysv/linux/.
    After this removal, the behaviour of the socket functions are
    not changed compared to the original glibc release version
    and the socket-multiplexer-syscall is always used.

    (cherry picked from commit 425c48c217ef93c2c4f81f9f3bb2fdba096877a2)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=78b80a22769f07fcd83763d5b8b3625fe4920574

commit 78b80a22769f07fcd83763d5b8b3625fe4920574
Author: Paul E. Murphy <murphyp@linux.vnet.ibm.com>
Date:   Wed Jan 20 10:33:19 2016 -0600

    powerpc: Fix macro usage of htm builtins

    Some extraneous semicolons were included in a
    recent patch which causes a build failure with
    newer compilers.

    (cherry picked from commit af8ea0f449af7d3847351a4a5bafcd435a22ac31)
    (cherry picked from commit a33d347c181cfa0d84c37e9961ebf030495ed248)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=e012eafca47020da292f828fe128f3aca50026e1

commit e012eafca47020da292f828fe128f3aca50026e1
Author: Tulio Magno Quites Machado Filho <tuliom@linux.vnet.ibm.com>
Date:   Mon Dec 28 12:24:43 2015 -0200

    powerpc: Enforce compiler barriers on hardware transactions

    Work around a GCC behavior with hardware transactional memory built-ins.
    GCC doesn't treat the PowerPC transactional built-ins as compiler
    barriers, moving instructions past the transaction boundaries and
    altering their atomicity.

    (cherry picked from commit 42bf1c897170ff951c7fd0ee9da25f97ff787396)

    Conflicts:
        sysdeps/unix/sysv/linux/powerpc/elision-trylock.c

    (cherry picked from commit 3803874b4a368eb8245fbf091651b6c8edd90b23)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog                                          |    5 +++
 elf/sln.c                                          |    4 +-
 sysdeps/powerpc/nptl/elide.h                       |    8 ++--
 sysdeps/powerpc/sysdep.h                           |    2 +-
 sysdeps/unix/sysv/linux/powerpc/elision-lock.c     |    4 +-
 sysdeps/unix/sysv/linux/powerpc/elision-trylock.c  |    6 ++--
 sysdeps/unix/sysv/linux/powerpc/elision-unlock.c   |    2 +-
 sysdeps/unix/sysv/linux/powerpc/htm.h              |   39 ++++++++++++++++++--
 sysdeps/unix/sysv/linux/s390/s390-64/syscalls.list |   19 ----------
 9 files changed, 53 insertions(+), 36 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.