20 Jan, 2021

2 commits

  • commit 69e976831cd53f9ba304fd20305b2025ecc78eab upstream.

    LLVM-built Linux triggered a boot hangup with KASLR enabled.

    arch/mips/kernel/relocate.c:get_random_boot() uses linux_banner,
    which is a string constant, as a random seed, but accesses it
    as an array of unsigned long (in rotate_xor()).
    When the address of linux_banner is not aligned to sizeof(long),
    such access emits unaligned access exception and hangs the kernel.

    Use PTR_ALIGN() to align input address to sizeof(long) and also
    align down the input length to prevent possible access-beyond-end.

    Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
    Cc: stable@vger.kernel.org # 4.7+
    Signed-off-by: Alexander Lobakin
    Tested-by: Nathan Chancellor
    Reviewed-by: Kees Cook
    Signed-off-by: Thomas Bogendoerfer
    Signed-off-by: Greg Kroah-Hartman

    Alexander Lobakin
     
  • commit 698222457465ce343443be81c5512edda86e5914 upstream.

    Patches that introduced NT_FILE and NT_SIGINFO notes back in 2012
    had taken care of native (fs/binfmt_elf.c) and compat (fs/compat_binfmt_elf.c)
    coredumps; unfortunately, compat on mips (which does not go through the
    usual compat_binfmt_elf.c) had not been noticed.

    As the result, both N32 and O32 coredumps on 64bit mips kernels
    have those sections malformed enough to confuse the living hell out of
    all gdb and readelf versions (up to and including the tip of binutils-gdb.git).

    Longer term solution is to make both O32 and N32 compat use the
    regular compat_binfmt_elf.c, but that's too much for backports. The minimal
    solution is to do in arch/mips/kernel/binfmt_elf[on]32.c the same thing
    those patches have done in fs/compat_binfmt_elf.c

    Cc: stable@kernel.org # v3.7+
    Signed-off-by: Al Viro
    Signed-off-by: Thomas Bogendoerfer
    Signed-off-by: Greg Kroah-Hartman

    Al Viro
     

30 Dec, 2020

1 commit

  • [ Upstream commit d121f125af22a16f0f679293756d28a9691fa46d ]

    Linux doesn't own the memory immediately after the kernel image. On Octeon
    bootloader places a shared structure right close after the kernel _end,
    refer to "struct cvmx_bootinfo *octeon_bootinfo" in cavium-octeon/setup.c.

    If check_kernel_sections_mem() rounds the PFNs up, first memblock_alloc()
    inside early_init_dt_alloc_memory_arch()
    Signed-off-by: Thomas Bogendoerfer
    Signed-off-by: Sasha Levin

    Alexander Sverdlin
     

30 Nov, 2020

1 commit


24 Nov, 2020

1 commit

  • We call arch_cpu_idle() with RCU disabled, but then use
    local_irq_{en,dis}able(), which invokes tracing, which relies on RCU.

    Switch all arch_cpu_idle() implementations to use
    raw_local_irq_{en,dis}able() and carefully manage the
    lockdep,rcu,tracing state like we do in entry.

    (XXX: we really should change arch_cpu_idle() to not return with
    interrupts enabled)

    Reported-by: Sven Schnelle
    Signed-off-by: Peter Zijlstra (Intel)
    Reviewed-by: Mark Rutland
    Tested-by: Mark Rutland
    Link: https://lkml.kernel.org/r/20201120114925.594122626@infradead.org

    Peter Zijlstra
     

17 Nov, 2020

1 commit


26 Oct, 2020

1 commit

  • Use a more generic form for __section that requires quotes to avoid
    complications with clang and gcc differences.

    Remove the quote operator # from compiler_attributes.h __section macro.

    Convert all unquoted __section(foo) uses to quoted __section("foo").
    Also convert __attribute__((section("foo"))) uses to __section("foo")
    even if the __attribute__ has multiple list entry forms.

    Conversion done using the script at:

    https://lore.kernel.org/lkml/75393e5ddc272dc7403de74d645e6c6e0f4e70eb.camel@perches.com/2-convert_section.pl

    Signed-off-by: Joe Perches
    Reviewed-by: Nick Desaulniers
    Reviewed-by: Miguel Ojeda
    Signed-off-by: Linus Torvalds

    Joe Perches
     

