23 Apr, 2020

1 commit

  • As the bug report [1] pointed out, must be included
    after .

    I believe we should not impose any include order restriction. We often
    sort include directives alphabetically, but it is just coding style
    convention. Technically, we can include header files in any order by
    making every header self-contained.

    Currently, arch-specific MODULE_ARCH_VERMAGIC is defined in
    , which is not included from .

    Hence, the straight-forward fix-up would be as follows:

    |--- a/include/linux/vermagic.h
    |+++ b/include/linux/vermagic.h
    |@@ -1,5 +1,6 @@
    | /* SPDX-License-Identifier: GPL-2.0 */
    | #include
    |+#include
    |
    | /* Simply sanity version stamp for modules. */
    | #ifdef CONFIG_SMP

    This works enough, but for further cleanups, I split MODULE_ARCH_VERMAGIC
    definitions into .

    With this, and will be orthogonal,
    and the location of MODULE_ARCH_VERMAGIC definitions will be consistent.

    For arc and ia64, MODULE_PROC_FAMILY is only used for defining
    MODULE_ARCH_VERMAGIC. I squashed it.

    For hexagon, nds32, and xtensa, I removed entirely
    because they contained nothing but MODULE_ARCH_VERMAGIC definition.
    Kbuild will automatically generate at build-time,
    wrapping .

    [1] https://lore.kernel.org/lkml/20200411155623.GA22175@zn.tnic

    Reported-by: Borislav Petkov
    Signed-off-by: Masahiro Yamada
    Acked-by: Jessica Yu

    Masahiro Yamada
     

11 Apr, 2020

4 commits

  • Merge yet more updates from Andrew Morton:

    - Almost all of the rest of MM (memcg, slab-generic, slab, pagealloc,
    gup, hugetlb, pagemap, memremap)

    - Various other things (hfs, ocfs2, kmod, misc, seqfile)

    * akpm: (34 commits)
    ipc/util.c: sysvipc_find_ipc() should increase position index
    kernel/gcov/fs.c: gcov_seq_next() should increase position index
    fs/seq_file.c: seq_read(): add info message about buggy .next functions
    drivers/dma/tegra20-apb-dma.c: fix platform_get_irq.cocci warnings
    change email address for Pali Rohár
    selftests: kmod: test disabling module autoloading
    selftests: kmod: fix handling test numbers above 9
    docs: admin-guide: document the kernel.modprobe sysctl
    fs/filesystems.c: downgrade user-reachable WARN_ONCE() to pr_warn_once()
    kmod: make request_module() return an error when autoloading is disabled
    mm/memremap: set caching mode for PCI P2PDMA memory to WC
    mm/memory_hotplug: add pgprot_t to mhp_params
    powerpc/mm: thread pgprot_t through create_section_mapping()
    x86/mm: introduce __set_memory_prot()
    x86/mm: thread pgprot_t through init_memory_mapping()
    mm/memory_hotplug: rename mhp_restrictions to mhp_params
    mm/memory_hotplug: drop the flags field from struct mhp_restrictions
    mm/special: create generic fallbacks for pte_special() and pte_mkspecial()
    mm/vma: introduce VM_ACCESS_FLAGS
    mm/vma: define a default value for VM_DATA_DEFAULT_FLAGS
    ...

    Linus Torvalds
     
  • Pull xtensa updates from Max Filippov:

    - replace setup_irq() by request_irq()

    - cosmetic fixes in xtensa Kconfig and boot/Makefile

    * tag 'xtensa-20200410' of git://github.com/jcmvbkbc/linux-xtensa:
    arch/xtensa: fix grammar in Kconfig help text
    xtensa: remove meaningless export ccflags-y
    xtensa: replace setup_irq() by request_irq()

    Linus Torvalds
     
  • Currently there are many platforms that dont enable ARCH_HAS_PTE_SPECIAL
    but required to define quite similar fallback stubs for special page
    table entry helpers such as pte_special() and pte_mkspecial(), as they
    get build in generic MM without a config check. This creates two
    generic fallback stub definitions for these helpers, eliminating much
    code duplication.

    mips platform has a special case where pte_special() and pte_mkspecial()
    visibility is wider than what ARCH_HAS_PTE_SPECIAL enablement requires.
    This restricts those symbol visibility in order to avoid redefinitions
    which is now exposed through this new generic stubs and subsequent build
    failure. arm platform set_pte_at() definition needs to be moved into a
    C file just to prevent a build failure.

    [anshuman.khandual@arm.com: use defined(CONFIG_ARCH_HAS_PTE_SPECIAL) in mips per Thomas]
    Link: http://lkml.kernel.org/r/1583851924-21603-1-git-send-email-anshuman.khandual@arm.com
    Signed-off-by: Anshuman Khandual
    Signed-off-by: Andrew Morton
    Acked-by: Guo Ren [csky]
    Acked-by: Geert Uytterhoeven [m68k]
    Acked-by: Stafford Horne [openrisc]
    Acked-by: Helge Deller [parisc]
    Cc: Richard Henderson
    Cc: Ivan Kokshaysky
    Cc: Matt Turner
    Cc: Russell King
    Cc: Brian Cain
    Cc: Tony Luck
    Cc: Fenghua Yu
    Cc: Sam Creasey
    Cc: Michal Simek
    Cc: Ralf Baechle
    Cc: Paul Burton
    Cc: Nick Hu
    Cc: Greentime Hu
    Cc: Vincent Chen
    Cc: Ley Foon Tan
    Cc: Jonas Bonn
    Cc: Stefan Kristiansson
    Cc: "James E.J. Bottomley"
    Cc: "David S. Miller"
    Cc: Jeff Dike
    Cc: Richard Weinberger
    Cc: Anton Ivanov
    Cc: Guan Xuetao
    Cc: Chris Zankel
    Cc: Max Filippov
    Cc: Thomas Bogendoerfer
    Link: http://lkml.kernel.org/r/1583802551-15406-1-git-send-email-anshuman.khandual@arm.com
    Signed-off-by: Linus Torvalds

    Anshuman Khandual
     
  • There are many platforms with exact same value for VM_DATA_DEFAULT_FLAGS
    This creates a default value for VM_DATA_DEFAULT_FLAGS in line with the
    existing VM_STACK_DEFAULT_FLAGS. While here, also define some more
    macros with standard VMA access flag combinations that are used
    frequently across many platforms. Apart from simplification, this
    reduces code duplication as well.

    Signed-off-by: Anshuman Khandual
    Signed-off-by: Andrew Morton
    Reviewed-by: Vlastimil Babka
    Acked-by: Geert Uytterhoeven
    Cc: Richard Henderson
    Cc: Vineet Gupta
    Cc: Russell King
    Cc: Catalin Marinas
    Cc: Mark Salter
    Cc: Guo Ren
    Cc: Yoshinori Sato
    Cc: Brian Cain
    Cc: Tony Luck
    Cc: Michal Simek
    Cc: Ralf Baechle
    Cc: Paul Burton
    Cc: Nick Hu
    Cc: Ley Foon Tan
    Cc: Jonas Bonn
    Cc: "James E.J. Bottomley"
    Cc: Michael Ellerman
    Cc: Paul Walmsley
    Cc: Heiko Carstens
    Cc: Rich Felker
    Cc: "David S. Miller"
    Cc: Guan Xuetao
    Cc: Thomas Gleixner
    Cc: Jeff Dike
    Cc: Chris Zankel
    Link: http://lkml.kernel.org/r/1583391014-8170-2-git-send-email-anshuman.khandual@arm.com
    Signed-off-by: Linus Torvalds

    Anshuman Khandual
     

