1. 14 9月, 2016 1 次提交
  2. 27 8月, 2016 1 次提交
  3. 04 8月, 2016 1 次提交
    • M
      tree-wide: replace config_enabled() with IS_ENABLED() · 97f2645f
      Masahiro Yamada 提交于
      The use of config_enabled() against config options is ambiguous.  In
      practical terms, config_enabled() is equivalent to IS_BUILTIN(), but the
      author might have used it for the meaning of IS_ENABLED().  Using
      IS_ENABLED(), IS_BUILTIN(), IS_MODULE() etc.  makes the intention
      clearer.
      
      This commit replaces config_enabled() with IS_ENABLED() where possible.
      This commit is only touching bool config options.
      
      I noticed two cases where config_enabled() is used against a tristate
      option:
      
       - config_enabled(CONFIG_HWMON)
        [ drivers/net/wireless/ath/ath10k/thermal.c ]
      
       - config_enabled(CONFIG_BACKLIGHT_CLASS_DEVICE)
        [ drivers/gpu/drm/gma500/opregion.c ]
      
      I did not touch them because they should be converted to IS_BUILTIN()
      in order to keep the logic, but I was not sure it was the authors'
      intention.
      
      Link: http://lkml.kernel.org/r/1465215656-20569-1-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Stas Sergeev <stsp@list.ru>
      Cc: Matt Redfearn <matt.redfearn@imgtec.com>
      Cc: Joshua Kinard <kumba@gentoo.org>
      Cc: Jiri Slaby <jslaby@suse.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: "Dmitry V. Levin" <ldv@altlinux.org>
      Cc: yu-cheng yu <yu-cheng.yu@intel.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Will Drewry <wad@chromium.org>
      Cc: Nikolay Martynov <mar.kolya@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Rafal Milecki <zajec5@gmail.com>
      Cc: James Cowgill <James.Cowgill@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Adam Buchbinder <adam.buchbinder@gmail.com>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Mikko Rapeli <mikko.rapeli@iki.fi>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
      Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Cc: Tony Wu <tung7970@gmail.com>
      Cc: Huaitong Han <huaitong.han@intel.com>
      Cc: Sumit Semwal <sumit.semwal@linaro.org>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andrea Gelmini <andrea.gelmini@gelma.net>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Rabin Vincent <rabin@rab.in>
      Cc: "Maciej W. Rozycki" <macro@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      97f2645f
  4. 02 8月, 2016 6 次提交
    • P
      MIPS: Use CPHYSADDR to implement mips32 __pa · 0d8d83d0
      Paul Burton 提交于
      Use CPHYSADDR to implement the __pa macro converting from a virtual to a
      physical address for MIPS32, much as is already done for MIPS64 (though
      without the complication of having both compatibility & XKPHYS
      segments).
      
      This allows for __pa to work regardless of whether the address being
      translated is in kseg0 or kseg1, unlike the previous subtraction based
      approach which only worked for addresses in kseg0. Working for kseg1
      addresses is important if __pa is used on addresses allocated by
      dma_alloc_coherent, where on systems with non-coherent I/O we provide
      addresses in kseg1. If this address is then used with
      dma_map_single_attrs then it is provided to virt_to_page, which in turn
      calls virt_to_phys which is a wrapper around __pa. The result is that we
      end up with a physical address 0x20000000 bytes (ie. the size of kseg0)
      too high.
      
      In addition to providing consistency with MIPS64 & fixing the kseg1 case
      above this has the added bonus of generating smaller code for systems
      implementing MIPS32r2 & beyond, where a single ext instruction can
      extract the physical address rather than needing to load an immediate
      into a temp register & subtract it. This results in ~1.3KB savings for a
      boston_defconfig kernel adjusted to set CONFIG_32BIT=y.
      
      This patch does not change the EVA case, which may or may not have
      similar issues around handling both cached & uncached addresses but is
      beyond the scope of this patch.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13836/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0d8d83d0
    • J
      MIPS: store the appended dtb address in a variable · 15f37e15
      Jonas Gorski 提交于
      Instead of rewriting the arguments to match the UHI spec, store the
      address of a appended or UHI supplied dtb in fw_supplied_dtb.
      
      That way the original bootloader arugments are kept intact while still
      making the use of an appended dtb invisible for mach code.
      
      Mach code can still find out if it is an appended dtb by comparing
      fw_arg1 with fw_supplied_dtb.
      Signed-off-by: NJonas Gorski <jogo@openwrt.org>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: John Crispin <john@phrozen.org>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Alban Bedel <albeu@free.fr>
      Cc: Daniel Gimpelevich <daniel@gimpelevich.san-francisco.ca.us>
      Cc: Antony Pavlov <antonynpavlov@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13699/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      15f37e15
    • H
      MIPS: Factor o32 specific code into signal_o32.c · d1e63c94
      Harvey Hunt 提交于
      The commit ebb5e78c ("MIPS: Initial implementation of a VDSO")
      caused building a 64 bit kernel with support for n32 and not o32
      to produce a build error:
      
      arch/mips/kernel/signal32.c:415:11: error: ‘vdso_image_o32’ undeclared here (not in a function)
        .vdso  = &vdso_image_o32,
      
      Fix this by moving the o32 specific code into signal_o32.c and
      updating the Makefile accordingly.
      Signed-off-by: NHarvey Hunt <harvey.hunt@imgtec.com>
      Cc: Leonid Yegoshin <Leonid.Yegoshin@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/13690/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      d1e63c94
    • P
      MIPS: non-exec stack & heap when non-exec PT_GNU_STACK is present · 1a770b85
      Paul Burton 提交于
      The stack and heap have both been executable by default on MIPS until
      now. This patch changes the default to be non-executable, but only for
      ELF binaries with a non-executable PT_GNU_STACK header present. This
      does apply to both the heap & the stack, despite the name PT_GNU_STACK,
      and this matches the behaviour of other architectures like ARM & x86.
      
      Current MIPS toolchains do not produce the PT_GNU_STACK header, which
      means that we can rely upon this patch not changing the behaviour of
      existing binaries. The new default will only take effect for newly
      compiled binaries once toolchains are updated to support PT_GNU_STACK,
      and since those binaries are newly compiled they can be compiled
      expecting the change in default behaviour. Again this matches the way in
      which the ARM & x86 architectures handled their implementations of
      non-executable memory.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13765/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      1a770b85
    • P
      MIPS: Use per-mm page to execute branch delay slot instructions · 432c6bac
      Paul Burton 提交于
      In some cases the kernel needs to execute an instruction from the delay
      slot of an emulated branch instruction. These cases include:
      
        - Emulated floating point branch instructions (bc1[ft]l?) for systems
          which don't include an FPU, or upon which the kernel is run with the
          "nofpu" parameter.
      
        - MIPSr6 systems running binaries targeting older revisions of the
          architecture, which may include branch instructions whose encodings
          are no longer valid in MIPSr6.
      
      Executing instructions from such delay slots is done by writing the
      instruction to memory followed by a trap, as part of an "emuframe", and
      executing it. This avoids the requirement of an emulator for the entire
      MIPS instruction set. Prior to this patch such emuframes are written to
      the user stack and executed from there.
      
      This patch moves FP branch delay emuframes off of the user stack and
      into a per-mm page. Allocating a page per-mm leaves userland with access
      to only what it had access to previously, and compared to other
      solutions is relatively simple.
      
      When a thread requires a delay slot emulation, it is allocated a frame.
      A thread may only have one frame allocated at any one time, since it may
      only ever be executing one instruction at any one time. In order to
      ensure that we can free up allocated frame later, its index is recorded
      in struct thread_struct. In the typical case, after executing the delay
      slot instruction we'll execute a break instruction with the BRK_MEMU
      code. This traps back to the kernel & leads to a call to do_dsemulret
      which frees the allocated frame & moves the user PC back to the
      instruction that would have executed following the emulated branch.
      In some cases the delay slot instruction may be invalid, such as a
      branch, or may trigger an exception. In these cases the BRK_MEMU break
      instruction will not be hit. In order to ensure that frames are freed
      this patch introduces dsemul_thread_cleanup() and calls it to free any
      allocated frame upon thread exit. If the instruction generated an
      exception & leads to a signal being delivered to the thread, or indeed
      if a signal simply happens to be delivered to the thread whilst it is
      executing from the struct emuframe, then we need to take care to exit
      the frame appropriately. This is done by either rolling back the user PC
      to the branch or advancing it to the continuation PC prior to signal
      delivery, using dsemul_thread_rollback(). If this were not done then a
      sigreturn would return to the struct emuframe, and if that frame had
      meanwhile been used in response to an emulated branch instruction within
      the signal handler then we would execute the wrong user code.
      
      Whilst a user could theoretically place something like a compact branch
      to self in a delay slot and cause their thread to become stuck in an
      infinite loop with the frame never being deallocated, this would:
      
        - Only affect the users single process.
      
        - Be architecturally invalid since there would be a branch in the
          delay slot, which is forbidden.
      
        - Be extremely unlikely to happen by mistake, and provide a program
          with no more ability to harm the system than a simple infinite loop
          would.
      
      If a thread requires a delay slot emulation & no frame is available to
      it (ie. the process has enough other threads that all frames are
      currently in use) then the thread joins a waitqueue. It will sleep until
      a frame is freed by another thread in the process.
      
      Since we now know whether a thread has an allocated frame due to our
      tracking of its index, the cookie field of struct emuframe is removed as
      we can be more certain whether we have a valid frame. Since a thread may
      only ever have a single frame at any given time, the epc field of struct
      emuframe is also removed & the PC to continue from is instead stored in
      struct thread_struct. Together these changes simplify & shrink struct
      emuframe somewhat, allowing twice as many frames to fit into the page
      allocated for them.
      
      The primary benefit of this patch is that we are now free to mark the
      user stack non-executable where that is possible.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Maciej Rozycki <maciej.rozycki@imgtec.com>
      Cc: Faraz Shahbazker <faraz.shahbazker@imgtec.com>
      Cc: Raghu Gandham <raghu.gandham@imgtec.com>
      Cc: Matthew Fortune <matthew.fortune@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13764/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      432c6bac
    • J
      MIPS: Fix definition of KSEGX() for 64-bit · 6002bdd3
      James Hogan 提交于
      The KSEGX() macro is defined to 32-bit sign extend the address argument
      and logically AND the result with 0xe0000000, with the final result
      usually compared against one of the CKSEG macros. However the literal
      0xe0000000 is unsigned as the high bit is set, and is therefore
      zero-extended on 64-bit kernels, resulting in the sign extension bits of
      the argument being masked to zero. This results in the odd situation
      where:
      
        KSEGX(CKSEG) != CKSEG
        (0xffffffff80000000 & 0x00000000e0000000) != 0xffffffff80000000)
      
      Fix this by 32-bit sign extending the 0xe0000000 literal using
      _ACAST32_.
      
      This will help some MIPS KVM code handling 32-bit guest addresses to
      work on 64-bit host kernels, but will also affect KSEGX in
      dec_kn01_be_backend() on a 64-bit DECstation kernel, and the SiByte DMA
      page ops KSEGX check in clear_page() and copy_page() on 64-bit SB1
      kernels, neither of which appear to be designed with 64-bit segments in
      mind anyway.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      6002bdd3
  5. 29 7月, 2016 3 次提交
    • J
      MIPS: c-r4k: Exclude sibling CPUs in SMP calls · 640511ae
      James Hogan 提交于
      When performing SMP calls to foreign cores, exclude sibling CPUs from
      the provided map, as we already handle the local core on the current
      CPU. This prevents an SMP call from for example core 0, VPE 1 to VPE 0
      on the same core.
      
      In the process the cpu_foreign_map cpumask is turned into an array of
      cpumasks, so that each CPU has its own version of it which excludes
      sibling CPUs. r4k_op_needs_ipi() is also updated to reflect that cache
      management SMP calls are not needed when all CPUs are siblings (i.e.
      there are no foreign CPUs according to the new cpu_foreign_map[]
      semantics which exclude siblings).
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: Felix Fietkau <nbd@nbd.name>
      Cc: Jayachandran C. <jchandra@broadcom.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13801/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      640511ae
    • J
      MIPS: c-r4k: Fix protected_writeback_scache_line for EVA · 0758b116
      James Hogan 提交于
      The protected_writeback_scache_line() function is used by
      local_r4k_flush_cache_sigtramp() to flush an FPU delay slot emulation
      trampoline on the userland stack from the caches so it is visible to
      subsequent instruction fetches.
      
      Commit de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing
      functions") updated some protected_ cache flush functions to use EVA
      CACHEE instructions via protected_cachee_op(), and commit 83fd4344
      ("MIPS: r4kcache: Add EVA case for protected_writeback_dcache_line") did
      the same thing for protected_writeback_dcache_line(), but
      protected_writeback_scache_line() never got updated. Lets fix that now
      to flush the right user address from the secondary cache rather than
      some arbitrary kernel unmapped address.
      
      This issue was spotted through code inspection, and it seems unlikely to
      be possible to hit this in practice. It theoretically affect EVA kernels
      on EVA capable cores with an L2 cache, where the icache fetches straight
      from RAM (cpu_icache_snoops_remote_store == 0), running a hard float
      userland with FPU disabled (nofpu). That both Malta and Boston platforms
      override cpu_icache_snoops_remote_store to 1 suggests that all MIPS
      cores fetch instructions into icache straight from L2 rather than RAM.
      
      Fixes: de8974e3 ("MIPS: asm: r4kcache: Add EVA cache flushing functions")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Leonid Yegoshin <leonid.yegoshin@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13800/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      0758b116
    • J
      MIPS: SMP: Update cpu_foreign_map on CPU disable · 826e99be
      James Hogan 提交于
      When a CPU is disabled via CPU hotplug, cpu_foreign_map is not updated.
      This could result in cache management SMP calls being sent to offline
      CPUs instead of online siblings in the same core.
      
      Add a call to calculate_cpu_foreign_map() in the various MIPS cpu
      disable callbacks after set_cpu_online(). All cases are updated for
      consistency and to keep cpu_foreign_map strictly up to date, not just
      those which may support hardware multithreading.
      
      Fixes: cccf34e9 ("MIPS: c-r4k: Fix cache flushing for MT cores")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Kevin Cernekee <cernekee@gmail.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: Hongliang Tao <taohl@lemote.com>
      Cc: Hua Yan <yanh@lemote.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13799/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      826e99be
  6. 28 7月, 2016 2 次提交
  7. 25 7月, 2016 1 次提交
  8. 24 7月, 2016 1 次提交
  9. 12 7月, 2016 1 次提交
  10. 06 7月, 2016 2 次提交
    • D
      MIPS: Fix page table corruption on THP permission changes. · acd168c0
      David Daney 提交于
      When the core THP code is modifying the permissions of a huge page it
      calls pmd_modify(), which unfortunately was clearing the _PAGE_HUGE bit
      of the page table entry.  The result can be kernel messages like:
      
      mm/memory.c:397: bad pmd 000000040080004d.
      mm/memory.c:397: bad pmd 00000003ff00004d.
      mm/memory.c:397: bad pmd 000000040100004d.
      
      or:
      
      ------------[ cut here ]------------
      WARNING: at mm/mmap.c:3200 exit_mmap+0x150/0x158()
      Modules linked in: ipv6 at24 octeon3_ethernet octeon_srio_nexus m25p80
      CPU: 12 PID: 1295 Comm: pmderr Not tainted 3.10.87-rt80-Cavium-Octeon #4
      Stack : 0000000040808000 0000000014009ce1 0000000000400004 ffffffff81076ba0
                0000000000000000 0000000000000000 ffffffff85110000 0000000000000119
                0000000000000004 0000000000000000 0000000000000119 43617669756d2d4f
                0000000000000000 ffffffff850fda40 ffffffff85110000 0000000000000000
                0000000000000000 0000000000000009 ffffffff809207a0 0000000000000c80
                ffffffff80f1bf20 0000000000000001 000000ffeca36828 0000000000000001
                0000000000000000 0000000000000001 000000ffeca7e700 ffffffff80886924
                80000003fd7a0000 80000003fd7a39b0 80000003fdea8000 ffffffff80885780
                80000003fdea8000 ffffffff80f12218 000000000000000c 000000000000050f
                0000000000000000 ffffffff80865c4c 0000000000000000 0000000000000000
                ...
      Call Trace:
      [<ffffffff80865c4c>] show_stack+0x6c/0xf8
      [<ffffffff80885780>] warn_slowpath_common+0x78/0xa8
      [<ffffffff809207a0>] exit_mmap+0x150/0x158
      [<ffffffff80882d44>] mmput+0x5c/0x110
      [<ffffffff8088b450>] do_exit+0x230/0xa68
      [<ffffffff8088be34>] do_group_exit+0x54/0x1d0
      [<ffffffff8088bfc0>] __wake_up_parent+0x0/0x18
      
      ---[ end trace c7b38293191c57dc ]---
      BUG: Bad rss-counter state mm:80000003fa168000 idx:1 val:1536
      
      Fix by not clearing _PAGE_HUGE bit.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Tested-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Cc: stable@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13687/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      acd168c0
    • D
      MIPS: Fix page table corruption on THP permission changes. · 88d02a2b
      David Daney 提交于
      When the core THP code is modifying the permissions of a huge page it
      calls pmd_modify(), which unfortunately was clearing the _PAGE_HUGE bit
      of the page table entry.  The result can be kernel messages like:
      
      mm/memory.c:397: bad pmd 000000040080004d.
      mm/memory.c:397: bad pmd 00000003ff00004d.
      mm/memory.c:397: bad pmd 000000040100004d.
      
      or:
      
      ------------[ cut here ]------------
      WARNING: at mm/mmap.c:3200 exit_mmap+0x150/0x158()
      Modules linked in: ipv6 at24 octeon3_ethernet octeon_srio_nexus m25p80
      CPU: 12 PID: 1295 Comm: pmderr Not tainted 3.10.87-rt80-Cavium-Octeon #4
      Stack : 0000000040808000 0000000014009ce1 0000000000400004 ffffffff81076ba0
                0000000000000000 0000000000000000 ffffffff85110000 0000000000000119
                0000000000000004 0000000000000000 0000000000000119 43617669756d2d4f
                0000000000000000 ffffffff850fda40 ffffffff85110000 0000000000000000
                0000000000000000 0000000000000009 ffffffff809207a0 0000000000000c80
                ffffffff80f1bf20 0000000000000001 000000ffeca36828 0000000000000001
                0000000000000000 0000000000000001 000000ffeca7e700 ffffffff80886924
                80000003fd7a0000 80000003fd7a39b0 80000003fdea8000 ffffffff80885780
                80000003fdea8000 ffffffff80f12218 000000000000000c 000000000000050f
                0000000000000000 ffffffff80865c4c 0000000000000000 0000000000000000
                ...
      Call Trace:
      [<ffffffff80865c4c>] show_stack+0x6c/0xf8
      [<ffffffff80885780>] warn_slowpath_common+0x78/0xa8
      [<ffffffff809207a0>] exit_mmap+0x150/0x158
      [<ffffffff80882d44>] mmput+0x5c/0x110
      [<ffffffff8088b450>] do_exit+0x230/0xa68
      [<ffffffff8088be34>] do_group_exit+0x54/0x1d0
      [<ffffffff8088bfc0>] __wake_up_parent+0x0/0x18
      
      ---[ end trace c7b38293191c57dc ]---
      BUG: Bad rss-counter state mm:80000003fa168000 idx:1 val:1536
      
      Fix by not clearing _PAGE_HUGE bit.
      Signed-off-by: NDavid Daney <david.daney@cavium.com>
      Tested-by: NAaro Koskinen <aaro.koskinen@nokia.com>
      Cc: stable@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/13687/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      88d02a2b
  11. 05 7月, 2016 8 次提交
  12. 02 7月, 2016 1 次提交
    • R
      MIPS: Fix possible corruption of cache mode by mprotect. · 6d037de9
      Ralf Baechle 提交于
      The following testcase may result in a page table entries with a invalid
      CCA field being generated:
      
      static void *bindstack;
      
      static int sysrqfd;
      
      static void protect_low(int protect)
      {
      	mprotect(bindstack, BINDSTACK_SIZE, protect);
      }
      
      static void sigbus_handler(int signal, siginfo_t * info, void *context)
      {
      	void *addr = info->si_addr;
      
      	write(sysrqfd, "x", 1);
      
      	printf("sigbus, fault address %p (should not happen, but might)\n",
      	       addr);
      	abort();
      }
      
      static void run_bind_test(void)
      {
      	unsigned int *p = bindstack;
      
      	p[0] = 0xf001f001;
      
      	write(sysrqfd, "x", 1);
      
      	/* Set trap on access to p[0] */
      	protect_low(PROT_NONE);
      
      	write(sysrqfd, "x", 1);
      
      	/* Clear trap on access to p[0] */
      	protect_low(PROT_READ | PROT_WRITE | PROT_EXEC);
      
      	write(sysrqfd, "x", 1);
      
      	/* Check the contents of p[0] */
      	if (p[0] != 0xf001f001) {
      		write(sysrqfd, "x", 1);
      
      		/* Reached, but shouldn't be */
      		printf("badness, shouldn't happen but does\n");
      		abort();
      	}
      }
      
      int main(void)
      {
      	struct sigaction sa;
      
      	sysrqfd = open("/proc/sysrq-trigger", O_WRONLY);
      
      	if (sigprocmask(SIG_BLOCK, NULL, &sa.sa_mask)) {
      		perror("sigprocmask");
      		return 0;
      	}
      
      	sa.sa_sigaction = sigbus_handler;
      	sa.sa_flags = SA_SIGINFO | SA_NODEFER | SA_RESTART;
      	if (sigaction(SIGBUS, &sa, NULL)) {
      		perror("sigaction");
      		return 0;
      	}
      
      	bindstack = mmap(NULL,
      			 BINDSTACK_SIZE,
      			 PROT_READ | PROT_WRITE | PROT_EXEC,
      			 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
      	if (bindstack == MAP_FAILED) {
      		perror("mmap bindstack");
      		return 0;
      	}
      
      	printf("bindstack: %p\n", bindstack);
      
      	run_bind_test();
      
      	printf("done\n");
      
      	return 0;
      }
      
      There are multiple ingredients for this:
      
       1) PAGE_NONE is defined to _CACHE_CACHABLE_NONCOHERENT, which is CCA 3
          on all platforms except SB1 where it's CCA 5.
       2) _page_cachable_default must have bits set which are not set
          _CACHE_CACHABLE_NONCOHERENT.
       3) Either the defective version of pte_modify for XPA or the standard
          version must be in used.  However pte_modify for the 36 bit address
          space support is no affected.
      
      In that case additional bits in the final CCA mode may generate an invalid
      value for the CCA field.  On the R10000 system where this was tracked
      down for example a CCA 7 has been observed, which is Uncached Accelerated.
      
      Fixed by:
      
       1) Using the proper CCA mode for PAGE_NONE just like for all the other
          PAGE_* pte/pmd bits.
       2) Fix the two affected variants of pte_modify.
      
      Further code inspection also shows the same issue to exist in pmd_modify
      which would affect huge page systems.
      
      Issue in pte_modify tracked down by Alastair Bridgewater, PAGE_NONE
      and pmd_modify issue found by me.
      
      The history of this goes back beyond Linus' git history.  Chris Dearman's
      commit 35133692 ("[MIPS] Allow setting of
      the cache attribute at run time.") missed the opportunity to fix this
      but it was originally introduced in lmo commit
      d523832cf12007b3242e50bb77d0c9e63e0b6518 ("Missing from last commit.")
      and 32cc38229ac7538f2346918a09e75413e8861f87 ("New configuration option
      CONFIG_MIPS_UNCACHED.")
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Reported-by: NAlastair Bridgewater <alastair.bridgewater@gmail.com>
      6d037de9
  13. 25 6月, 2016 1 次提交
  14. 18 6月, 2016 1 次提交
    • B
      PCI: Unify pci_resource_to_user() declarations · 8221a013
      Bjorn Helgaas 提交于
      Replace the pci_resource_to_user() declarations in each arch that defines
      HAVE_ARCH_PCI_RESOURCE_TO_USER with a single one in linux/pci.h.
      
      Change the MIPS static inline implementation to a non-inline version so the
      static inline doesn't conflict with the new non-static linux/pci.h
      declaration.
      
      No functional change intended.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      8221a013
  15. 16 6月, 2016 10 次提交
    • P
      locking/atomic, arch/mips: Convert to _relaxed atomics · 4ec45856
      Peter Zijlstra 提交于
      Generic code will construct {,_acquire,_release} versions by adding the
      required smp_mb__{before,after}_atomic() calls.
      
      XXX if/when MIPS will start using their new SYNCxx instructions they
      can provide custom __atomic_op_{acquire,release}() macros as per the
      powerpc example.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4ec45856
    • P
      locking/atomic: Remove linux/atomic.h:atomic_fetch_or() · b53d6bed
      Peter Zijlstra 提交于
      Since all architectures have this implemented now natively, remove this
      dead code.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      b53d6bed
    • P
      locking/atomic, arch/mips: Implement atomic{,64}_fetch_{add,sub,and,or,xor}() · 4edac529
      Peter Zijlstra 提交于
      Implement FETCH-OP atomic primitives, these are very similar to the
      existing OP-RETURN primitives we already have, except they return the
      value of the atomic variable _before_ modification.
      
      This is especially useful for irreversible operations -- such as
      bitops (because it becomes impossible to reconstruct the state prior
      to modification).
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arch@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4edac529
    • J
      MIPS: KVM: Use mipsregs.h defs for config registers · 4e10b764
      James Hogan 提交于
      Convert MIPS KVM guest register state initialisation to use the standard
      <asm/mipsregs.h> register field definitions for Config registers, and
      drop the custom definitions in kvm_host.h which it was using before.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4e10b764
    • J
      MIPS: Add define for Config.VI (virtual icache) bit · 4b34bca0
      James Hogan 提交于
      The Config.VI bit specifies that the instruction cache is virtually
      tagged, which is checked in c-r4k.c's probe_pcache(). Add a proper
      definition for it in mipsregs.h and make use of it.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4b34bca0
    • J
      MIPS: KVM: Move commpage so 0x0 is unmapped · 42aa12e7
      James Hogan 提交于
      The comm page which is mapped into the guest kernel address space at
      0x0 has the unfortunate side effect of allowing guest kernel NULL
      pointer dereferences to succeed. The only constraint on this address is
      that it must be within 32KiB of 0x0, so that single lw/sw instructions
      (which have 16-bit signed offset fields) can be used to access it, using
      the zero register as a base.
      
      So lets move the comm page as high as possible within that constraint so
      that 0x0 can be left unmapped, at least for page sizes < 32KiB.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      42aa12e7
    • J
      MIPS: KVM: Add KScratch registers · 05108709
      James Hogan 提交于
      Allow up to 6 KVM guest KScratch registers to be enabled and accessed
      via the KVM guest register API and from the guest itself (the fallback
      reading and writing of commpage registers is sufficient for KScratch
      registers to work as expected).
      
      User mode can expose the registers by setting the appropriate bits of
      the guest Config4.KScrExist field. KScratch registers that aren't usable
      won't be writeable via the KVM Ioctl API.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      05108709
    • J
      MIPS: KVM: Don't hardcode restored HWREna · b937ff62
      James Hogan 提交于
      KVM modifies CP0_HWREna during guest execution so it can trap and
      emulate RDHWR instructions, however it always restores the hardcoded
      value 0x2000000F. This assumes the presence of the UserLocal register,
      and the absence of any implementation dependent or future HW registers.
      
      Fix by exporting the value that traps.c write into CP0_HWREna, and
      loading from there instead of hard coding.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      b937ff62
    • J
      MIPS: Clean up RDHWR handling · aff565aa
      James Hogan 提交于
      No preprocessor definitions are used in the handling of the registers
      accessible with the RDHWR instruction, nor the corresponding bits in the
      CP0 HWREna register.
      
      Add definitions for both the register numbers (MIPS_HWR_*) and HWREna
      bits (MIPS_HWRENA_*) in asm/mipsregs.h and make use of them in the
      initialisation of HWREna and emulation of the RDHWR instruction.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      aff565aa
    • J
      MIPS: KVM: Use raw_cpu_has_fpu in kvm_mips_guest_can_have_fpu() · 19451e51
      James Hogan 提交于
      We need to use kvm_mips_guest_can_have_fpu() when deciding which
      registers to list with KVM_GET_REG_LIST, however it causes warnings with
      preemption since it uses cpu_has_fpu. KVM is only really supported on
      CPUs which have symmetric FPUs, so switch to raw_cpu_has_fpu to avoid
      the warning.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      19451e51