24 Oct, 2020

1 commit

  • Pull arch task_work cleanups from Jens Axboe:
    "Two cleanups that don't fit other categories:

    - Finally get the task_work_add() cleanup done properly, so we don't
    have random 0/1/false/true/TWA_SIGNAL confusing use cases. Updates
    all callers, and also fixes up the documentation for
    task_work_add().

    - While working on some TIF related changes for 5.11, this
    TIF_NOTIFY_RESUME cleanup fell out of that. Remove some arch
    duplication for how that is handled"

    * tag 'arch-cleanup-2020-10-22' of git://git.kernel.dk/linux-block:
    task_work: cleanup notification modes
    tracehook: clear TIF_NOTIFY_RESUME in tracehook_notify_resume()

    Linus Torvalds
     

19 Oct, 2020

1 commit

  • There is usecase that System Management Software(SMS) want to give a
    memory hint like MADV_[COLD|PAGEEOUT] to other processes and in the
    case of Android, it is the ActivityManagerService.

    The information required to make the reclaim decision is not known to the
    app. Instead, it is known to the centralized userspace
    daemon(ActivityManagerService), and that daemon must be able to initiate
    reclaim on its own without any app involvement.

    To solve the issue, this patch introduces a new syscall
    process_madvise(2). It uses pidfd of an external process to give the
    hint. It also supports vector address range because Android app has
    thousands of vmas due to zygote so it's totally waste of CPU and power if
    we should call the syscall one by one for each vma.(With testing 2000-vma
    syscall vs 1-vector syscall, it showed 15% performance improvement. I
    think it would be bigger in real practice because the testing ran very
    cache friendly environment).

    Another potential use case for the vector range is to amortize the cost
    ofTLB shootdowns for multiple ranges when using MADV_DONTNEED; this could
    benefit users like TCP receive zerocopy and malloc implementations. In
    future, we could find more usecases for other advises so let's make it
    happens as API since we introduce a new syscall at this moment. With
    that, existing madvise(2) user could replace it with process_madvise(2)
    with their own pid if they want to have batch address ranges support
    feature.

    ince it could affect other process's address range, only privileged
    process(PTRACE_MODE_ATTACH_FSCREDS) or something else(e.g., being the same
    UID) gives it the right to ptrace the process could use it successfully.
    The flag argument is reserved for future use if we need to extend the API.

    I think supporting all hints madvise has/will supported/support to
    process_madvise is rather risky. Because we are not sure all hints make
    sense from external process and implementation for the hint may rely on
    the caller being in the current context so it could be error-prone. Thus,
    I just limited hints as MADV_[COLD|PAGEOUT] in this patch.

    If someone want to add other hints, we could hear the usecase and review
    it for each hint. It's safer for maintenance rather than introducing a
    buggy syscall but hard to fix it later.

    So finally, the API is as follows,

    ssize_t process_madvise(int pidfd, const struct iovec *iovec,
    unsigned long vlen, int advice, unsigned int flags);

    DESCRIPTION
    The process_madvise() system call is used to give advice or directions
    to the kernel about the address ranges from external process as well as
    local process. It provides the advice to address ranges of process
    described by iovec and vlen. The goal of such advice is to improve
    system or application performance.

    The pidfd selects the process referred to by the PID file descriptor
    specified in pidfd. (See pidofd_open(2) for further information)

    The pointer iovec points to an array of iovec structures, defined in
    as:

    struct iovec {
    void *iov_base; /* starting address */
    size_t iov_len; /* number of bytes to be advised */
    };

    The iovec describes address ranges beginning at address(iov_base)
    and with size length of bytes(iov_len).

    The vlen represents the number of elements in iovec.

    The advice is indicated in the advice argument, which is one of the
    following at this moment if the target process specified by pidfd is
    external.

    MADV_COLD
    MADV_PAGEOUT

    Permission to provide a hint to external process is governed by a
    ptrace access mode PTRACE_MODE_ATTACH_FSCREDS check; see ptrace(2).

    The process_madvise supports every advice madvise(2) has if target
    process is in same thread group with calling process so user could
    use process_madvise(2) to extend existing madvise(2) to support
    vector address ranges.

    RETURN VALUE
    On success, process_madvise() returns the number of bytes advised.
    This return value may be less than the total number of requested
    bytes, if an error occurred. The caller should check return value
    to determine whether a partial advice occurred.

    FAQ:

    Q.1 - Why does any external entity have better knowledge?

    Quote from Sandeep

    "For Android, every application (including the special SystemServer)
    are forked from Zygote. The reason of course is to share as many
    libraries and classes between the two as possible to benefit from the
    preloading during boot.

    After applications start, (almost) all of the APIs end up calling into
    this SystemServer process over IPC (binder) and back to the
    application.

    In a fully running system, the SystemServer monitors every single
    process periodically to calculate their PSS / RSS and also decides
    which process is "important" to the user for interactivity.

    So, because of how these processes start _and_ the fact that the
    SystemServer is looping to monitor each process, it does tend to *know*
    which address range of the application is not used / useful.

    Besides, we can never rely on applications to clean things up
    themselves. We've had the "hey app1, the system is low on memory,
    please trim your memory usage down" notifications for a long time[1].
    They rely on applications honoring the broadcasts and very few do.

    So, if we want to avoid the inevitable killing of the application and
    restarting it, some way to be able to tell the OS about unimportant
    memory in these applications will be useful.

    - ssp

    Q.2 - How to guarantee the race(i.e., object validation) between when
    giving a hint from an external process and get the hint from the target
    process?

    process_madvise operates on the target process's address space as it
    exists at the instant that process_madvise is called. If the space
    target process can run between the time the process_madvise process
    inspects the target process address space and the time that
    process_madvise is actually called, process_madvise may operate on
    memory regions that the calling process does not expect. It's the
    responsibility of the process calling process_madvise to close this
    race condition. For example, the calling process can suspend the
    target process with ptrace, SIGSTOP, or the freezer cgroup so that it
    doesn't have an opportunity to change its own address space before
    process_madvise is called. Another option is to operate on memory
    regions that the caller knows a priori will be unchanged in the target
    process. Yet another option is to accept the race for certain
    process_madvise calls after reasoning that mistargeting will do no
    harm. The suggested API itself does not provide synchronization. It
    also apply other APIs like move_pages, process_vm_write.

    The race isn't really a problem though. Why is it so wrong to require
    that callers do their own synchronization in some manner? Nobody
    objects to write(2) merely because it's possible for two processes to
    open the same file and clobber each other's writes --- instead, we tell
    people to use flock or something. Think about mmap. It never
    guarantees newly allocated address space is still valid when the user
    tries to access it because other threads could unmap the memory right
    before. That's where we need synchronization by using other API or
    design from userside. It shouldn't be part of API itself. If someone
    needs more fine-grained synchronization rather than process level,
    there were two ideas suggested - cookie[2] and anon-fd[3]. Both are
    applicable via using last reserved argument of the API but I don't
    think it's necessary right now since we have already ways to prevent
    the race so don't want to add additional complexity with more
    fine-grained optimization model.

    To make the API extend, it reserved an unsigned long as last argument
    so we could support it in future if someone really needs it.

    Q.3 - Why doesn't ptrace work?

    Injecting an madvise in the target process using ptrace would not work
    for us because such injected madvise would have to be executed by the
    target process, which means that process would have to be runnable and
    that creates the risk of the abovementioned race and hinting a wrong
    VMA. Furthermore, we want to act the hint in caller's context, not the
    callee's, because the callee is usually limited in cpuset/cgroups or
    even freezed state so they can't act by themselves quick enough, which
    causes more thrashing/kill. It doesn't work if the target process are
    ptraced(e.g., strace, debugger, minidump) because a process can have at
    most one ptracer.

    [1] https://developer.android.com/topic/performance/memory"

    [2] process_getinfo for getting the cookie which is updated whenever
    vma of process address layout are changed - Daniel Colascione -
    https://lore.kernel.org/lkml/20190520035254.57579-1-minchan@kernel.org/T/#m7694416fd179b2066a2c62b5b139b14e3894e224

    [3] anonymous fd which is used for the object(i.e., address range)
    validation - Michal Hocko -
    https://lore.kernel.org/lkml/20200120112722.GY18451@dhcp22.suse.cz/

    [minchan@kernel.org: fix process_madvise build break for arm64]
    Link: http://lkml.kernel.org/r/20200303145756.GA219683@google.com
    [minchan@kernel.org: fix build error for mips of process_madvise]
    Link: http://lkml.kernel.org/r/20200508052517.GA197378@google.com
    [akpm@linux-foundation.org: fix patch ordering issue]
    [akpm@linux-foundation.org: fix arm64 whoops]
    [minchan@kernel.org: make process_madvise() vlen arg have type size_t, per Florian]
    [akpm@linux-foundation.org: fix i386 build]
    [sfr@canb.auug.org.au: fix syscall numbering]
    Link: https://lkml.kernel.org/r/20200905142639.49fc3f1a@canb.auug.org.au
    [sfr@canb.auug.org.au: madvise.c needs compat.h]
    Link: https://lkml.kernel.org/r/20200908204547.285646b4@canb.auug.org.au
    [minchan@kernel.org: fix mips build]
    Link: https://lkml.kernel.org/r/20200909173655.GC2435453@google.com
    [yuehaibing@huawei.com: remove duplicate header which is included twice]
    Link: https://lkml.kernel.org/r/20200915121550.30584-1-yuehaibing@huawei.com
    [minchan@kernel.org: do not use helper functions for process_madvise]
    Link: https://lkml.kernel.org/r/20200921175539.GB387368@google.com
    [akpm@linux-foundation.org: pidfd_get_pid() gained an argument]
    [sfr@canb.auug.org.au: fix up for "iov_iter: transparently handle compat iovecs in import_iovec"]
    Link: https://lkml.kernel.org/r/20200928212542.468e1fef@canb.auug.org.au

    Signed-off-by: Minchan Kim
    Signed-off-by: YueHaibing
    Signed-off-by: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Reviewed-by: Suren Baghdasaryan
    Reviewed-by: Vlastimil Babka
    Acked-by: David Rientjes
    Cc: Alexander Duyck
    Cc: Brian Geffon
    Cc: Christian Brauner
    Cc: Daniel Colascione
    Cc: Jann Horn
    Cc: Jens Axboe
    Cc: Joel Fernandes
    Cc: Johannes Weiner
    Cc: John Dias
    Cc: Kirill Tkhai
    Cc: Michal Hocko
    Cc: Oleksandr Natalenko
    Cc: Sandeep Patil
    Cc: SeongJae Park
    Cc: SeongJae Park
    Cc: Shakeel Butt
    Cc: Sonny Rao
    Cc: Tim Murray
    Cc: Christian Brauner
    Cc: Florian Weimer
    Cc:
    Link: http://lkml.kernel.org/r/20200302193630.68771-3-minchan@kernel.org
    Link: http://lkml.kernel.org/r/20200508183320.GA125527@google.com
    Link: http://lkml.kernel.org/r/20200622192900.22757-4-minchan@kernel.org
    Link: https://lkml.kernel.org/r/20200901000633.1920247-4-minchan@kernel.org
    Signed-off-by: Linus Torvalds

    Minchan Kim
     