08 Apr, 2020

1 commit

  • Generated files are also checked by sparse that's why add newline to
    remove sparse (C=1) warning.

    The issue was found on Microblaze and reported like this:
    ./arch/microblaze/include/generated/uapi/asm/unistd_32.h:438:45: warning:
    no newline at end of file

    Mips and PowerPC have it already but let's align with style used by m68k.

    Signed-off-by: Michal Simek
    Signed-off-by: Andrew Morton
    Reviewed-by: Stefan Asserhall
    Acked-by: Max Filippov (xtensa)
    Cc: Arnd Bergmann
    Cc: Max Filippov
    Cc: Benjamin Herrenschmidt
    Cc: Chris Zankel
    Cc: David S. Miller
    Cc: Fenghua Yu
    Cc: Helge Deller
    Cc: Ivan Kokshaysky
    Cc: James Bottomley
    Cc: Matt Turner
    Cc: Michael Ellerman
    Cc: Paul Burton
    Cc: Paul Mackerras
    Cc: Ralf Baechle
    Cc: Rich Felker
    Cc: Richard Henderson
    Cc: Tony Luck
    Cc: Yoshinori Sato
    Link: http://lkml.kernel.org/r/4d32ab4e1fb2edb691d2e1687e8fb303c09fd023.1581504803.git.michal.simek@xilinx.com
    Signed-off-by: Linus Torvalds

    Michal Simek
     

05 Apr, 2020

1 commit

  • Pull dma-mapping updates from Christoph Hellwig:

    - fix an integer overflow in the coherent pool (Kevin Grandemange)

    - provide support for in-place uncached remapping and use that for
    openrisc

    - fix the arm coherent allocator to take the bus limit into account

    * tag 'dma-mapping-5.7' of git://git.infradead.org/users/hch/dma-mapping:
    ARM/dma-mapping: merge __dma_supported into arm_dma_supported
    ARM/dma-mapping: take the bus limit into account in __dma_alloc
    ARM/dma-mapping: remove get_coherent_dma_mask
    openrisc: use the generic in-place uncached DMA allocator
    dma-direct: provide a arch_dma_clear_uncached hook
    dma-direct: make uncached_kernel_address more general
    dma-direct: consolidate the error handling in dma_direct_alloc_pages
    dma-direct: remove the cached_kernel_address hook
    dma-coherent: fix integer overflow in the reserved-memory dma allocation

    Linus Torvalds
     

04 Apr, 2020

1 commit

  • Pull SPDX updates from Greg KH:
    "Here are three SPDX patches for 5.7-rc1.

    One fixes up the SPDX tag for a single driver, while the other two go
    through the tree and add SPDX tags for all of the .gitignore files as
    needed.

    Nothing too complex, but you will get a merge conflict with your
    current tree, that should be trivial to handle (one file modified by
    two things, one file deleted.)

    All three of these have been in linux-next for a while, with no
    reported issues other than the merge conflict"

    * tag 'spdx-5.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/spdx:
    ASoC: MT6660: make spdxcheck.py happy
    .gitignore: add SPDX License Identifier
    .gitignore: remove too obvious comments

    Linus Torvalds
     

03 Apr, 2020

