24 Apr, 2019

1 commit

  • Pull syscall numbering updates from Arnd Bergmann:
    "arch: add pidfd and io_uring syscalls everywhere

    This comes a bit late, but should be in 5.1 anyway: we want the newly
    added system calls to be synchronized across all architectures in the
    release.

    I hope that in the future, any newly added system calls can be added
    to all architectures at the same time, and tested there while they are
    in linux-next, avoiding dependencies between the architecture
    maintainer trees and the tree that contains the new system call"

    * tag 'syscalls-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic:
    arch: add pidfd and io_uring syscalls everywhere

    Linus Torvalds
     

15 Apr, 2019

1 commit

  • Add the io_uring and pidfd_send_signal system calls to all architectures.

    These system calls are designed to handle both native and compat tasks,
    so all entries are the same across architectures, only arm-compat and
    the generic tale still use an old format.

    Acked-by: Michael Ellerman (powerpc)
    Acked-by: Heiko Carstens (s390)
    Acked-by: Geert Uytterhoeven
    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

05 Apr, 2019

2 commits

  • After removing the start and count arguments of syscall_get_arguments() it
    seems reasonable to remove them from syscall_set_arguments(). Note, as of
    today, there are no users of syscall_set_arguments(). But we are told that
    there will be soon. But for now, at least make it consistent with
    syscall_get_arguments().

    Link: http://lkml.kernel.org/r/20190327222014.GA32540@altlinux.org

    Cc: Oleg Nesterov
    Cc: Kees Cook
    Cc: Andy Lutomirski
    Cc: Dominik Brodowski
    Cc: Dave Martin
    Cc: "Dmitry V. Levin"
    Cc: x86@kernel.org
    Cc: linux-snps-arc@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-c6x-dev@linux-c6x.org
    Cc: uclinux-h8-devel@lists.sourceforge.jp
    Cc: linux-hexagon@vger.kernel.org
    Cc: linux-ia64@vger.kernel.org
    Cc: linux-mips@vger.kernel.org
    Cc: nios2-dev@lists.rocketboards.org
    Cc: openrisc@lists.librecores.org
    Cc: linux-parisc@vger.kernel.org
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: linux-riscv@lists.infradead.org
    Cc: linux-s390@vger.kernel.org
    Cc: linux-sh@vger.kernel.org
    Cc: sparclinux@vger.kernel.org
    Cc: linux-um@lists.infradead.org
    Cc: linux-xtensa@linux-xtensa.org
    Cc: linux-arch@vger.kernel.org
    Acked-by: Max Filippov # For xtensa changes
    Acked-by: Will Deacon # For the arm64 bits
    Reviewed-by: Thomas Gleixner # for x86
    Reviewed-by: Dmitry V. Levin
    Signed-off-by: Steven Rostedt (VMware)

    Steven Rostedt (VMware)
     
  • At Linux Plumbers, Andy Lutomirski approached me and pointed out that the
    function call syscall_get_arguments() implemented in x86 was horribly
    written and not optimized for the standard case of passing in 0 and 6 for
    the starting index and the number of system calls to get. When looking at
    all the users of this function, I discovered that all instances pass in only
    0 and 6 for these arguments. Instead of having this function handle
    different cases that are never used, simply rewrite it to return the first 6
    arguments of a system call.

    This should help out the performance of tracing system calls by ptrace,
    ftrace and perf.

    Link: http://lkml.kernel.org/r/20161107213233.754809394@goodmis.org

    Cc: Oleg Nesterov
    Cc: Kees Cook
    Cc: Andy Lutomirski
    Cc: Dominik Brodowski
    Cc: Dave Martin
    Cc: "Dmitry V. Levin"
    Cc: x86@kernel.org
    Cc: linux-snps-arc@lists.infradead.org
    Cc: linux-kernel@vger.kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: linux-c6x-dev@linux-c6x.org
    Cc: uclinux-h8-devel@lists.sourceforge.jp
    Cc: linux-hexagon@vger.kernel.org
    Cc: linux-ia64@vger.kernel.org
    Cc: linux-mips@vger.kernel.org
    Cc: nios2-dev@lists.rocketboards.org
    Cc: openrisc@lists.librecores.org
    Cc: linux-parisc@vger.kernel.org
    Cc: linuxppc-dev@lists.ozlabs.org
    Cc: linux-riscv@lists.infradead.org
    Cc: linux-s390@vger.kernel.org
    Cc: linux-sh@vger.kernel.org
    Cc: sparclinux@vger.kernel.org
    Cc: linux-um@lists.infradead.org
    Cc: linux-xtensa@linux-xtensa.org
    Cc: linux-arch@vger.kernel.org
    Acked-by: Paul Burton # MIPS parts
    Acked-by: Max Filippov # For xtensa changes
    Acked-by: Will Deacon # For the arm64 bits
    Reviewed-by: Thomas Gleixner # for x86
    Reviewed-by: Dmitry V. Levin
    Reported-by: Andy Lutomirski
    Signed-off-by: Steven Rostedt (VMware)

    Steven Rostedt (Red Hat)
     

29 Mar, 2019

1 commit

  • I do not see any consistency about headers_install of
    and .

    According to my analysis of Linux 5.1-rc1, there are 3 groups:

    [1] Both and are exported

    alpha, arm, hexagon, mips, powerpc, s390, sparc, x86

    [2] is exported, but is not

    arc, arm64, c6x, h8300, ia64, m68k, microblaze, nios2, openrisc,
    parisc, sh, unicore32, xtensa

    [3] Neither nor is exported

    csky, nds32, riscv

    This does not match to the actual KVM support. At least, [2] is
    half-baked.

    Nor do arch maintainers look like they care about this. For example,
    commit 0add53713b1c ("microblaze: Add missing kvm_para.h to Kbuild")
    exported to user-space in order to fix an in-kernel
    build error.

    We have two ways to make this consistent:

    [A] export both and for all
    architectures, irrespective of the KVM support

    [B] Match the header export of and
    to the KVM support

    My first attempt was [A] because the code looks cleaner, but Paolo
    suggested [B].

    So, this commit goes with [B].

    For most architectures, was moved to the kernel-space.
    I changed include/uapi/linux/Kbuild so that it checks generated
    asm/kvm_para.h as well as check-in ones.

    After this commit, there will be two groups:

    [1] Both and are exported

    arm, arm64, mips, powerpc, s390, x86

    [2] Neither nor is exported

    alpha, arc, c6x, csky, h8300, hexagon, ia64, m68k, microblaze,
    nds32, nios2, openrisc, parisc, riscv, sh, sparc, unicore32, xtensa

    Signed-off-by: Masahiro Yamada
    Acked-by: Cornelia Huck
    Signed-off-by: Paolo Bonzini

    Masahiro Yamada
     