18 Oct, 2020

1 commit


17 Oct, 2020

1 commit

  • Pull MIPS updates from Thomas Bogendoerfer:

    - removed support for PNX833x alias NXT_STB22x

    - included Ingenic SoC support into generic MIPS kernels

    - added support for new Ingenic SoCs

    - converted workaround selection to use Kconfig

    - replaced old boot mem functions by memblock_*

    - enabled COP2 usage in kernel for Loongson64 to make use
    of 16byte load/stores possible

    - cleanups and fixes

    * tag 'mips_5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (92 commits)
    MIPS: DEC: Restore bootmem reservation for firmware working memory area
    MIPS: dec: fix section mismatch
    bcm963xx_tag.h: fix duplicated word
    mips: ralink: enable zboot support
    MIPS: ingenic: Remove CPU_SUPPORTS_HUGEPAGES
    MIPS: cpu-probe: remove MIPS_CPU_BP_GHIST option bit
    MIPS: cpu-probe: introduce exclusive R3k CPU probe
    MIPS: cpu-probe: move fpu probing/handling into its own file
    MIPS: replace add_memory_region with memblock
    MIPS: Loongson64: Clean up numa.c
    MIPS: Loongson64: Select SMP in Kconfig to avoid build error
    mips: octeon: Add Ubiquiti E200 and E220 boards
    MIPS: SGI-IP28: disable use of ll/sc in kernel
    MIPS: tx49xx: move tx4939_add_memory_regions into only user
    MIPS: pgtable: Remove used PAGE_USERIO define
    MIPS: alchemy: Share prom_init implementation
    MIPS: alchemy: Fix build breakage, if TOUCHSCREEN_WM97XX is disabled
    MIPS: process: include exec.h header in process.c
    MIPS: process: Add prototype for function arch_dup_task_struct
    MIPS: idle: Add prototype for function check_wait
    ...

    Linus Torvalds
     