4 commits

  • The idea comes from a discussion between Linus and Andrea [1].

    Before this patch we only allow a page fault to retry once. We achieved
    this by clearing the FAULT_FLAG_ALLOW_RETRY flag when doing
    handle_mm_fault() the second time. This was majorly used to avoid
    unexpected starvation of the system by looping over forever to handle the
    page fault on a single page. However that should hardly happen, and after
    all for each code path to return a VM_FAULT_RETRY we'll first wait for a
    condition (during which time we should possibly yield the cpu) to happen
    before VM_FAULT_RETRY is really returned.

    This patch removes the restriction by keeping the FAULT_FLAG_ALLOW_RETRY
    flag when we receive VM_FAULT_RETRY. It means that the page fault handler
    now can retry the page fault for multiple times if necessary without the
    need to generate another page fault event. Meanwhile we still keep the
    FAULT_FLAG_TRIED flag so page fault handler can still identify whether a
    page fault is the first attempt or not.

    Then we'll have these combinations of fault flags (only considering
    ALLOW_RETRY flag and TRIED flag):

    - ALLOW_RETRY and !TRIED: this means the page fault allows to
    retry, and this is the first try

    - ALLOW_RETRY and TRIED: this means the page fault allows to
    retry, and this is not the first try

    - !ALLOW_RETRY and !TRIED: this means the page fault does not allow
    to retry at all

    - !ALLOW_RETRY and TRIED: this is forbidden and should never be used

    In existing code we have multiple places that has taken special care of
    the first condition above by checking against (fault_flags &
    FAULT_FLAG_ALLOW_RETRY). This patch introduces a simple helper to detect
    the first retry of a page fault by checking against both (fault_flags &
    FAULT_FLAG_ALLOW_RETRY) and !(fault_flag & FAULT_FLAG_TRIED) because now
    even the 2nd try will have the ALLOW_RETRY set, then use that helper in
    all existing special paths. One example is in __lock_page_or_retry(), now
    we'll drop the mmap_sem only in the first attempt of page fault and we'll
    keep it in follow up retries, so old locking behavior will be retained.

    This will be a nice enhancement for current code [2] at the same time a
    supporting material for the future userfaultfd-writeprotect work, since in
    that work there will always be an explicit userfault writeprotect retry
    for protected pages, and if that cannot resolve the page fault (e.g., when
    userfaultfd-writeprotect is used in conjunction with swapped pages) then
    we'll possibly need a 3rd retry of the page fault. It might also benefit
    other potential users who will have similar requirement like userfault
    write-protection.

    GUP code is not touched yet and will be covered in follow up patch.

    Please read the thread below for more information.

    [1] https://lore.kernel.org/lkml/20171102193644.GB22686@redhat.com/
    [2] https://lore.kernel.org/lkml/20181230154648.GB9832@redhat.com/

    Suggested-by: Linus Torvalds
    Suggested-by: Andrea Arcangeli
    Signed-off-by: Peter Xu
    Signed-off-by: Andrew Morton
    Tested-by: Brian Geffon
    Cc: Bobby Powers
    Cc: David Hildenbrand
    Cc: Denis Plotnikov
    Cc: "Dr . David Alan Gilbert"
    Cc: Hugh Dickins
    Cc: Jerome Glisse
    Cc: Johannes Weiner
    Cc: "Kirill A . Shutemov"
    Cc: Martin Cracauer
    Cc: Marty McFadden
    Cc: Matthew Wilcox
    Cc: Maya Gokhale
    Cc: Mel Gorman
    Cc: Mike Kravetz
    Cc: Mike Rapoport
    Cc: Pavel Emelyanov
    Link: http://lkml.kernel.org/r/20200220160246.9790-1-peterx@redhat.com
    Signed-off-by: Linus Torvalds

    Peter Xu
     
  • Although there're tons of arch-specific page fault handlers, most of them
    are still sharing the same initial value of the page fault flags. Say,
    merely all of the page fault handlers would allow the fault to be retried,
    and they also allow the fault to respond to SIGKILL.

    Let's define a default value for the fault flags to replace those initial
    page fault flags that were copied over. With this, it'll be far easier to
    introduce new fault flag that can be used by all the architectures instead
    of touching all the archs.

    Signed-off-by: Peter Xu
    Signed-off-by: Andrew Morton
    Tested-by: Brian Geffon
    Reviewed-by: David Hildenbrand
    Cc: Andrea Arcangeli
    Cc: Bobby Powers
    Cc: Denis Plotnikov
    Cc: "Dr . David Alan Gilbert"
    Cc: Hugh Dickins
    Cc: Jerome Glisse
    Cc: Johannes Weiner
    Cc: "Kirill A . Shutemov"
    Cc: Martin Cracauer
    Cc: Marty McFadden
    Cc: Matthew Wilcox
    Cc: Maya Gokhale
    Cc: Mel Gorman
    Cc: Mike Kravetz
    Cc: Mike Rapoport
    Cc: Pavel Emelyanov
    Link: http://lkml.kernel.org/r/20200220160238.9694-1-peterx@redhat.com
    Signed-off-by: Linus Torvalds

    Peter Xu
     
  • For most architectures, we've got a quick path to detect fatal signal
    after a handle_mm_fault(). Introduce a helper for that quick path.

    It cleans the current codes a bit so we don't need to duplicate the same
    check across archs. More importantly, this will be an unified place that
    we handle the signal immediately right after an interrupted page fault, so
    it'll be much easier for us if we want to change the behavior of handling
    signals later on for all the archs.

    Note that currently only part of the archs are using this new helper,
    because some archs have their own way to handle signals. In the follow up
    patches, we'll try to apply this helper to all the rest of archs.

    Another note is that the "regs" parameter in the new helper is not used
    yet. It'll be used very soon. Now we kept it in this patch only to avoid
    touching all the archs again in the follow up patches.

    [peterx@redhat.com: fix sparse warnings]
    Link: http://lkml.kernel.org/r/20200311145921.GD479302@xz-x1
    Signed-off-by: Peter Xu
    Signed-off-by: Andrew Morton
    Tested-by: Brian Geffon
    Cc: Andrea Arcangeli
    Cc: Bobby Powers
    Cc: David Hildenbrand
    Cc: Denis Plotnikov
    Cc: "Dr . David Alan Gilbert"
    Cc: Hugh Dickins
    Cc: Jerome Glisse
    Cc: Johannes Weiner
    Cc: "Kirill A . Shutemov"
    Cc: Martin Cracauer
    Cc: Marty McFadden
    Cc: Matthew Wilcox
    Cc: Maya Gokhale
    Cc: Mel Gorman
    Cc: Mike Kravetz
    Cc: Mike Rapoport
    Cc: Pavel Emelyanov
    Link: http://lkml.kernel.org/r/20200220155353.8676-4-peterx@redhat.com
    Signed-off-by: Linus Torvalds

    Peter Xu
     
  • Change a header to mandatory-y if both of the following are met:

    [1] At least one architecture (except um) specifies it as generic-y in
    arch/*/include/asm/Kbuild

    [2] Every architecture (except um) either has its own implementation
    (arch/*/include/asm/*.h) or specifies it as generic-y in
    arch/*/include/asm/Kbuild

    This commit was generated by the following shell script.

    ----------------------------------->8-----------------------------------

    arches=$(cd arch; ls -1 | sed -e '/Kconfig/d' -e '/um/d')

    tmpfile=$(mktemp)

    grep "^mandatory-y +=" include/asm-generic/Kbuild > $tmpfile

    find arch -path 'arch/*/include/asm/Kbuild' |
    xargs sed -n 's/^generic-y += \(.*\)/\1/p' | sort -u |
    while read header
    do
    mandatory=yes

    for arch in $arches
    do
    if ! grep -q "generic-y += $header" arch/$arch/include/asm/Kbuild &&
    ! [ -f arch/$arch/include/asm/$header ]; then
    mandatory=no
    break
    fi
    done

    if [ "$mandatory" = yes ]; then
    echo "mandatory-y += $header" >> $tmpfile

    for arch in $arches
    do
    sed -i "/generic-y += $header/d" arch/$arch/include/asm/Kbuild
    done
    fi

    done

    sed -i '/^mandatory-y +=/d' include/asm-generic/Kbuild

    LANG=C sort $tmpfile >> include/asm-generic/Kbuild

    ----------------------------------->8-----------------------------------

    One obvious benefit is the diff stat:

    25 files changed, 52 insertions(+), 557 deletions(-)

    It is tedious to list generic-y for each arch that needs it.

    So, mandatory-y works like a fallback default (by just wrapping
    asm-generic one) when arch does not have a specific header
    implementation.

    See the following commits:

    def3f7cefe4e81c296090e1722a76551142c227c
    a1b39bae16a62ce4aae02d958224f19316d98b24

    It is tedious to convert headers one by one, so I processed by a shell
    script.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Andrew Morton
    Cc: Michal Simek
    Cc: Christoph Hellwig
    Cc: Arnd Bergmann
    Link: http://lkml.kernel.org/r/20200210175452.5030-1-masahiroy@kernel.org
    Signed-off-by: Linus Torvalds

    Masahiro Yamada
     

