1. 01 6月, 2013 3 次提交
  2. 28 5月, 2013 2 次提交
  3. 27 5月, 2013 1 次提交
  4. 26 5月, 2013 1 次提交
  5. 25 5月, 2013 6 次提交
    • V
      ARC: lazy dcache flush broke gdb in non-aliasing configs · 7bb66f6e
      Vineet Gupta 提交于
      gdbserver inserting a breakpoint ends up calling copy_user_page() for a
      code page. The generic version of which (non-aliasing config) didn't set
      the PG_arch_1 bit hence update_mmu_cache() didn't sync dcache/icache for
      corresponding dynamic loader code page - causing garbade to be executed.
      
      So now aliasing versions of copy_user_highpage()/clear_page() are made
      default. There is no significant overhead since all of special alias
      handling code is compiled out for non-aliasing build
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      7bb66f6e
    • H
      parisc: fix irq stack on UP and SMP · d96b51ec
      Helge Deller 提交于
      The logic to detect if the irq stack was already in use with
      raw_spin_trylock() is wrong, because it will generate a "trylock failure
      on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y.
      
      arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case
      no atomic protection is given and we are reentrant here. A mutex didn't
      worked either and brings more overhead by turning off interrupts.
      
      So, let's use the fastest path for parisc which is the ldcw instruction.
      
      Counting how often the irq stack was used is pretty useless, so just
      drop this piece of code.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d96b51ec
    • J
      parisc: make interrupt and interruption stack allocation reentrant · b63a2bbc
      John David Anglin 提交于
      The get_stack_use_cr30 and get_stack_use_r30 macros allocate a stack
      frame for external interrupts and interruptions requiring a stack frame.
      They are currently not reentrant in that they save register context
      before the stack is set or adjusted.
      
      I have observed a number of system crashes where there was clear
      evidence of stack corruption during interrupt processing, and as a
      result register corruption. Some interruptions can still occur during
      interruption processing, however external interrupts are disabled and
      data TLB misses don't occur for absolute accesses. So, it's not entirely
      clear what triggers this issue. Also, if an interruption occurs when
      Q=0, it is generally not possible to recover as the shadowed registers
      are not copied.
      
      The attached patch reworks the get_stack_use_cr30 and get_stack_use_r30
      macros to allocate stack before doing register saves. The new code is a
      couple of instructions shorter than the old implementation. Thus, it's
      an improvement even if it doesn't fully resolve the stack corruption
      issue. Based on limited testing, it improves SMP system stability.
      Signed-off-by: NJohn David Anglin <dave.anglin@bell.net>
      Signed-off-by: NHelge Deller <deller@gmx.de>
      b63a2bbc
    • H
      parisc: show number of FPE and unaligned access handler calls in /proc/interrupts · d0c3be80
      Helge Deller 提交于
      Show number of floating point assistant and unaligned access fixup
      handler in /proc/interrupts file.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d0c3be80
    • H
      parisc: use PAGE_SHIFT instead of hardcoded value 12 in pacache.S · d845b5fb
      Helge Deller 提交于
      additionally clean up some whitespaces & tabs.
      Signed-off-by: NHelge Deller <deller@gmx.de>
      d845b5fb
    • H
      parisc: add rp5470 entry to machine database · 949451b9
      Helge Deller 提交于
      Signed-off-by: NHelge Deller <deller@gmx.de>
      949451b9
  6. 24 5月, 2013 10 次提交
  7. 23 5月, 2013 9 次提交
    • V
      ARC: Use enough bits for determining page's cache color · 006dfb3c
      Vineet Gupta 提交于
      The current code uses 2 bits for determining page's dcache color, thus
      sorting pages into 4 bins, whereas the aliasing dcache really has 2 bins
      (8k page, 64k dcache - 4 way-set-assoc).
      This can cause extraneous flushes - e.g. color 0 and 2.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      006dfb3c
    • V
      ARC: Brown paper bag bug in macro for checking cache color · 3e87974d
      Vineet Gupta 提交于
      The VM_EXEC check in update_mmu_cache() was getting optimized away
      because of a stupid error in definition of macro addr_not_cache_congruent()
      
      The intention was to have the equivalent of following:
      
      	if (a || (1 ? b : 0))
      
      but we ended up with following:
      
      	if (a || 1 ? b : 0)
      
      And because precedence of '||' is more that that of '?', gcc was optimizing
      away evaluation of <a>
      
      Nasty Repercussions:
      1. For non-aliasing configs it would mean some extraneous dcache flushes
         for non-code pages if U/K mappings were not congruent.
      2. For aliasing config, some needed dcache flush for code pages might
         be missed if U/K mappings were congruent.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      3e87974d
    • M
      microblaze: Use proper casting for inb/inw/inl in io.h · b5dd0bb4
      Michal Simek 提交于
      We are going to move to asm-generic/io.h but
      let's fix compilation warnings first for 3.10.
      
      Warning message:
      arch/microblaze/include/asm/io.h:126:26: warning: cast to
       pointer from integer of different size [-Wint-to-pointer-cast]
       #define inb(port)  readb((u8 *)((port)))
      ...
      Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
      b5dd0bb4
    • V
      ARC: copy_(to|from)_user() to honor usermode-access permissions · a950549c
      Vineet Gupta 提交于
      This manifested as grep failing psuedo-randomly:
      
      -------------->8---------------------
      [ARCLinux]$ ip address show lo | grep inet
      [ARCLinux]$ ip address show lo | grep inet
      [ARCLinux]$ ip address show lo | grep inet
      [ARCLinux]$
      [ARCLinux]$ ip address show lo | grep inet
          inet 127.0.0.1/8 scope host lo
      -------------->8---------------------
      
      ARC700 MMU provides fully orthogonal permission bits per page:
      Ur, Uw, Ux, Kr, Kw, Kx
      
      The user mode page permission templates used to have all Kernel mode
      access bits enabled.
      This caused a tricky race condition observed with uClibc buffered file
      read and UNIX pipes.
      
      1. Read access to an anon mapped page in libc .bss: write-protected
         zero_page mapped: TLB Entry installed with Ur + K[rwx]
      
      2. grep calls libc:getc() -> buffered read layer calls read(2) with the
         internal read buffer in same .bss page.
         The read() call is on STDIN which has been redirected to a pipe.
         read(2) => sys_read() => pipe_read() => copy_to_user()
      
      3. Since page has Kernel-write permission (despite being user-mode
         write-protected), copy_to_user() suceeds w/o taking a MMU TLB-Miss
         Exception (page-fault for ARC). core-MM is unaware that kernel
         erroneously wrote to the reserved read-only zero-page (BUG #1)
      
      4. Control returns to userspace which now does a write to same .bss page
         Since Linux MM is not aware that page has been modified by kernel, it
         simply reassigns a new writable zero-init page to mapping, loosing the
         prior write by kernel - effectively zero'ing out the libc read buffer
         under the hood - hence grep doesn't see right data (BUG #2)
      
      The fix is to make all kernel-mode access permissions mirror the
      user-mode ones. Note that the kernel still has full access to pages,
      when accessed directly (w/o MMU) - this fix ensures that kernel-mode
      access in copy_to_from() path uses the same faulting access model as for
      pure user accesses to keep MM fully aware of page state.
      
      The issue is peudo-random because it only shows up if the TLB entry
      installed in #1 is present at the time of #3. If it is evicted out, due
      to TLB pressure or some-such, then copy_to_user() does take a TLB Miss
      Exception, with a routine write-to-anon COW processing installing a
      fresh page for kernel writes and also usable as it is in userspace.
      
      Further the issue was dormant for so long as it depends on where the
      libc internal read buffer (in .bss) is mapped at runtime.
      If it happens to reside in file-backed data mapping of libc (in the
      page-aligned slack space trailing the file backed data), loader zero
      padding the slack space, does the early cow page replacement, setting
      things up at the very beginning itself.
      
      With gcc 4.8 based builds, the libc buffer got pushed out to a real
      anon mapping which triggers the issue.
      Reported-by: NAnton Kolesov <akolesov@synopsys.com>
      Cc: <stable@vger.kernel.org> # 3.9
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      a950549c
    • V
      ARC: [mm] Prevent stray dcache lines after__sync_icache_dcach() · f538881c
      Vineet Gupta 提交于
      Flush and INVALIDATE the dcache page.
      
      This helper is only used for writeback of CODE pages to memory. So
      there's no value in keeping the dcache lines around. Infact it is risky
      as a writeback on natural eviction under pressure can cause un-needed
      writeback with weird issues on aliasing dcache configurations.
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      f538881c
    • W
      ARM: 7729/1: vfp: ensure VFP_arch is non-zero when VFP is not supported · f27d6e17
      Will Deacon 提交于
      Commit d3f79584 ("ARM: cleanup undefined instruction entry code")
      improved the register scheduling when handling undefined instructions.
      A side effect of this is that r5 is now used as a temporary, whilst the
      VFP probing code relies on r5 containing a non-zero value when VFP is
      not supported.
      
      This patch fixes the VFP detection code so that we don't rely on the
      contents of r5. Without this patch, Linux dies loudly on CPUs without
      VFP support.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      f27d6e17
    • S
      ARM: 7727/1: remove the .vm_mm value from gate_vma · 4ca46c5e
      Steven Capper 提交于
      If one reads /proc/$PID/smaps, the mmap_sem belonging to the
      address space of the task being examined is locked for reading.
      All the pages of the vmas belonging to the task's address space
      are then walked with this lock held.
      
      If a gate_vma is present in the architecture, it too is examined
      by the fs/proc/task_mmu.c code. As gate_vma doesn't belong to the
      address space of the task though, its pages are not walked.
      
      A recent cleanup (commit f6604efe) of the gate_vma initialisation
      code set the vm_mm value to &init_mm. Unfortunately a non-NULL
      vm_mm value in the gate_vma will cause the task_mmu code to attempt
      to walk the pages of the gate_vma (with no mmap-sem lock held). If
      one enables Transparent Huge Page support and vm debugging, this
      will then cause OOPses as pmd_trans_huge_lock is called without
      mmap_sem being locked.
      
      This patch removes the .vm_mm value from gate_vma, restoring the
      original behaviour of the task_mmu code.
      Signed-off-by: NSteve Capper <steve.capper@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4ca46c5e
    • A
      ARM: 7723/1: crypto: sha1-armv4-large.S: fix SP handling · 934fc24d
      Ard Biesheuvel 提交于
      Make the SHA1 asm code ABI conformant by making sure all stack
      accesses occur above the stack pointer.
      
      Origin:
      http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1a9d60d2Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NNicolas Pitre <nico@linaro.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      934fc24d
    • J
      avr32: fix building warnings caused by redefinitions of HZ · 0c9b5a31
      Jiang Liu 提交于
      As suggested by David Howells <dhowells@redhat.com>, use
      asm-generic/param.h and uapi/asm-generic/param.h for AVR32.
      
      It also fixes building warnings caused by redefinitions of HZ:
      In file included from /ws/linux/kernel/linux.git/include/uapi/linux/param.h:4,
                       from include/linux/timex.h:63,
                       from include/linux/jiffies.h:8,
                       from include/linux/ktime.h:25,
                       from include/linux/timer.h:5,
                       from include/linux/workqueue.h:8,
                       from include/linux/srcu.h:34,
                       from include/linux/notifier.h:15,
                       from include/linux/memory_hotplug.h:6,
                       from include/linux/mmzone.h:777,
                       from include/linux/gfp.h:4,
                       from arch/avr32/mm/init.c:10:
      /ws/linux/kernel/linux.git/arch/avr32/include/asm/param.h:6:1: warning: "HZ" redefined
      In file included from /ws/linux/kernel/linux.git/arch/avr32/include/asm/param.h:4,
                       from /ws/linux/kernel/linux.git/include/uapi/linux/param.h:4,
                       from include/linux/timex.h:63,
                       from include/linux/jiffies.h:8,
                       from include/linux/ktime.h:25,
                       from include/linux/timer.h:5,
                       from include/linux/workqueue.h:8,
                       from include/linux/srcu.h:34,
                       from include/linux/notifier.h:15,
                       from include/linux/memory_hotplug.h:6,
                       from include/linux/mmzone.h:777,
                       from include/linux/gfp.h:4,
                       from arch/avr32/mm/init.c:10:
      /ws/linux/kernel/linux.git/arch/avr32/include/uapi/asm/param.h:6:1: warning: this is the location of the previous definition
      Signed-off-by: NJiang Liu <jiang.liu@huawei.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
      0c9b5a31
  8. 22 5月, 2013 8 次提交