16 Oct, 2020

1 commit

  • Pull dma-mapping updates from Christoph Hellwig:

    - rework the non-coherent DMA allocator

    - move private definitions out of

    - lower CMA_ALIGNMENT (Paul Cercueil)

    - remove the omap1 dma address translation in favor of the common code

    - make dma-direct aware of multiple dma offset ranges (Jim Quinlan)

    - support per-node DMA CMA areas (Barry Song)

    - increase the default seg boundary limit (Nicolin Chen)

    - misc fixes (Robin Murphy, Thomas Tai, Xu Wang)

    - various cleanups

    * tag 'dma-mapping-5.10' of git://git.infradead.org/users/hch/dma-mapping: (63 commits)
    ARM/ixp4xx: add a missing include of dma-map-ops.h
    dma-direct: simplify the DMA_ATTR_NO_KERNEL_MAPPING handling
    dma-direct: factor out a dma_direct_alloc_from_pool helper
    dma-direct check for highmem pages in dma_direct_alloc_pages
    dma-mapping: merge into
    dma-mapping: move large parts of to kernel/dma
    dma-mapping: move dma-debug.h to kernel/dma/
    dma-mapping: remove
    dma-mapping: merge into
    dma-contiguous: remove dma_contiguous_set_default
    dma-contiguous: remove dev_set_cma_area
    dma-contiguous: remove dma_declare_contiguous
    dma-mapping: split
    cma: decrease CMA_ALIGNMENT lower limit to 2
    firewire-ohci: use dma_alloc_pages
    dma-iommu: implement ->alloc_noncoherent
    dma-mapping: add new {alloc,free}_noncoherent dma_map_ops methods
    dma-mapping: add a new dma_alloc_pages API
    dma-mapping: remove dma_cache_sync
    53c700: convert to dma_alloc_noncoherent
    ...

    Linus Torvalds
     