31 Mar, 2020

2 commits

  • Pull locking updates from Ingo Molnar:
    "The main changes in this cycle were:

    - Continued user-access cleanups in the futex code.

    - percpu-rwsem rewrite that uses its own waitqueue and atomic_t
    instead of an embedded rwsem. This addresses a couple of
    weaknesses, but the primary motivation was complications on the -rt
    kernel.

    - Introduce raw lock nesting detection on lockdep
    (CONFIG_PROVE_RAW_LOCK_NESTING=y), document the raw_lock vs. normal
    lock differences. This too originates from -rt.

    - Reuse lockdep zapped chain_hlocks entries, to conserve RAM
    footprint on distro-ish kernels running into the "BUG:
    MAX_LOCKDEP_CHAIN_HLOCKS too low!" depletion of the lockdep
    chain-entries pool.

    - Misc cleanups, smaller fixes and enhancements - see the changelog
    for details"

    * 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (55 commits)
    fs/buffer: Make BH_Uptodate_Lock bit_spin_lock a regular spinlock_t
    thermal/x86_pkg_temp: Make pkg_temp_lock a raw_spinlock_t
    Documentation/locking/locktypes: Minor copy editor fixes
    Documentation/locking/locktypes: Further clarifications and wordsmithing
    m68knommu: Remove mm.h include from uaccess_no.h
    x86: get rid of user_atomic_cmpxchg_inatomic()
    generic arch_futex_atomic_op_inuser() doesn't need access_ok()
    x86: don't reload after cmpxchg in unsafe_atomic_op2() loop
    x86: convert arch_futex_atomic_op_inuser() to user_access_begin/user_access_end()
    objtool: whitelist __sanitizer_cov_trace_switch()
    [parisc, s390, sparc64] no need for access_ok() in futex handling
    sh: no need of access_ok() in arch_futex_atomic_op_inuser()
    futex: arch_futex_atomic_op_inuser() calling conventions change
    completion: Use lockdep_assert_RT_in_threaded_ctx() in complete_all()
    lockdep: Add posixtimer context tracing bits
    lockdep: Annotate irq_work
    lockdep: Add hrtimer context tracing bits
    lockdep: Introduce wait-type checks
    completion: Use simple wait queues
    sched/swait: Prepare usage in completions
    ...

    Linus Torvalds
     
  • Spell "Don't" correctly in the XTENSA_VARIANT_CUSTOM_NAME help text.

    Signed-off-by: Hu Haowen
    Message-Id:
    Signed-off-by: Max Filippov

    Hu Haowen
     