18 Mar, 2019

1 commit

  • Pull more Kbuild updates from Masahiro Yamada:

    - add more Build-Depends to Debian source package

    - prefix header search paths with $(srctree)/

    - make modpost show verbose section mismatch warnings

    - avoid hard-coded CROSS_COMPILE for h8300

    - fix regression for Debian make-kpkg command

    - add semantic patch to detect missing put_device()

    - fix some warnings of 'make deb-pkg'

    - optimize NOSTDINC_FLAGS evaluation

    - add warnings about redundant generic-y

    - clean up Makefiles and scripts

    * tag 'kbuild-v5.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
    kconfig: remove stale lxdialog/.gitignore
    kbuild: force all architectures except um to include mandatory-y
    kbuild: warn redundant generic-y
    Revert "modsign: Abort modules_install when signing fails"
    kbuild: Make NOSTDINC_FLAGS a simply expanded variable
    kbuild: deb-pkg: avoid implicit effects
    coccinelle: semantic code search for missing put_device()
    kbuild: pkg: grep include/config/auto.conf instead of $KCONFIG_CONFIG
    kbuild: deb-pkg: introduce is_enabled and if_enabled_echo to builddeb
    kbuild: deb-pkg: add CONFIG_ prefix to kernel config options
    kbuild: add workaround for Debian make-kpkg
    kbuild: source include/config/auto.conf instead of ${KCONFIG_CONFIG}
    unicore32: simplify linker script generation for decompressor
    h8300: use cc-cross-prefix instead of hardcoding h8300-unknown-linux-
    kbuild: move archive command to scripts/Makefile.lib
    modpost: always show verbose warning for section mismatch
    ia64: prefix header search path with $(srctree)/
    libfdt: prefix header search paths with $(srctree)/
    deb-pkg: generate correct build dependencies

    Linus Torvalds
     

17 Mar, 2019

1 commit

  • Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes
    the common Kbuild.asm file. Factor out the duplicated include directives
    to scripts/Makefile.asm-generic so that no architecture would opt out
    of the mandatory-y mechanism.

    um is not forced to include mandatory-y since it is a very exceptional
    case which does not support UAPI.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

15 Mar, 2019

1 commit


13 Mar, 2019