14 Oct, 2020

1 commit

  • There are several occurrences of the following pattern:

    for_each_memblock(memory, reg) {
    start = __pfn_to_phys(memblock_region_memory_base_pfn(reg);
    end = __pfn_to_phys(memblock_region_memory_end_pfn(reg));

    /* do something with start and end */
    }

    Using for_each_mem_range() iterator is more appropriate in such cases and
    allows simpler and cleaner code.

    [akpm@linux-foundation.org: fix arch/arm/mm/pmsa-v7.c build]
    [rppt@linux.ibm.com: mips: fix cavium-octeon build caused by memblock refactoring]
    Link: http://lkml.kernel.org/r/20200827124549.GD167163@linux.ibm.com

    Signed-off-by: Mike Rapoport
    Signed-off-by: Andrew Morton
    Cc: Andy Lutomirski
    Cc: Baoquan He
    Cc: Benjamin Herrenschmidt
    Cc: Borislav Petkov
    Cc: Catalin Marinas
    Cc: Christoph Hellwig
    Cc: Daniel Axtens
    Cc: Dave Hansen
    Cc: Emil Renner Berthing
    Cc: Hari Bathini
    Cc: Ingo Molnar
    Cc: Ingo Molnar
    Cc: Jonathan Cameron
    Cc: Marek Szyprowski
    Cc: Max Filippov
    Cc: Michael Ellerman
    Cc: Michal Simek
    Cc: Miguel Ojeda
    Cc: Palmer Dabbelt
    Cc: Paul Mackerras
    Cc: Paul Walmsley
    Cc: Peter Zijlstra
    Cc: Russell King
    Cc: Stafford Horne
    Cc: Thomas Bogendoerfer
    Cc: Thomas Gleixner
    Cc: Will Deacon
    Cc: Yoshinori Sato
    Link: https://lkml.kernel.org/r/20200818151634.14343-13-rppt@kernel.org
    Signed-off-by: Linus Torvalds

    Mike Rapoport
     

13 Oct, 2020

4 commits

  • Pull compat mount cleanups from Al Viro:
    "The last remnants of mount(2) compat buried by Christoph.

    Buried into NFS, that is.

    Generally I'm less enthusiastic about "let's use in_compat_syscall()
    deep in call chain" kind of approach than Christoph seems to be, but
    in this case it's warranted - that had been an NFS-specific wart,
    hopefully not to be repeated in any other filesystems (read: any new
    filesystem introducing non-text mount options will get NAKed even if
    it doesn't mess the layout up).

    IOW, not worth trying to grow an infrastructure that would avoid that
    use of in_compat_syscall()..."

    * 'compat.mount' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    fs: remove compat_sys_mount
    fs,nfs: lift compat nfs4 mount data handling into the nfs code
    nfs: simplify nfs4_parse_monolithic

    Linus Torvalds
     
  • Pull compat iovec cleanups from Al Viro:
    "Christoph's series around import_iovec() and compat variant thereof"

    * 'work.iov_iter' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    security/keys: remove compat_keyctl_instantiate_key_iov
    mm: remove compat_process_vm_{readv,writev}
    fs: remove compat_sys_vmsplice
    fs: remove the compat readv/writev syscalls
    fs: remove various compat readv/writev helpers
    iov_iter: transparently handle compat iovecs in import_iovec
    iov_iter: refactor rw_copy_check_uvector and import_iovec
    iov_iter: move rw_copy_check_uvector() into lib/iov_iter.c
    compat.h: fix a spelling error in

    Linus Torvalds
     
  • Pull perf/kprobes updates from Ingo Molnar:
    "This prepares to unify the kretprobe trampoline handler and make
    kretprobe lockless (those patches are still work in progress)"

    * tag 'perf-kprobes-2020-10-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
    kprobes: Fix to check probe enabled before disarm_kprobe_ftrace()
    kprobes: Make local functions static
    kprobes: Free kretprobe_instance with RCU callback
    kprobes: Remove NMI context check
    sparc: kprobes: Use generic kretprobe trampoline handler
    sh: kprobes: Use generic kretprobe trampoline handler
    s390: kprobes: Use generic kretprobe trampoline handler
    powerpc: kprobes: Use generic kretprobe trampoline handler
    parisc: kprobes: Use generic kretprobe trampoline handler
    mips: kprobes: Use generic kretprobe trampoline handler
    ia64: kprobes: Use generic kretprobe trampoline handler
    csky: kprobes: Use generic kretprobe trampoline handler
    arc: kprobes: Use generic kretprobe trampoline handler
    arm64: kprobes: Use generic kretprobe trampoline handler
    arm: kprobes: Use generic kretprobe trampoline handler
    x86/kprobes: Use generic kretprobe trampoline handler
    kprobes: Add generic kretprobe trampoline handler

    Linus Torvalds
     
  • Pull orphan section checking from Ingo Molnar:
    "Orphan link sections were a long-standing source of obscure bugs,
    because the heuristics that various linkers & compilers use to handle
    them (include these bits into the output image vs discarding them
    silently) are both highly idiosyncratic and also version dependent.

    Instead of this historically problematic mess, this tree by Kees Cook
    (et al) adds build time asserts and build time warnings if there's any
    orphan section in the kernel or if a section is not sized as expected.

    And because we relied on so many silent assumptions in this area, fix
    a metric ton of dependencies and some outright bugs related to this,
    before we can finally enable the checks on the x86, ARM and ARM64
    platforms"

    * tag 'core-build-2020-10-12' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (36 commits)
    x86/boot/compressed: Warn on orphan section placement
    x86/build: Warn on orphan section placement
    arm/boot: Warn on orphan section placement
    arm/build: Warn on orphan section placement
    arm64/build: Warn on orphan section placement
    x86/boot/compressed: Add missing debugging sections to output
    x86/boot/compressed: Remove, discard, or assert for unwanted sections
    x86/boot/compressed: Reorganize zero-size section asserts
    x86/build: Add asserts for unwanted sections
    x86/build: Enforce an empty .got.plt section
    x86/asm: Avoid generating unused kprobe sections
    arm/boot: Handle all sections explicitly
    arm/build: Assert for unwanted sections
    arm/build: Add missing sections
    arm/build: Explicitly keep .ARM.attributes sections
    arm/build: Refactor linker script headers
    arm64/build: Assert for unwanted sections
    arm64/build: Add missing DWARF sections
    arm64/build: Use common DISCARDS in linker script
    arm64/build: Remove .eh_frame* sections due to unwind tables
    ...

    Linus Torvalds
     

12 Oct, 2020

4 commits


06 Oct, 2020

1 commit


03 Oct, 2020

3 commits


01 Oct, 2020

1 commit


23 Sep, 2020

1 commit


22 Sep, 2020

5 commits

  • When the kernel crashkernel parameter is specified with just a size,
    we are supposed to allocate a region from RAM to store the crashkernel.
    However, MIPS merely reserves physical address zero with no checking
    that there is even RAM there.

    Fix this by lifting similar code from x86, importing it to MIPS with the
    MIPS specific parameters added. In the absence of any platform specific
    information, we allocate the crashkernel region from the first 512MB of
    physical memory (limited to CKSEG0 or KSEG0 address range).

    When X is not specified, crash_base defaults to 0 (crashkernel=YM@XM).

    E.g. without this patch:

    The environment as follows:
    [ 0.000000] MIPS: machine is loongson,loongson64c-4core-ls7a
    ...
    [ 0.000000] Kernel command line: root=/dev/sda2 crashkernel=96M ...

    The warning as follows:
    [ 0.000000] Invalid memory region reserved for crash kernel

    And the iomem as follows:
    00200000-0effffff : System RAM
    00200000-00b47f87 : Kernel code
    00b47f88-00dfffff : Kernel data
    00e60000-01f73c7f : Kernel bss
    1a000000-1bffffff : pci@1a000000
    ...

    With this patch:

    After increasing crash_base
    Signed-off-by: Thomas Bogendoerfer

    Youling Tang
     
  • Loongson-3 has 16-bytes load/store instructions: gslq and gssq. This
    patch calculate ra properly when unwinding the stack, if ra is saved
    by gssq and restored by gslq.

    Signed-off-by: Huacai Chen
    Signed-off-by: Thomas Bogendoerfer

    Huacai Chen
     
  • Loongson-3's COP2 is Multi-Media coprocessor, it is disabled in kernel
    mode by default. However, gslq/gssq (16-bytes load/store instructions)
    overrides the instruction format of lwc2/swc2. If we wan't to use gslq/
    gssq for optimization in kernel, we should enable COP2 usage in kernel.

    Please pay attention that in this patch we only enable COP2 in kernel,
    which means it will lose ST0_CU2 when a process go to user space (try
    to use COP2 in user space will trigger an exception and then grab COP2,
    which is similar to FPU). And as a result, we need to modify the context
    switching code because the new scheduled process doesn't contain ST0_CU2
    in its THERAD_STATUS probably.

    For zboot, we disable gslq/gssq be generated by toolchain.

    Signed-off-by: Huacai Chen
    Signed-off-by: Thomas Bogendoerfer

    Huacai Chen
     
  • arch/mips/kernel/branch.c:876:5: error: no previous prototype for '__insn_is_compact_branch' [-Werror=missing-prototypes]

    Signed-off-by: Pujin Shi
    Signed-off-by: Pujin Shi
    Signed-off-by: Thomas Bogendoerfer

    Pujin Shi
     
  • This addresses the following sparse warning:

    arch/mips/kernel/setup.c:446:33: warning: symbol 'setup_elfcorehdr_size'
    was not declared. Should it be static?

    Reported-by: Hulk Robot
    Signed-off-by: Jason Yan
    Signed-off-by: Thomas Bogendoerfer

    Jason Yan
     

18 Sep, 2020

3 commits

  • The previous code was doing:
    BUG_ON(!__builtin_constant_p(cpu_has_counter) || cpu_has_counter);

    This only worked as the "cpu_has_counter" macro was overridden in
    . The default "cpu_has_counter" macro is
    non-constant, which triggered the BUG_ON() independently of the value
    returned by the macro.

    What we want to check here, is that *if* the macro was overridden to a
    compile-time constant, then must be defined to zero, otherwise it's a
    bug.

    So the correct check is:
    BUG_ON(__builtin_constant_p(cpu_has_counter) && cpu_has_counter);

    Signed-off-by: Paul Cercueil
    Signed-off-by: Thomas Bogendoerfer

    Paul Cercueil
     
  • XBurst CPUs present in Ingenic SoCs have virtually tagged caches,
    according to the header.

    Add that information to cpu_probe_ingenic().

    Signed-off-by: Paul Cercueil
    Signed-off-by: Thomas Bogendoerfer

    Paul Cercueil
     
  • Previously, in cpu_probe_ingenic(), c->writecombine was set to
    _CACHE_UNCACHED_ACCELERATED, but this macro was defined differently when
    CONFIG_MACH_INGENIC was set. This made it impossible to support multiple
    CPUs.

    Address this issue by setting c->writecombine to _CACHE_CACHABLE_WA
    directly and removing the dependency on CONFIG_MACH_INGENIC.

    Signed-off-by: Paul Cercueil
    Signed-off-by: Thomas Bogendoerfer

    Paul Cercueil
     

08 Sep, 2020

3 commits


03 Sep, 2020

2 commits

  • In cc97ab235f3f ("MIPS: Simplify FP context initialization), init_fp_ctx
    just initialize the fp/msa context, and own_fp_inatomic just restore
    FCSR and 64bit FP regs from it, but miss MSACSR and upper MSA regs for
    MSA, so MSACSR and MSA upper regs's value from previous task on current
    cpu can leak into current task and cause unpredictable behavior when MSA
    context not initialized.

    Fixes: cc97ab235f3f ("MIPS: Simplify FP context initialization")
    Signed-off-by: Huang Pei
    Signed-off-by: Thomas Bogendoerfer

    Huang Pei
     
  • The call simply looks up the corresponding task (without iterating
    the tasklist), which is safe under rcu instead of the tasklist_lock.
    In addition, the setaffinity counter part already does this.

    Signed-off-by: Davidlohr Bueso
    Signed-off-by: Thomas Bogendoerfer

    Davidlohr Bueso