28 Mar, 2020

2 commits

  • Move access_ok() in and pagefault_enable()/pagefault_disable() out.
    Mechanical conversion only - some instances don't really need
    a separate access_ok() at all (e.g. the ones only using
    get_user()/put_user(), or architectures where access_ok()
    is always true); we'll deal with that in followups.

    Signed-off-by: Al Viro

    Al Viro
     
  • Current make_request based drivers use either blk_alloc_queue_node or
    blk_alloc_queue to allocate a queue, and then set up the make_request_fn
    function pointer and a few parameters using the blk_queue_make_request
    helper. Simplify this by passing the make_request pointer to
    blk_alloc_queue, and while at it merge the _node variant into the main
    helper by always passing a node_id, and remove the superfluous gfp_mask
    parameter. A lower-level __blk_alloc_queue is kept for the blk-mq case.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Jens Axboe

    Christoph Hellwig
     

25 Mar, 2020

1 commit


16 Mar, 2020

2 commits


10 Mar, 2020

1 commit


04 Mar, 2020

1 commit

  • request_irq() is preferred over setup_irq(). Invocations of setup_irq()
    occur after memory allocators are ready.

    Per tglx[1], setup_irq() existed in olden days when allocators were not
    ready by the time early interrupts were initialized.

    Hence replace setup_irq() by request_irq().

    [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos

    Signed-off-by: afzal mohammed
    Message-Id:
    Signed-off-by: Max Filippov

    afzal mohammed
     

08 Feb, 2020

1 commit

  • Pull xtensa updates from Max Filippov:

    - reorganize exception vectors placement

    - small cleanups (drop unused functions/headers/defconfig entries,
    spelling fixes)

    * tag 'xtensa-20200206' of git://github.com/jcmvbkbc/linux-xtensa:
    xtensa: ISS: improve simcall assembly
    xtensa: reorganize vectors placement
    xtensa: separate SMP and XIP support
    xtensa: move fast exception handlers close to vectors
    arch/xtensa: fix Kconfig typos for HAVE_SMP
    xtensa: clean up optional XCHAL_* definitions
    xtensa: drop unused function fast_coprocessor_double
    xtensa: drop empty platform_* functions from platforms
    xtensa: clean up platform headers
    xtensa: drop set_except_vector declaration
    xtensa: configs: Cleanup old Kconfig IO scheduler options

    Linus Torvalds
     

05 Feb, 2020

4 commits

  • Drop redundant result moving from inline assembly, use a1 and b1 values
    as return value and errno value respectively.

    Signed-off-by: Max Filippov

    Max Filippov
     
  • Allow vectors to be either merged into the kernel .text or put at a
    fixed virtual address independently of XIP option. Drop option that
    puts vectors at a fixed offset from the kernel text. Add choice to
    Kconfig.
    Vectors at fixed virtual address may be useful for XIP-aware MTD support
    and for noMMU configurations with available IRAM. Configurations without
    VECBASE register must put their vectors at specific locations regardless
    of the selected option. All other configurations should happily use
    merged vectors.

    Signed-off-by: Max Filippov

    Max Filippov
     
  • There's no real dependency between SMP and XIP, allow them to be
    selected together. Always define 2- and 4-argument SECTION_VECTOR
    macros, always use 4-argument macro for the secondary reset vector and
    always define relocation entry for it.

    Signed-off-by: Max Filippov

    Max Filippov
     
  • On XIP kernels it makes sense to have exception vectors and fast
    exception handlers together (in a fast memory). In addition, with MTD
    XIP support both vectors and fast exception handlers must be outside of
    the FLASH.

    Add section .exception.text and move fast exception handlers to it.
    Put it together with vectors when vectors are outside of the .text.

    Signed-off-by: Max Filippov

    Max Filippov
     

04 Feb, 2020

3 commits

  • Pull Microblaze update from Michal Simek:

    - enable CMA

    - add support for MB v11

    - defconfig updates

    - minor fixes

    * tag 'microblaze-v5.6-rc1' of git://git.monstr.eu/linux-2.6-microblaze:
    microblaze: Add ID for Microblaze v11
    microblaze: Prevent the overflow of the start
    microblaze: Wire CMA allocator
    asm-generic: Make dma-contiguous.h a mandatory include/asm header
    microblaze: Sync defconfig with latest Kconfig layout
    microblaze: defconfig: Disable EXT2 driver and Enable EXT3 & EXT4 drivers
    microblaze: Align comments with register usage

    Linus Torvalds
     
  • dma-continuguous.h is generic for all architectures except arm32 which has
    its own version.

    Similar change was done for msi.h by commit a1b39bae16a6
    ("asm-generic: Make msi.h a mandatory include/asm header")

    Suggested-by: Christoph Hellwig
    Link: https://lore.kernel.org/linux-arm-kernel/20200117080446.GA8980@lst.de/T/#m92bb56b04161057635d4142e1b3b9b6b0a70122e
    Signed-off-by: Michal Simek
    Reviewed-by: Christoph Hellwig
    Acked-by: Thomas Gleixner
    Acked-by: Arnd Bergmann
    Acked-by: Paul Walmsley # for arch/riscv

    Michal Simek
     
  • The most notable change is DEFINE_SHOW_ATTRIBUTE macro split in
    seq_file.h.

    Conversion rule is:

    llseek => proc_lseek
    unlocked_ioctl => proc_ioctl

    xxx => proc_xxx

    delete ".owner = THIS_MODULE" line

    [akpm@linux-foundation.org: fix drivers/isdn/capi/kcapi_proc.c]
    [sfr@canb.auug.org.au: fix kernel/sched/psi.c]
    Link: http://lkml.kernel.org/r/20200122180545.36222f50@canb.auug.org.au
    Link: http://lkml.kernel.org/r/20191225172546.GB13378@avx2
    Signed-off-by: Alexey Dobriyan
    Signed-off-by: Stephen Rothwell
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

01 Feb, 2020

6 commits


31 Jan, 2020

1 commit


30 Jan, 2020

4 commits

  • Pull thread management updates from Christian Brauner:
    "Sargun Dhillon over the last cycle has worked on the pidfd_getfd()
    syscall.

    This syscall allows for the retrieval of file descriptors of a process
    based on its pidfd. A task needs to have ptrace_may_access()
    permissions with PTRACE_MODE_ATTACH_REALCREDS (suggested by Oleg and
    Andy) on the target.

    One of the main use-cases is in combination with seccomp's user
    notification feature. As a reminder, seccomp's user notification
    feature was made available in v5.0. It allows a task to retrieve a
    file descriptor for its seccomp filter. The file descriptor is usually
    handed of to a more privileged supervising process. The supervisor can
    then listen for syscall events caught by the seccomp filter of the
    supervisee and perform actions in lieu of the supervisee, usually
    emulating syscalls. pidfd_getfd() is needed to expand its uses.

    There are currently two major users that wait on pidfd_getfd() and one
    future user:

    - Netflix, Sargun said, is working on a service mesh where users
    should be able to connect to a dns-based VIP. When a user connects
    to e.g. 1.2.3.4:80 that runs e.g. service "foo" they will be
    redirected to an envoy process. This service mesh uses seccomp user
    notifications and pidfd to intercept all connect calls and instead
    of connecting them to 1.2.3.4:80 connects them to e.g.
    127.0.0.1:8080.

    - LXD uses the seccomp notifier heavily to intercept and emulate
    mknod() and mount() syscalls for unprivileged containers/processes.
    With pidfd_getfd() more uses-cases e.g. bridging socket connections
    will be possible.

    - The patchset has also seen some interest from the browser corner.
    Right now, Firefox is using a SECCOMP_RET_TRAP sandbox managed by a
    broker process. In the future glibc will start blocking all signals
    during dlopen() rendering this type of sandbox impossible. Hence,
    in the future Firefox will switch to a seccomp-user-nofication
    based sandbox which also makes use of file descriptor retrieval.
    The thread for this can be found at
    https://sourceware.org/ml/libc-alpha/2019-12/msg00079.html

    With pidfd_getfd() it is e.g. possible to bridge socket connections
    for the supervisee (binding to a privileged port) and taking actions
    on file descriptors on behalf of the supervisee in general.

    Sargun's first version was using an ioctl on pidfds but various people
    pushed for it to be a proper syscall which he duely implemented as
    well over various review cycles. Selftests are of course included.
    I've also added instructions how to deal with merge conflicts below.

    There's also a small fix coming from the kernel mentee project to
    correctly annotate struct sighand_struct with __rcu to fix various
    sparse warnings. We've received a few more such fixes and even though
    they are mostly trivial I've decided to postpone them until after -rc1
    since they came in rather late and I don't want to risk introducing
    build warnings.

    Finally, there's a new prctl() command PR_{G,S}ET_IO_FLUSHER which is
    needed to avoid allocation recursions triggerable by storage drivers
    that have userspace parts that run in the IO path (e.g. dm-multipath,
    iscsi, etc). These allocation recursions deadlock the device.

    The new prctl() allows such privileged userspace components to avoid
    allocation recursions by setting the PF_MEMALLOC_NOIO and
    PF_LESS_THROTTLE flags. The patch carries the necessary acks from the
    relevant maintainers and is routed here as part of prctl()
    thread-management."

    * tag 'threads-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux:
    prctl: PR_{G,S}ET_IO_FLUSHER to support controlling memory reclaim
    sched.h: Annotate sighand_struct with __rcu
    test: Add test for pidfd getfd
    arch: wire up pidfd_getfd syscall
    pid: Implement pidfd_getfd syscall
    vfs, fdtable: Add fget_task helper

    Linus Torvalds
     
  • …/kernel/git/arnd/playground

    Pull y2038 updates from Arnd Bergmann:
    "Core, driver and file system changes

    These are updates to device drivers and file systems that for some
    reason or another were not included in the kernel in the previous
    y2038 series.

    I've gone through all users of time_t again to make sure the kernel is
    in a long-term maintainable state, replacing all remaining references
    to time_t with safe alternatives.

    Some related parts of the series were picked up into the nfsd, xfs,
    alsa and v4l2 trees. A final set of patches in linux-mm removes the
    now unused time_t/timeval/timespec types and helper functions after
    all five branches are merged for linux-5.6, ensuring that no new users
    get merged.

    As a result, linux-5.6, or my backport of the patches to 5.4 [1],
    should be the first release that can serve as a base for a 32-bit
    system designed to run beyond year 2038, with a few remaining caveats:

    - All user space must be compiled with a 64-bit time_t, which will be
    supported in the coming musl-1.2 and glibc-2.32 releases, along
    with installed kernel headers from linux-5.6 or higher.

    - Applications that use the system call interfaces directly need to
    be ported to use the time64 syscalls added in linux-5.1 in place of
    the existing system calls. This impacts most users of futex() and
    seccomp() as well as programming languages that have their own
    runtime environment not based on libc.

    - Applications that use a private copy of kernel uapi header files or
    their contents may need to update to the linux-5.6 version, in
    particular for sound/asound.h, xfs/xfs_fs.h, linux/input.h,
    linux/elfcore.h, linux/sockios.h, linux/timex.h and
    linux/can/bcm.h.

    - A few remaining interfaces cannot be changed to pass a 64-bit
    time_t in a compatible way, so they must be configured to use
    CLOCK_MONOTONIC times or (with a y2106 problem) unsigned 32-bit
    timestamps. Most importantly this impacts all users of 'struct
    input_event'.

    - All y2038 problems that are present on 64-bit machines also apply
    to 32-bit machines. In particular this affects file systems with
    on-disk timestamps using signed 32-bit seconds: ext4 with
    ext3-style small inodes, ext2, xfs (to be fixed soon) and ufs"

    [1] https://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git/log/?h=y2038-endgame

    * tag 'y2038-drivers-for-v5.6-signed' of git://git.kernel.org:/pub/scm/linux/kernel/git/arnd/playground: (21 commits)
    Revert "drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC"
    y2038: sh: remove timeval/timespec usage from headers
    y2038: sparc: remove use of struct timex
    y2038: rename itimerval to __kernel_old_itimerval
    y2038: remove obsolete jiffies conversion functions
    nfs: fscache: use timespec64 in inode auxdata
    nfs: fix timstamp debug prints
    nfs: use time64_t internally
    sunrpc: convert to time64_t for expiry
    drm/etnaviv: avoid deprecated timespec
    drm/etnaviv: reject timeouts with tv_nsec >= NSEC_PER_SEC
    drm/msm: avoid using 'timespec'
    hfs/hfsplus: use 64-bit inode timestamps
    hostfs: pass 64-bit timestamps to/from user space
    packet: clarify timestamp overflow
    tsacct: add 64-bit btime field
    acct: stop using get_seconds()
    um: ubd: use 64-bit time_t where possible
    xtensa: ISS: avoid struct timeval
    dlm: use SO_SNDTIMEO_NEW instead of SO_SNDTIMEO_OLD
    ...

    Linus Torvalds
     
  • Pull openat2 support from Al Viro:
    "This is the openat2() series from Aleksa Sarai.

    I'm afraid that the rest of namei stuff will have to wait - it got
    zero review the last time I'd posted #work.namei, and there had been a
    leak in the posted series I'd caught only last weekend. I was going to
    repost it on Monday, but the window opened and the odds of getting any
    review during that... Oh, well.

    Anyway, openat2 part should be ready; that _did_ get sane amount of
    review and public testing, so here it comes"

    From Aleksa's description of the series:
    "For a very long time, extending openat(2) with new features has been
    incredibly frustrating. This stems from the fact that openat(2) is
    possibly the most famous counter-example to the mantra "don't silently
    accept garbage from userspace" -- it doesn't check whether unknown
    flags are present[1].

    This means that (generally) the addition of new flags to openat(2) has
    been fraught with backwards-compatibility issues (O_TMPFILE has to be
    defined as __O_TMPFILE|O_DIRECTORY|[O_RDWR or O_WRONLY] to ensure old
    kernels gave errors, since it's insecure to silently ignore the
    flag[2]). All new security-related flags therefore have a tough road
    to being added to openat(2).

    Furthermore, the need for some sort of control over VFS's path
    resolution (to avoid malicious paths resulting in inadvertent
    breakouts) has been a very long-standing desire of many userspace
    applications.

    This patchset is a revival of Al Viro's old AT_NO_JUMPS[3] patchset
    (which was a variant of David Drysdale's O_BENEATH patchset[4] which
    was a spin-off of the Capsicum project[5]) with a few additions and
    changes made based on the previous discussion within [6] as well as
    others I felt were useful.

    In line with the conclusions of the original discussion of
    AT_NO_JUMPS, the flag has been split up into separate flags. However,
    instead of being an openat(2) flag it is provided through a new
    syscall openat2(2) which provides several other improvements to the
    openat(2) interface (see the patch description for more details). The
    following new LOOKUP_* flags are added:

    LOOKUP_NO_XDEV:

    Blocks all mountpoint crossings (upwards, downwards, or through
    absolute links). Absolute pathnames alone in openat(2) do not
    trigger this. Magic-link traversal which implies a vfsmount jump is
    also blocked (though magic-link jumps on the same vfsmount are
    permitted).

    LOOKUP_NO_MAGICLINKS:

    Blocks resolution through /proc/$pid/fd-style links. This is done
    by blocking the usage of nd_jump_link() during resolution in a
    filesystem. The term "magic-links" is used to match with the only
    reference to these links in Documentation/, but I'm happy to change
    the name.

    It should be noted that this is different to the scope of
    ~LOOKUP_FOLLOW in that it applies to all path components. However,
    you can do openat2(NO_FOLLOW|NO_MAGICLINKS) on a magic-link and it
    will *not* fail (assuming that no parent component was a
    magic-link), and you will have an fd for the magic-link.

    In order to correctly detect magic-links, the introduction of a new
    LOOKUP_MAGICLINK_JUMPED state flag was required.

    LOOKUP_BENEATH:

    Disallows escapes to outside the starting dirfd's
    tree, using techniques such as ".." or absolute links. Absolute
    paths in openat(2) are also disallowed.

    Conceptually this flag is to ensure you "stay below" a certain
    point in the filesystem tree -- but this requires some additional
    to protect against various races that would allow escape using
    "..".

    Currently LOOKUP_BENEATH implies LOOKUP_NO_MAGICLINKS, because it
    can trivially beam you around the filesystem (breaking the
    protection). In future, there might be similar safety checks done
    as in LOOKUP_IN_ROOT, but that requires more discussion.

    In addition, two new flags are added that expand on the above ideas:

    LOOKUP_NO_SYMLINKS:

    Does what it says on the tin. No symlink resolution is allowed at
    all, including magic-links. Just as with LOOKUP_NO_MAGICLINKS this
    can still be used with NOFOLLOW to open an fd for the symlink as
    long as no parent path had a symlink component.

    LOOKUP_IN_ROOT:

    This is an extension of LOOKUP_BENEATH that, rather than blocking
    attempts to move past the root, forces all such movements to be
    scoped to the starting point. This provides chroot(2)-like
    protection but without the cost of a chroot(2) for each filesystem
    operation, as well as being safe against race attacks that
    chroot(2) is not.

    If a race is detected (as with LOOKUP_BENEATH) then an error is
    generated, and similar to LOOKUP_BENEATH it is not permitted to
    cross magic-links with LOOKUP_IN_ROOT.

    The primary need for this is from container runtimes, which
    currently need to do symlink scoping in userspace[7] when opening
    paths in a potentially malicious container.

    There is a long list of CVEs that could have bene mitigated by
    having RESOLVE_THIS_ROOT (such as CVE-2017-1002101,
    CVE-2017-1002102, CVE-2018-15664, and CVE-2019-5736, just to name a
    few).

    In order to make all of the above more usable, I'm working on
    libpathrs[8] which is a C-friendly library for safe path resolution.
    It features a userspace-emulated backend if the kernel doesn't support
    openat2(2). Hopefully we can get userspace to switch to using it, and
    thus get openat2(2) support for free once it's ready.

    Future work would include implementing things like
    RESOLVE_NO_AUTOMOUNT and possibly a RESOLVE_NO_REMOTE (to allow
    programs to be sure they don't hit DoSes though stale NFS handles)"

    * 'work.openat2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
    Documentation: path-lookup: include new LOOKUP flags
    selftests: add openat2(2) selftests
    open: introduce openat2(2) syscall
    namei: LOOKUP_{IN_ROOT,BENEATH}: permit limited ".." resolution
    namei: LOOKUP_IN_ROOT: chroot-like scoped resolution
    namei: LOOKUP_BENEATH: O_BENEATH-like scoped resolution
    namei: LOOKUP_NO_XDEV: block mountpoint crossing
    namei: LOOKUP_NO_MAGICLINKS: block magic-link resolution
    namei: LOOKUP_NO_SYMLINKS: block symlink resolution
    namei: allow set_root() to produce errors
    namei: allow nd_jump_link() to produce errors
    nsfs: clean-up ns_get_path() signature to return int
    namei: only return -ECHILD from follow_dotdot_rcu()

    Linus Torvalds
     
  • Pull tty/serial driver updates from Greg KH:
    "Here are the big set of tty and serial driver updates for 5.6-rc1

    Included in here are:
    - dummy_con cleanups (touches lots of arch code)
    - sysrq logic cleanups (touches lots of serial drivers)
    - samsung driver fixes (wasn't really being built)
    - conmakeshash move to tty subdir out of scripts
    - lots of small tty/serial driver updates

    All of these have been in linux-next for a while with no reported
    issues"

    * tag 'tty-5.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (140 commits)
    tty: n_hdlc: Use flexible-array member and struct_size() helper
    tty: baudrate: SPARC supports few more baud rates
    tty: baudrate: Synchronise baud_table[] and baud_bits[]
    tty: serial: meson_uart: Add support for kernel debugger
    serial: imx: fix a race condition in receive path
    serial: 8250_bcm2835aux: Document struct bcm2835aux_data
    serial: 8250_bcm2835aux: Use generic remapping code
    serial: 8250_bcm2835aux: Allocate uart_8250_port on stack
    serial: 8250_bcm2835aux: Suppress register_port error on -EPROBE_DEFER
    serial: 8250_bcm2835aux: Suppress clk_get error on -EPROBE_DEFER
    serial: 8250_bcm2835aux: Fix line mismatch on driver unbind
    serial_core: Remove unused member in uart_port
    vt: Correct comment documenting do_take_over_console()
    vt: Delete comment referencing non-existent unbind_con_driver()
    arch/xtensa/setup: Drop dummy_con initialization
    arch/x86/setup: Drop dummy_con initialization
    arch/unicore32/setup: Drop dummy_con initialization
    arch/sparc/setup: Drop dummy_con initialization
    arch/sh/setup: Drop dummy_con initialization
    arch/s390/setup: Drop dummy_con initialization
    ...

    Linus Torvalds