2 commits

  • Add check for the return value of memblock_alloc*() functions and call
    panic() in case of error. The panic message repeats the one used by
    panicing memblock allocators with adjustment of parameters to include
    only relevant ones.

    The replacement was mostly automated with semantic patches like the one
    below with manual massaging of format strings.

    @@
    expression ptr, size, align;
    @@
    ptr = memblock_alloc(size, align);
    + if (!ptr)
    + panic("%s: Failed to allocate %lu bytes align=0x%lx\n", __func__, size, align);

    [anders.roxell@linaro.org: use '%pa' with 'phys_addr_t' type]
    Link: http://lkml.kernel.org/r/20190131161046.21886-1-anders.roxell@linaro.org
    [rppt@linux.ibm.com: fix format strings for panics after memblock_alloc]
    Link: http://lkml.kernel.org/r/1548950940-15145-1-git-send-email-rppt@linux.ibm.com
    [rppt@linux.ibm.com: don't panic if the allocation in sparse_buffer_init fails]
    Link: http://lkml.kernel.org/r/20190131074018.GD28876@rapoport-lnx
    [akpm@linux-foundation.org: fix xtensa printk warning]
    Link: http://lkml.kernel.org/r/1548057848-15136-20-git-send-email-rppt@linux.ibm.com
    Signed-off-by: Mike Rapoport
    Signed-off-by: Anders Roxell
    Reviewed-by: Guo Ren [c-sky]
    Acked-by: Paul Burton [MIPS]
    Acked-by: Heiko Carstens [s390]
    Reviewed-by: Juergen Gross [Xen]
    Reviewed-by: Geert Uytterhoeven [m68k]
    Acked-by: Max Filippov [xtensa]
    Cc: Catalin Marinas
    Cc: Christophe Leroy
    Cc: Christoph Hellwig
    Cc: "David S. Miller"
    Cc: Dennis Zhou
    Cc: Greentime Hu
    Cc: Greg Kroah-Hartman
    Cc: Guan Xuetao
    Cc: Guo Ren
    Cc: Mark Salter
    Cc: Matt Turner
    Cc: Michael Ellerman
    Cc: Michal Simek
    Cc: Petr Mladek
    Cc: Richard Weinberger
    Cc: Rich Felker
    Cc: Rob Herring
    Cc: Rob Herring
    Cc: Russell King
    Cc: Stafford Horne
    Cc: Tony Luck
    Cc: Vineet Gupta
    Cc: Yoshinori Sato
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     
  • memblock_alloc() already clears the allocated memory, no point in doing
    it twice.

    Link: http://lkml.kernel.org/r/1548057848-15136-14-git-send-email-rppt@linux.ibm.com
    Signed-off-by: Mike Rapoport
    Acked-by: Geert Uytterhoeven [m68k]
    Cc: Catalin Marinas
    Cc: Christophe Leroy
    Cc: Christoph Hellwig
    Cc: "David S. Miller"
    Cc: Dennis Zhou
    Cc: Greentime Hu
    Cc: Greg Kroah-Hartman
    Cc: Guan Xuetao
    Cc: Guo Ren
    Cc: Guo Ren [c-sky]
    Cc: Heiko Carstens
    Cc: Juergen Gross [Xen]
    Cc: Mark Salter
    Cc: Matt Turner
    Cc: Max Filippov
    Cc: Michael Ellerman
    Cc: Michal Simek
    Cc: Paul Burton
    Cc: Petr Mladek
    Cc: Richard Weinberger
    Cc: Rich Felker
    Cc: Rob Herring
    Cc: Rob Herring
    Cc: Russell King
    Cc: Stafford Horne
    Cc: Tony Luck
    Cc: Vineet Gupta
    Cc: Yoshinori Sato
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     

08 Mar, 2019

1 commit

  • Rather than use the memblock_alloc_base that returns a physical address
    and then convert this address to the virtual one, use appropriate
    memblock function that returns a virtual address.

    Link: http://lkml.kernel.org/r/1546248566-14910-3-git-send-email-rppt@linux.ibm.com
    Signed-off-by: Mike Rapoport
    Tested-by: Michal Simek
    Cc: Arnd Bergmann
    Cc: Benjamin Herrenschmidt
    Cc: Christoph Hellwig
    Cc: "David S. Miller"
    Cc: Greentime Hu
    Cc: Guan Xuetao
    Cc: Heiko Carstens
    Cc: Jonas Bonn
    Cc: Mark Salter
    Cc: Martin Schwidefsky
    Cc: Michael Ellerman
    Cc: Michal Hocko
    Cc: Michal Simek
    Cc: Paul Mackerras
    Cc: Rich Felker
    Cc: Russell King
    Cc: Stafford Horne
    Cc: Stefan Kristiansson
    Cc: Vincent Chen
    Cc: Yoshinori Sato
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     

06 Mar, 2019

1 commit

  • Pull year 2038 updates from Thomas Gleixner:
    "Another round of changes to make the kernel ready for 2038. After lots
    of preparatory work this is the first set of syscalls which are 2038
    safe:

    403 clock_gettime64
    404 clock_settime64
    405 clock_adjtime64
    406 clock_getres_time64
    407 clock_nanosleep_time64
    408 timer_gettime64
    409 timer_settime64
    410 timerfd_gettime64
    411 timerfd_settime64
    412 utimensat_time64
    413 pselect6_time64
    414 ppoll_time64
    416 io_pgetevents_time64
    417 recvmmsg_time64
    418 mq_timedsend_time64
    419 mq_timedreceiv_time64
    420 semtimedop_time64
    421 rt_sigtimedwait_time64
    422 futex_time64
    423 sched_rr_get_interval_time64

    The syscall numbers are identical all over the architectures"

    * 'timers-2038-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
    riscv: Use latest system call ABI
    checksyscalls: fix up mq_timedreceive and stat exceptions
    unicore32: Fix __ARCH_WANT_STAT64 definition
    asm-generic: Make time32 syscall numbers optional
    asm-generic: Drop getrlimit and setrlimit syscalls from default list
    32-bit userspace ABI: introduce ARCH_32BIT_OFF_T config option
    compat ABI: use non-compat openat and open_by_handle_at variants
    y2038: add 64-bit time_t syscalls to all 32-bit architectures
    y2038: rename old time and utime syscalls
    y2038: remove struct definition redirects
    y2038: use time32 syscall names on 32-bit
    syscalls: remove obsolete __IGNORE_ macros
    y2038: syscalls: rename y2038 compat syscalls
    x86/x32: use time64 versions of sigtimedwait and recvmmsg
    timex: change syscalls to use struct __kernel_timex
    timex: use __kernel_timex internally
    sparc64: add custom adjtimex/clock_adjtime functions
    time: fix sys_timer_settime prototype
    time: Add struct __kernel_timex
    time: make adjtime compat handling available for 32 bit
    ...

    Linus Torvalds
     

05 Mar, 2019

1 commit

  • Every in-kernel use of this function defined it to KERNEL_DS (either as
    an actual define, or as an inline function). It's an entirely
    historical artifact, and long long long ago used to actually read the
    segment selector valueof '%ds' on x86.

    Which in the kernel is always KERNEL_DS.

    Inspired by a patch from Jann Horn that just did this for a very small
    subset of users (the ones in fs/), along with Al who suggested a script.
    I then just took it to the logical extreme and removed all the remaining
    gunk.

    Roughly scripted with

    git grep -l '(get_ds())' -- :^tools/ | xargs sed -i 's/(get_ds())/(KERNEL_DS)/'
    git grep -lw 'get_ds' -- :^tools/ | xargs sed -i '/^#define get_ds()/d'

    plus manual fixups to remove a few unusual usage patterns, the couple of
    inline function cases and to fix up a comment that had become stale.

    The 'get_ds()' function remains in an x86 kvm selftest, since in user
    space it actually does something relevant.

    Inspired-by: Jann Horn
    Inspired-by: Al Viro
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

28 Feb, 2019

1 commit

  • …rnd/playground into timers/2038

    Pull additional syscall ABI cleanup for y2038 from Arnd Bergmann:

    This is a follow-up to the y2038 syscall patches already merged in the tip
    tree. As the final 32-bit RISC-V syscall ABI is still being decided on,
    this is the last chance to make a few corrections to leave out interfaces
    based on 32-bit time_t along with the old off_t and rlimit types.

    The series achieves this in a few steps:

    - A couple of bug fixes for minor regressions I introduced
    in the original series

    - A couple of older patches from Yury Norov that I had never
    merged in the past, these fix up the openat/open_by_handle_at and
    getrlimit/setrlimit syscalls to disallow the old versions of off_t
    and rlimit.

    - Hiding the deprecated system calls behind an #ifdef in
    include/uapi/asm-generic/unistd.h

    - Change arch/riscv to drop all these ABIs.

    Originally, the plan was to also leave these out on C-Sky, but that now
    has a glibc port that uses the older interfaces, so we need to leave
    them in place.

    Thomas Gleixner
     

19 Feb, 2019

1 commit

  • All new 32-bit architectures should have 64-bit userspace off_t type, but
    existing architectures has 32-bit ones.

    To enforce the rule, new config option is added to arch/Kconfig that defaults
    ARCH_32BIT_OFF_T to be disabled for new 32-bit architectures. All existing
    32-bit architectures enable it explicitly.

    New option affects force_o_largefile() behaviour. Namely, if userspace
    off_t is 64-bits long, we have no reason to reject user to open big files.

    Note that even if architectures has only 64-bit off_t in the kernel
    (arc, c6x, h8300, hexagon, nios2, openrisc, and unicore32),
    a libc may use 32-bit off_t, and therefore want to limit the file size
    to 4GB unless specified differently in the open flags.

    Signed-off-by: Yury Norov
    Acked-by: Arnd Bergmann
    Signed-off-by: Yury Norov
    Signed-off-by: Arnd Bergmann

    Yury Norov
     

11 Feb, 2019

2 commits

  • …/arnd/playground into timers/2038

    Pull y2038 - time64 system calls from Arnd Bergmann:

    This series finally gets us to the point of having system calls with 64-bit
    time_t on all architectures, after a long time of incremental preparation
    patches.

    There was actually one conversion that I missed during the summer,
    i.e. Deepa's timex series, which I now updated based the 5.0-rc1 changes
    and review comments.

    The following system calls are now added on all 32-bit architectures using
    the same system call numbers:

    403 clock_gettime64
    404 clock_settime64
    405 clock_adjtime64
    406 clock_getres_time64
    407 clock_nanosleep_time64
    408 timer_gettime64
    409 timer_settime64
    410 timerfd_gettime64
    411 timerfd_settime64
    412 utimensat_time64
    413 pselect6_time64
    414 ppoll_time64
    416 io_pgetevents_time64
    417 recvmmsg_time64
    418 mq_timedsend_time64
    419 mq_timedreceiv_time64
    420 semtimedop_time64
    421 rt_sigtimedwait_time64
    422 futex_time64
    423 sched_rr_get_interval_time64

    Each one of these corresponds directly to an existing system call that
    includes a 'struct timespec' argument, or a structure containing a timespec
    or (in case of clock_adjtime) timeval. Not included here are new versions
    of getitimer/setitimer and getrusage/waitid, which are planned for the
    future but only needed to make a consistent API rather than for correct
    operation beyond y2038. These four system calls are based on 'timeval', and
    it has not been finally decided what the replacement kernel interface will
    use instead.

    So far, I have done a lot of build testing across most architectures, which
    has found a number of bugs. Runtime testing so far included testing LTP on
    32-bit ARM with the existing system calls, to ensure we do not regress for
    existing binaries, and a test with a 32-bit x86 build of LTP against a
    modified version of the musl C library that has been adapted to the new
    system call interface [3]. This library can be used for testing on all
    architectures supported by musl-1.1.21, but it is not how the support is
    getting integrated into the official musl release. Official musl support is
    planned but will require more invasive changes to the library.

    Link: https://lore.kernel.org/lkml/20190110162435.309262-1-arnd@arndb.de/T/
    Link: https://lore.kernel.org/lkml/20190118161835.2259170-1-arnd@arndb.de/
    Link: https://git.linaro.org/people/arnd/musl-y2038.git/ [2]

    Thomas Gleixner
     
  • …git/arnd/playground into timers/2038

    Pull preparatory work for y2038 changes from Arnd Bergmann:

    System call unification and cleanup

    The system call tables have diverged a bit over the years, and a number of
    the recent additions never made it into all architectures, for one reason
    or another.

    This is an attempt to clean it up as far as we can without breaking
    compatibility, doing a number of steps:

    - Add system calls that have not yet been integrated into all architectures
    but that we definitely want there. This includes {,f}statfs64() and
    get{eg,eu,g,p,u,pp}id() on alpha, which have been missing traditionally.

    - The s390 compat syscall handling is cleaned up to be more like what we
    do on other architectures, while keeping the 31-bit pointer
    extension. This was merged as a shared branch by the s390 maintainers
    and is included here in order to base the other patches on top.

    - Add the separate ipc syscalls on all architectures that traditionally
    only had sys_ipc(). This version is done without support for IPC_OLD
    that is we have in sys_ipc. The new semtimedop_time64 syscall will only
    be added here, not in sys_ipc

    - Add syscall numbers for a couple of syscalls that we probably don't need
    everywhere, in particular pkey_* and rseq, for the purpose of symmetry:
    if it's in asm-generic/unistd.h, it makes sense to have it everywhere. I
    expect that any future system calls will get assigned on all platforms
    together, even when they appear to be specific to a single architecture.

    - Prepare for having the same system call numbers for any future calls. In
    combination with the generated tables, this hopefully makes it easier to
    add new calls across all architectures together.

    All of the above are technically separate from the y2038 work, but are done
    as preparation before we add the new 64-bit time_t system calls everywhere,
    providing a common baseline set of system calls.

    I expect that glibc and other libraries that want to use 64-bit time_t will
    require linux-5.1 kernel headers for building in the future, and at a much
    later point may also require linux-5.1 or a later version as the minimum
    kernel at runtime. Having a common baseline then allows the removal of many
    architecture or kernel version specific workarounds.

    Thomas Gleixner
     

07 Feb, 2019

3 commits

  • This adds 21 new system calls on each ABI that has 32-bit time_t
    today. All of these have the exact same semantics as their existing
    counterparts, and the new ones all have macro names that end in 'time64'
    for clarification.

    This gets us to the point of being able to safely use a C library
    that has 64-bit time_t in user space. There are still a couple of
    loose ends to tie up in various areas of the code, but this is the
    big one, and should be entirely uncontroversial at this point.

    In particular, there are four system calls (getitimer, setitimer,
    waitid, and getrusage) that don't have a 64-bit counterpart yet,
    but these can all be safely implemented in the C library by wrapping
    around the existing system calls because the 32-bit time_t they
    pass only counts elapsed time, not time since the epoch. They
    will be dealt with later.

    Signed-off-by: Arnd Bergmann
    Acked-by: Heiko Carstens
    Acked-by: Geert Uytterhoeven
    Acked-by: Catalin Marinas

    Arnd Bergmann
     
  • The time, stime, utime, utimes, and futimesat system calls are only
    used on older architectures, and we do not provide y2038 safe variants
    of them, as they are replaced by clock_gettime64, clock_settime64,
    and utimensat_time64.

    However, for consistency it seems better to have the 32-bit architectures
    that still use them call the "time32" entry points (leaving the
    traditional handlers for the 64-bit architectures), like we do for system
    calls that now require two versions.

    Note: We used to always define __ARCH_WANT_SYS_TIME and
    __ARCH_WANT_SYS_UTIME and only set __ARCH_WANT_COMPAT_SYS_TIME and
    __ARCH_WANT_SYS_UTIME32 for compat mode on 64-bit kernels. Now this is
    reversed: only 64-bit architectures set __ARCH_WANT_SYS_TIME/UTIME, while
    we need __ARCH_WANT_SYS_TIME32/UTIME32 for 32-bit architectures and compat
    mode. The resulting asm/unistd.h changes look a bit counterintuitive.

    This is only a cleanup patch and it should not change any behavior.

    Signed-off-by: Arnd Bergmann
    Acked-by: Geert Uytterhoeven
    Acked-by: Heiko Carstens

    Arnd Bergmann
     
  • This is the big flip, where all 32-bit architectures set COMPAT_32BIT_TIME
    and use the _time32 system calls from the former compat layer instead
    of the system calls that take __kernel_timespec and similar arguments.

    The temporary redirects for __kernel_timespec, __kernel_itimerspec
    and __kernel_timex can get removed with this.

    It would be easy to split this commit by architecture, but with the new
    generated system call tables, it's easy enough to do it all at once,
    which makes it a little easier to check that the changes are the same
    in each table.

    Acked-by: Geert Uytterhoeven
    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

02 Feb, 2019

1 commit

  • Most architectures do not export shmparam.h to user-space.

    $ find arch -name shmparam.h | sort
    arch/alpha/include/asm/shmparam.h
    arch/arc/include/asm/shmparam.h
    arch/arm64/include/asm/shmparam.h
    arch/arm/include/asm/shmparam.h
    arch/csky/include/asm/shmparam.h
    arch/ia64/include/asm/shmparam.h
    arch/mips/include/asm/shmparam.h
    arch/nds32/include/asm/shmparam.h
    arch/nios2/include/asm/shmparam.h
    arch/parisc/include/asm/shmparam.h
    arch/powerpc/include/asm/shmparam.h
    arch/s390/include/asm/shmparam.h
    arch/sh/include/asm/shmparam.h
    arch/sparc/include/asm/shmparam.h
    arch/x86/include/asm/shmparam.h
    arch/xtensa/include/asm/shmparam.h

    Strangely, some users of the asm-generic wrapper export shmparam.h

    $ git grep 'generic-y += shmparam.h'
    arch/c6x/include/uapi/asm/Kbuild:generic-y += shmparam.h
    arch/h8300/include/uapi/asm/Kbuild:generic-y += shmparam.h
    arch/hexagon/include/uapi/asm/Kbuild:generic-y += shmparam.h
    arch/m68k/include/uapi/asm/Kbuild:generic-y += shmparam.h
    arch/microblaze/include/uapi/asm/Kbuild:generic-y += shmparam.h
    arch/openrisc/include/uapi/asm/Kbuild:generic-y += shmparam.h
    arch/riscv/include/asm/Kbuild:generic-y += shmparam.h
    arch/unicore32/include/uapi/asm/Kbuild:generic-y += shmparam.h

    The newly added riscv correctly creates the asm-generic wrapper
    in the kernel space, but the others (c6x, h8300, hexagon, m68k,
    microblaze, openrisc, unicore32) create the one in the uapi directory.

    Digging into the git history, now I guess fcc8487d477a ("uapi:
    export all headers under uapi directories") was the misconversion.
    Prior to that commit, no architecture exported to shmparam.h
    As its commit description said, that commit exported shmparam.h
    for c6x, h8300, hexagon, m68k, openrisc, unicore32.

    83f0124ad81e ("microblaze: remove asm-generic wrapper headers")
    accidentally exported shmparam.h for microblaze.

    This commit unexports shmparam.h for those architectures.

    There is no more reason to export include/uapi/asm-generic/shmparam.h,
    so it has been moved to include/asm-generic/shmparam.h

    Link: http://lkml.kernel.org/r/1546904307-11124-1-git-send-email-yamada.masahiro@socionext.com
    Signed-off-by: Masahiro Yamada
    Acked-by: Stafford Horne
    Cc: Geert Uytterhoeven
    Cc: Michal Simek
    Cc: Yoshinori Sato
    Cc: Richard Kuo
    Cc: Guan Xuetao
    Cc: Nicolas Dichtel
    Cc: Arnd Bergmann
    Cc: Aurelien Jacquiot
    Cc: Greentime Hu
    Cc: Guo Ren
    Cc: Palmer Dabbelt
    Cc: Stefan Kristiansson
    Cc: Mark Salter
    Cc: Albert Ou
    Cc: Jonas Bonn
    Cc: Vincent Chen
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Masahiro Yamada
     

26 Jan, 2019

1 commit

  • The behavior of these system calls is slightly different between
    architectures, as determined by the CONFIG_ARCH_WANT_IPC_PARSE_VERSION
    symbol. Most architectures that implement the split IPC syscalls don't set
    that symbol and only get the modern version, but alpha, arm, microblaze,
    mips-n32, mips-n64 and xtensa expect the caller to pass the IPC_64 flag.

    For the architectures that so far only implement sys_ipc(), i.e. m68k,
    mips-o32, powerpc, s390, sh, sparc, and x86-32, we want the new behavior
    when adding the split syscalls, so we need to distinguish between the
    two groups of architectures.

    The method I picked for this distinction is to have a separate system call
    entry point: sys_old_*ctl() now uses ipc_parse_version, while sys_*ctl()
    does not. The system call tables of the five architectures are changed
    accordingly.

    As an additional benefit, we no longer need the configuration specific
    definition for ipc_parse_version(), it always does the same thing now,
    but simply won't get called on architectures with the modern interface.

    A small downside is that on architectures that do set
    ARCH_WANT_IPC_PARSE_VERSION, we now have an extra set of entry points
    that are never called. They only add a few bytes of bloat, so it seems
    better to keep them compared to adding yet another Kconfig symbol.
    I considered adding new syscall numbers for the IPC_64 variants for
    consistency, but decided against that for now.

    Signed-off-by: Arnd Bergmann

    Arnd Bergmann
     

14 Jan, 2019

1 commit


07 Jan, 2019

1 commit


06 Jan, 2019

3 commits

  • Now that Kbuild automatically creates asm-generic wrappers for missing
    mandatory headers, it is redundant to list the same headers in
    generic-y and mandatory-y.

    Suggested-by: Sam Ravnborg
    Signed-off-by: Masahiro Yamada
    Acked-by: Sam Ravnborg

    Masahiro Yamada
     
  • These comments are leftovers of commit fcc8487d477a ("uapi: export all
    headers under uapi directories").

    Prior to that commit, exported headers must be explicitly added to
    header-y. Now, all headers under the uapi/ directories are exported.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • Merge more updates from Andrew Morton:

    - procfs updates

    - various misc bits

    - lib/ updates

    - epoll updates

    - autofs

    - fatfs

    - a few more MM bits

    * emailed patches from Andrew Morton : (58 commits)
    mm/page_io.c: fix polled swap page in
    checkpatch: add Co-developed-by to signature tags
    docs: fix Co-Developed-by docs
    drivers/base/platform.c: kmemleak ignore a known leak
    fs: don't open code lru_to_page()
    fs/: remove caller signal_pending branch predictions
    mm/: remove caller signal_pending branch predictions
    arch/arc/mm/fault.c: remove caller signal_pending_branch predictions
    kernel/sched/: remove caller signal_pending branch predictions
    kernel/locking/mutex.c: remove caller signal_pending branch predictions
    mm: select HAVE_MOVE_PMD on x86 for faster mremap
    mm: speed up mremap by 20x on large regions
    mm: treewide: remove unused address argument from pte_alloc functions
    initramfs: cleanup incomplete rootfs
    scripts/gdb: fix lx-version string output
    kernel/kcov.c: mark write_comp_data() as notrace
    kernel/sysctl: add panic_print into sysctl
    panic: add options to print system info when panic happens
    bfs: extra sanity checking and static inode bitmap
    exec: separate MM_ANONPAGES and RLIMIT_STACK accounting
    ...

    Linus Torvalds
     

05 Jan, 2019

1 commit

  • Patch series "Add support for fast mremap".

    This series speeds up the mremap(2) syscall by copying page tables at
    the PMD level even for non-THP systems. There is concern that the extra
    'address' argument that mremap passes to pte_alloc may do something
    subtle architecture related in the future that may make the scheme not
    work. Also we find that there is no point in passing the 'address' to
    pte_alloc since its unused. This patch therefore removes this argument
    tree-wide resulting in a nice negative diff as well. Also ensuring
    along the way that the enabled architectures do not do anything funky
    with the 'address' argument that goes unnoticed by the optimization.

    Build and boot tested on x86-64. Build tested on arm64. The config
    enablement patch for arm64 will be posted in the future after more
    testing.

    The changes were obtained by applying the following Coccinelle script.
    (thanks Julia for answering all Coccinelle questions!).
    Following fix ups were done manually:
    * Removal of address argument from pte_fragment_alloc
    * Removal of pte_alloc_one_fast definitions from m68k and microblaze.

    // Options: --include-headers --no-includes
    // Note: I split the 'identifier fn' line, so if you are manually
    // running it, please unsplit it so it runs for you.

    virtual patch

    @pte_alloc_func_def depends on patch exists@
    identifier E2;
    identifier fn =~
    "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
    type T2;
    @@

    fn(...
    - , T2 E2
    )
    { ... }

    @pte_alloc_func_proto_noarg depends on patch exists@
    type T1, T2, T3, T4;
    identifier fn =~ "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
    @@

    (
    - T3 fn(T1, T2);
    + T3 fn(T1);
    |
    - T3 fn(T1, T2, T4);
    + T3 fn(T1, T2);
    )

    @pte_alloc_func_proto depends on patch exists@
    identifier E1, E2, E4;
    type T1, T2, T3, T4;
    identifier fn =~
    "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
    @@

    (
    - T3 fn(T1 E1, T2 E2);
    + T3 fn(T1 E1);
    |
    - T3 fn(T1 E1, T2 E2, T4 E4);
    + T3 fn(T1 E1, T2 E2);
    )

    @pte_alloc_func_call depends on patch exists@
    expression E2;
    identifier fn =~
    "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
    @@

    fn(...
    -, E2
    )

    @pte_alloc_macro depends on patch exists@
    identifier fn =~
    "^(__pte_alloc|pte_alloc_one|pte_alloc|__pte_alloc_kernel|pte_alloc_one_kernel)$";
    identifier a, b, c;
    expression e;
    position p;
    @@

    (
    - #define fn(a, b, c) e
    + #define fn(a, b) e
    |
    - #define fn(a, b) e
    + #define fn(a) e
    )

    Link: http://lkml.kernel.org/r/20181108181201.88826-2-joelaf@google.com
    Signed-off-by: Joel Fernandes (Google)
    Suggested-by: Kirill A. Shutemov
    Acked-by: Kirill A. Shutemov
    Cc: Michal Hocko
    Cc: Julia Lawall
    Cc: Kirill A. Shutemov
    Cc: William Kucharski
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Joel Fernandes (Google)
     

04 Jan, 2019

1 commit

  • Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
    of the user address range verification function since we got rid of the
    old racy i386-only code to walk page tables by hand.

    It existed because the original 80386 would not honor the write protect
    bit when in kernel mode, so you had to do COW by hand before doing any
    user access. But we haven't supported that in a long time, and these
    days the 'type' argument is a purely historical artifact.

    A discussion about extending 'user_access_begin()' to do the range
    checking resulted this patch, because there is no way we're going to
    move the old VERIFY_xyz interface to that model. And it's best done at
    the end of the merge window when I've done most of my merges, so let's
    just get this done once and for all.

    This patch was mostly done with a sed-script, with manual fix-ups for
    the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

    There were a couple of notable cases:

    - csky still had the old "verify_area()" name as an alias.

    - the iter_iov code had magical hardcoded knowledge of the actual
    values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
    really used it)

    - microblaze used the type argument for a debug printout

    but other than those oddities this should be a total no-op patch.

    I tried to fix up all architectures, did fairly extensive grepping for
    access_ok() uses, and the changes are trivial, but I may have missed
    something. Any missed conversion should be trivially fixable, though.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

02 Jan, 2019

1 commit

  • Pull kgdb updates from Daniel Thompson:
    "Mostly clean ups although while Doug's was chasing down a odd lockdep
    warning he also did some work to improved debugger resilience when
    some CPUs fail to respond to the round up request.

    The main changes are:

    - Fixing a lockdep warning on architectures that cannot use an NMI
    for the round up plus related changes to make CPU round up and all
    CPU backtrace more resilient.

    - Constify the arch ops tables

    - A couple of other small clean ups

    Two of the three patchsets here include changes that spill over into
    arch/. Changes in the arch space are relatively narrow in scope (and
    directly related to kgdb). Didn't get comprehensive acks but all
    impacted maintainers were Cc:ed in good time"

    * tag 'kgdb-4.21-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux:
    kgdb/treewide: constify struct kgdb_arch arch_kgdb_ops
    mips/kgdb: prepare arch_kgdb_ops for constness
    kdb: use bool for binary state indicators
    kdb: Don't back trace on a cpu that didn't round up
    kgdb: Don't round up a CPU that failed rounding up before
    kgdb: Fix kgdb_roundup_cpus() for arches who used smp_call_function()
    kgdb: Remove irq flags from roundup

    Linus Torvalds
     

30 Dec, 2018

3 commits

  • checkpatch.pl reports the following:

    WARNING: struct kgdb_arch should normally be const
    #28: FILE: arch/mips/kernel/kgdb.c:397:
    +struct kgdb_arch arch_kgdb_ops = {

    This report makes sense, as all other ops struct, this
    one should also be const. This patch does the change.

    Cc: Vineet Gupta
    Cc: Russell King
    Cc: Catalin Marinas
    Cc: Will Deacon
    Cc: Yoshinori Sato
    Cc: Richard Kuo
    Cc: Michal Simek
    Cc: Ralf Baechle
    Cc: Paul Burton
    Cc: James Hogan
    Cc: Ley Foon Tan
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Michael Ellerman
    Cc: Rich Felker
    Cc: "David S. Miller"
    Cc: Thomas Gleixner
    Cc: Ingo Molnar
    Cc: Borislav Petkov
    Cc: x86@kernel.org
    Acked-by: Daniel Thompson
    Acked-by: Paul Burton
    Signed-off-by: Christophe Leroy
    Acked-by: Borislav Petkov
    Acked-by: Michael Ellerman (powerpc)
    Signed-off-by: Daniel Thompson

    Christophe Leroy
     
  • Pull Kconfig file consolidation from Masahiro Yamada:
    "Consolidation of bus (PCI, PCMCIA, EISA, RapidIO) config entries by
    Christoph Hellwig.

    Currently, every architecture that wants to provide common peripheral
    busses needs to add some boilerplate code and include the right
    Kconfig files. This series instead just selects the presence (when
    needed) and then handles everything in the bus-specific Kconfig file
    under drivers/"

    * tag 'kconfig-v4.21-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
    pcmcia: remove per-arch PCMCIA config entry
    eisa: consolidate EISA Kconfig entry in drivers/eisa
    rapidio: consolidate RAPIDIO config entry in drivers/rapidio
    pcmcia: allow PCMCIA support independent of the architecture
    PCI: consolidate the PCI_SYSCALL symbol
    PCI: consolidate the PCI_DOMAINS and PCI_DOMAINS_GENERIC config options
    PCI: consolidate PCI config entry in drivers/pci
    MIPS: remove the HT_PCI config option

    Linus Torvalds
     
  • Pull Kconfig updates from Masahiro Yamada:

    - support -y option for merge_config.sh to avoid downgrading =y to =m

    - remove S_OTHER symbol type, and touch include/config/*.h files correctly

    - fix file name and line number in lexer warnings

    - fix memory leak when EOF is encountered in quotation

    - resolve all shift/reduce conflicts of the parser

    - warn no new line at end of file

    - make 'source' statement more strict to take only string literal

    - rewrite the lexer and remove the keyword lookup table

    - convert to SPDX License Identifier

    - compile C files independently instead of including them from zconf.y

    - fix various warnings of gconfig

    - misc cleanups

    * tag 'kconfig-v4.21' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (39 commits)
    kconfig: surround dbg_sym_flags with #ifdef DEBUG to fix gconf warning
    kconfig: split images.c out of qconf.cc/gconf.c to fix gconf warnings
    kconfig: add static qualifiers to fix gconf warnings
    kconfig: split the lexer out of zconf.y
    kconfig: split some C files out of zconf.y
    kconfig: convert to SPDX License Identifier
    kconfig: remove keyword lookup table entirely
    kconfig: update current_pos in the second lexer
    kconfig: switch to ASSIGN_VAL state in the second lexer
    kconfig: stop associating kconf_id with yylval
    kconfig: refactor end token rules
    kconfig: stop supporting '.' and '/' in unquoted words
    treewide: surround Kconfig file paths with double quotes
    microblaze: surround string default in Kconfig with double quotes
    kconfig: use T_WORD instead of T_VARIABLE for variables
    kconfig: use specific tokens instead of T_ASSIGN for assignments
    kconfig: refactor scanning and parsing "option" properties
    kconfig: use distinct tokens for type and default properties
    kconfig: remove redundant token defines
    kconfig: rename depends_list to comment_option_list
    ...

    Linus Torvalds
     

29 Dec, 2018

1 commit

  • Pull DMA mapping updates from Christoph Hellwig:
    "A huge update this time, but a lot of that is just consolidating or
    removing code:

    - provide a common DMA_MAPPING_ERROR definition and avoid indirect
    calls for dma_map_* error checking

    - use direct calls for the DMA direct mapping case, avoiding huge
    retpoline overhead for high performance workloads

    - merge the swiotlb dma_map_ops into dma-direct

    - provide a generic remapping DMA consistent allocator for
    architectures that have devices that perform DMA that is not cache
    coherent. Based on the existing arm64 implementation and also used
    for csky now.

    - improve the dma-debug infrastructure, including dynamic allocation
    of entries (Robin Murphy)

    - default to providing chaining scatterlist everywhere, with opt-outs
    for the few architectures (alpha, parisc, most arm32 variants) that
    can't cope with it

    - misc sparc32 dma-related cleanups

    - remove the dma_mark_clean arch hook used by swiotlb on ia64 and
    replace it with the generic noncoherent infrastructure

    - fix the return type of dma_set_max_seg_size (Niklas Söderlund)

    - move the dummy dma ops for not DMA capable devices from arm64 to
    common code (Robin Murphy)

    - ensure dma_alloc_coherent returns zeroed memory to avoid kernel
    data leaks through userspace. We already did this for most common
    architectures, but this ensures we do it everywhere.
    dma_zalloc_coherent has been deprecated and can hopefully be
    removed after -rc1 with a coccinelle script"

    * tag 'dma-mapping-4.21' of git://git.infradead.org/users/hch/dma-mapping: (73 commits)
    dma-mapping: fix inverted logic in dma_supported
    dma-mapping: deprecate dma_zalloc_coherent
    dma-mapping: zero memory returned from dma_alloc_*
    sparc/iommu: fix ->map_sg return value
    sparc/io-unit: fix ->map_sg return value
    arm64: default to the direct mapping in get_arch_dma_ops
    PCI: Remove unused attr variable in pci_dma_configure
    ia64: only select ARCH_HAS_DMA_COHERENT_TO_PFN if swiotlb is enabled
    dma-mapping: bypass indirect calls for dma-direct
    vmd: use the proper dma_* APIs instead of direct methods calls
    dma-direct: merge swiotlb_dma_ops into the dma_direct code
    dma-direct: use dma_direct_map_page to implement dma_direct_map_sg
    dma-direct: improve addressability error reporting
    swiotlb: remove dma_mark_clean
    swiotlb: remove SWIOTLB_MAP_ERROR
    ACPI / scan: Refactor _CCA enforcement
    dma-mapping: factor out dummy DMA ops
    dma-mapping: always build the direct mapping code
    dma-mapping: move dma_cache_sync out of line
    dma-mapping: move various slow path functions out of line
    ...

    Linus Torvalds
     

27 Dec, 2018

1 commit

  • Pull arch/microblaze updates from Michal Simek:

    - Fix multiple Kbuild/Makefile issues

    - Start to use system call table generation

    * tag 'microblaze-v5.0-rc1' of git://git.monstr.eu/linux-2.6-microblaze:
    microblaze: remove the explicit removal of system.dtb
    microblaze: fix race condition in building boot images
    microblaze: add linux.bin* and simpleImage.* to PHONY
    microblaze: fix multiple bugs in arch/microblaze/boot/Makefile
    microblaze: move "... is ready" messages to arch/microblaze/Makefile
    microblaze: adjust the help to the real behavior
    microblaze: generate uapi header and system call table files
    microblaze: add system call table generation support
    microblaze: move __NR_syscalls macro from asm/unistd.h
    microblaze: Typo s/use use/use/

    Linus Torvalds
     

21 Dec, 2018

1 commit


20 Dec, 2018

1 commit

  • If we want to map memory from the DMA allocator to userspace it must be
    zeroed at allocation time to prevent stale data leaks. We already do
    this on most common architectures, but some architectures don't do this
    yet, fix them up, either by passing GFP_ZERO when we use the normal page
    allocator or doing a manual memset otherwise.

    Signed-off-by: Christoph Hellwig
    Acked-by: Geert Uytterhoeven [m68k]
    Acked-by: Sam Ravnborg [sparc]

    Christoph Hellwig
     

14 Dec, 2018

3 commits

  • I guess

    || (rm -f $@ && echo false)

    ... should be

    || (rm -f $@ && false)

    In fact, no Makefile needs to delete a target explicitly on error.

    It is automatically done since commit 9c2af1c7377a ("kbuild: add
    .DELETE_ON_ERROR special target").

    I also reused equivalent cmd_shipped from scripts/Makefile.lib.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Michal Simek

    Masahiro Yamada
     
  • I fixed a race condition in the parallel building of ARM in commit
    3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
    generate invalid images").

    I see the same problem for MicroBlaze too.

    "make -j ARCH=microblaze all linux.bin.ub" results in a broken build
    because two threads descend into arch/microblaze/boot simultaneously.

    Add proper dependencies to avoid it.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Michal Simek

    Masahiro Yamada
     
  • linux.bin, linux.bin.gz, and linux.bin.ub are phony targets to
    generate a corresponding image under arch/microblaze/boot/.

    simpleImage.% also works like a phony target, but a pattern that
    contains '%' cannot be a phony target. I replaced it with equivalent
    simpleImage.$(DTB).

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Michal Simek

    Masahiro Yamada