1. 26 9月, 2016 18 次提交
    • G
      m68k: always make available dump_fpu() · 8912eacc
      Greg Ungerer 提交于
      Our local m68k architecture dump_fpu() is conditionally compiled in on
      CONFIG_FPU. That is OK for all existing MMU enabled CPU types, but won't
      handle the case for some ColdFire SoC CPU parts that we want to support
      that have no FPU hardware.
      
      dump_fpu() is expected to be present by the ELF loader, so we must always
      have it available and exported.
      
      Remove the conditional and reorganize the dump_fpu hard FPU code path
      to let the compiler remove code when not needed.
      
      This change based on changes and discussion from Yannick Gicquel
      <yannick.gicquel@open.eurogiciel.org>.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      8912eacc
    • G
      m68k: generalize io memory region setup for ColdFire ACR registers · 8cf4a973
      Greg Ungerer 提交于
      The ACR registers of the ColdFire define at a macro level what regions
      of the addresses space should have caching or other attribute types applied.
      
      Currently for the MMU enabled setups we map the interal IO peripheral addres
      space as uncachable based on the define for the MBAR address (CONFIG_MBAR).
      Not all ColdFire SoC use a programmable MBAR register address. Some parts
      have fixed addressing for their internal peripheral registers.
      
      Generalize the way we get the internal peripheral base address so all types
      can be accomodated in the ACR definitions. Each ColdFire SoC type now sets
      its IO memory base and size definitions (which may be based on MBAR) which
      are then used in the ACR definitions.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      8cf4a973
    • G
      m68k: move ColdFire _bootmem_alloc code · f7116065
      Greg Ungerer 提交于
      The early ColdFire bootmem_alloc() code is currently only included in
      the board support for the Coldire 54xx platforms. It will be used on all
      ColdFire MMU enabled platforms as others are supported. So move the
      mcf54xx_bootmem_alloc() function to be generally available to all MMU
      enabled ColdFire parts (and use a more generic name for it).
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      f7116065
    • G
      m68k: report correct FPU type on ColdFire MMU platforms · cbd5b982
      Greg Ungerer 提交于
      Not all ColdFire SoC parts that have an MMU also have an FPU - so set
      an FPU type (via m68k_fputype) appropriate for the configured platform.
      
      With this set correctly /proc/cpuinfo will report FPU "none" on devices
      that don't have one. And kernel code paths that initialize FPU hardware
      will now only execute if an FPU is actually present.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      cbd5b982
    • G
      m68k: set appropriate machine type for m5411x SoC platforms · 81d33350
      Greg Ungerer 提交于
      Create a new machine type for platforms based around the ColdFire 5441x
      SoC family. Set that machine type on startup when building for this
      platform type.
      
      Currently the ColdFire head.S hard codes a M54xx machine type at startup -
      since that is the only platform type currently supported with MMU enabled.
      The m5441x has an MMU and this change forms part of the support required
      to run it with the MMU enabled.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      81d33350
    • G
      m68k: move CONFIG_FPU set to per-CPU configuration · e5f8d1f0
      Greg Ungerer 提交于
      Move the selection of CONFIG_FPU to each CPU type configuration.
      
      Currently for m68k we have a global set of CONFIG_FPU based on if CONFIG_MMU
      is enabled or not. There is at least one CPU family we support (m5441x)
      that has an MMU but has no FPU hardware. So we need to be able to have
      CONFIG_MMU set and CONFIG_FPU not set.
      
      Whether we build for a CPU with MMU enabled or not doesn't change the
      fact that it has FPU hardware support. Our current non-MMU builds have
      never had CONIG_FPU enabled - and in fact the kernel will not compile
      with that set and CONFIG_MMU not set at the moment. It is easy enough
      to fix this - but it would involve a structure change to sigcontext.h,
      and that is a user space exported header (so ABI change).
      
      This change makes no configuration visible changes, and all configs
      end up with the same configuration settings as before.
      
      This change based on changes and discussion from Yannick Gicquel
      <yannick.gicquel@open.eurogiciel.org>.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      e5f8d1f0
    • G
      m68knommu: fix IO write size in nettel pin set · 36d050d9
      Greg Ungerer 提交于
      The pin write code that supports the UART signals is not using he correct
      word write IO access method. It correctly reads the correct 16 bit
      registrer, it should also write the new value back with a 16 bit write.
      Fix it to use writew().
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      36d050d9
    • G
      m68knommu: switch to using IO access methods in WildFire board code · 41b39ea1
      Greg Ungerer 提交于
      Most ColdFire support code has switched to using IO memory access
      methods (readb/writeb/etc) when reading and writing internal peripheral
      device registers. The WildFire board specific halt code was missed.
      
      As it is now the WildFire code is broken, since all register definitions
      were changed to be register addresses only some time ago.
      
      Fix the WildFire board code to use the appropriate IO access functions.
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      41b39ea1
    • G
      m68knommu: fix early setup to not access variables · bc065e47
      Greg Ungerer 提交于
      The early setup code for the ColdFire 53xx platform accesses variables
      before the RAM and other system initialization steps may have taken place.
      Currently it has 2 global variables that will end up in the bss section
      that are accessed during this early setup. There is a special static RAM
      stack setup at this time, but not necessarily the RAM where kernel data
      sections will end up.
      
      Even on system setups where RAM is setup by a boot loader the access
      to the early setup variables is before the BSS section has been initialized.
      This can potentially corrupt a ram loaded root filesystem that sits in that
      memory area before it has been moved.
      
      These 2 variables are not used at all after being set, and can just be
      removed.
      Reported-by: NChristian Gieseler <christiangieseler@yahoo.de>
      Signed-off-by: NGreg Ungerer <gerg@linux-m68k.org>
      bc065e47
    • L
      Linux 4.8-rc8 · 08895a8b
      Linus Torvalds 提交于
      08895a8b
    • L
      Merge tag 'trace-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace · 4c04b4b5
      Linus Torvalds 提交于
      Pull tracefs fixes from Steven Rostedt:
       "Al Viro has been looking at the tracefs code, and has pointed out some
        issues.  This contains one fix by me and one by Al.  I'm sure that
        he'll come up with more but for now I tested these patches and they
        don't appear to have any negative impact on tracing"
      
      * tag 'trace-v4.8-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
        fix memory leaks in tracing_buffers_splice_read()
        tracing: Move mutex to protect against resetting of seq data
      4c04b4b5
    • D
      fault_in_multipages_readable() throws set-but-unused error · 90b75db6
      Dave Chinner 提交于
      When building XFS with -Werror, it now fails with:
      
        include/linux/pagemap.h: In function 'fault_in_multipages_readable':
        include/linux/pagemap.h:602:16: error: variable 'c' set but not used [-Werror=unused-but-set-variable]
          volatile char c;
                        ^
      
      This is a regression caused by commit e23d4159 ("fix
      fault_in_multipages_...() on architectures with no-op access_ok()").
      Fix it by re-adding the "(void)c" trick taht was previously used to make
      the compiler think the variable is used.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      90b75db6
    • L
      mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing · 38e08854
      Lorenzo Stoakes 提交于
      The NUMA balancing logic uses an arch-specific PROT_NONE page table flag
      defined by pte_protnone() or pmd_protnone() to mark PTEs or huge page
      PMDs respectively as requiring balancing upon a subsequent page fault.
      User-defined PROT_NONE memory regions which also have this flag set will
      not normally invoke the NUMA balancing code as do_page_fault() will send
      a segfault to the process before handle_mm_fault() is even called.
      
      However if access_remote_vm() is invoked to access a PROT_NONE region of
      memory, handle_mm_fault() is called via faultin_page() and
      __get_user_pages() without any access checks being performed, meaning
      the NUMA balancing logic is incorrectly invoked on a non-NUMA memory
      region.
      
      A simple means of triggering this problem is to access PROT_NONE mmap'd
      memory using /proc/self/mem which reliably results in the NUMA handling
      functions being invoked when CONFIG_NUMA_BALANCING is set.
      
      This issue was reported in bugzilla (issue 99101) which includes some
      simple repro code.
      
      There are BUG_ON() checks in do_numa_page() and do_huge_pmd_numa_page()
      added at commit c0e7cad9 to avoid accidentally provoking strange
      behaviour by attempting to apply NUMA balancing to pages that are in
      fact PROT_NONE.  The BUG_ON()'s are consistently triggered by the repro.
      
      This patch moves the PROT_NONE check into mm/memory.c rather than
      invoking BUG_ON() as faulting in these pages via faultin_page() is a
      valid reason for reaching the NUMA check with the PROT_NONE page table
      flag set and is therefore not always a bug.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=99101Reported-by: NTrevor Saunders <tbsaunde@tbsaunde.org>
      Signed-off-by: NLorenzo Stoakes <lstoakes@gmail.com>
      Acked-by: NRik van Riel <riel@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      38e08854
    • L
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · 831e45d8
      Linus Torvalds 提交于
      Pull MIPS fixes from Ralf Baechle:
       "A round of 4.8 fixes:
      
        MIPS generic code:
         - Add a missing ".set pop" in an early commit
         - Fix memory regions reaching top of physical
         - MAAR: Fix address alignment
         - vDSO: Fix Malta EVA mapping to vDSO page structs
         - uprobes: fix incorrect uprobe brk handling
         - uprobes: select HAVE_REGS_AND_STACK_ACCESS_API
         - Avoid a BUG warning during PR_SET_FP_MODE prctl
         - SMP: Fix possibility of deadlock when bringing CPUs online
         - R6: Remove compact branch policy Kconfig entries
         - Fix size calc when avoiding IPIs for small icache flushes
         - Fix pre-r6 emulation FPU initialisation
         - Fix delay slot emulation count in debugfs
      
        ATH79:
         - Fix test for error return of clk_register_fixed_factor.
      
        Octeon:
         - Fix kernel header to work for VDSO build.
         - Fix initialization of platform device probing.
      
        paravirt:
         - Fix undefined reference to smp_bootstrap"
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
        MIPS: Fix delay slot emulation count in debugfs
        MIPS: SMP: Fix possibility of deadlock when bringing CPUs online
        MIPS: Fix pre-r6 emulation FPU initialisation
        MIPS: vDSO: Fix Malta EVA mapping to vDSO page structs
        MIPS: Select HAVE_REGS_AND_STACK_ACCESS_API
        MIPS: Octeon: Fix platform bus probing
        MIPS: Octeon: mangle-port: fix build failure with VDSO code
        MIPS: Avoid a BUG warning during prctl(PR_SET_FP_MODE, ...)
        MIPS: c-r4k: Fix size calc when avoiding IPIs for small icache flushes
        MIPS: Add a missing ".set pop" in an early commit
        MIPS: paravirt: Fix undefined reference to smp_bootstrap
        MIPS: Remove compact branch policy Kconfig entries
        MIPS: MAAR: Fix address alignment
        MIPS: Fix memory regions reaching top of physical
        MIPS: uprobes: fix incorrect uprobe brk handling
        MIPS: ath79: Fix test for error return of clk_register_fixed_factor().
      831e45d8
    • L
      Merge tag 'powerpc-4.8-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux · 751b9a5d
      Linus Torvalds 提交于
      Pull one more powerpc fix from Michael Ellerman:
       "powernv/pci: Fix m64 checks for SR-IOV and window alignment from
        Russell Currey"
      
      * tag 'powerpc-4.8-7' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
        powerpc/powernv/pci: Fix m64 checks for SR-IOV and window alignment
      751b9a5d
    • L
      radix tree: fix sibling entry handling in radix_tree_descend() · 8d2c0d36
      Linus Torvalds 提交于
      The fixes to the radix tree test suite show that the multi-order case is
      broken.  The basic reason is that the radix tree code uses tagged
      pointers with the "internal" bit in the low bits, and calculating the
      pointer indices was supposed to mask off those bits.  But gcc will
      notice that we then use the index to re-create the pointer, and will
      avoid doing the arithmetic and use the tagged pointer directly.
      
      This cleans the code up, using the existing is_sibling_entry() helper to
      validate the sibling pointer range (instead of open-coding it), and
      using entry_to_node() to mask off the low tag bit from the pointer.  And
      once you do that, you might as well just use the now cleaned-up pointer
      directly.
      
      [ Side note: the multi-order code isn't actually ever used in the kernel
        right now, and the only reason I didn't just delete all that code is
        that Kirill Shutemov piped up and said:
      
          "Well, my ext4-with-huge-pages patchset[1] uses multi-order entries.
           It also converts shmem-with-huge-pages and hugetlb to them.
      
           I'm okay with converting it to other mechanism, but I need
           something.  (I looked into Konstantin's RFC patchset[2].  It looks
           okay, but I don't feel myself qualified to review it as I don't
           know much about radix-tree internals.)"
      
        [1] http://lkml.kernel.org/r/20160915115523.29737-1-kirill.shutemov@linux.intel.com
        [2] http://lkml.kernel.org/r/147230727479.9957.1087787722571077339.stgit@zurg ]
      Reported-by: NMatthew Wilcox <mawilcox@microsoft.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Cc: Cedric Blancher <cedric.blancher@gmail.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8d2c0d36
    • M
      radix tree test suite: Test radix_tree_replace_slot() for multiorder entries · 62fd5258
      Matthew Wilcox 提交于
      When we replace a multiorder entry, check that all indices reflect the
      new value.
      
      Also, compile the test suite with -O2, which shows other problems with
      the code due to some dodgy pointer operations in the radix tree code.
      Signed-off-by: NMatthew Wilcox <mawilcox@microsoft.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      62fd5258
    • A
      fix memory leaks in tracing_buffers_splice_read() · 1ae2293d
      Al Viro 提交于
      Cc: stable@vger.kernel.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      1ae2293d
  2. 25 9月, 2016 11 次提交
  3. 24 9月, 2016 11 次提交