1. 13 Mar, 2017 1 commit
    • James Cowgill's avatar
      MIPS: OCTEON: Fix copy_from_user fault handling for large buffers · 6f25f217
      James Cowgill authored
      commit 884b4269 upstream.
      
      If copy_from_user is called with a large buffer (>= 128 bytes) and the
      userspace buffer refers partially to unreadable memory, then it is
      possible for Octeon's copy_from_user to report the wrong number of bytes
      have been copied. In the case where the buffer size is an exact multiple
      of 128 and the fault occurs in the last 64 bytes, copy_from_user will
      report that all the bytes were copied successfully but leave some
      garbage in the destination buffer.
      
      The bug is in the main __copy_user_common loop in octeon-memcpy.S where
      in the middle of the loop, src and dst are incremented by 128 bytes. The
      l_exc_copy fault handler is used after this but that assumes that
      "src < THREAD_BUADDR($28)". This is not the case if src has already been
      incremented.
      
      Fix by adding an extra fault handler which rewinds the src and dst
      pointers 128 bytes before falling though to l_exc_copy.
      
      Thanks to the pwritev test from the strace test suite for originally
      highlighting this bug!
      
      Fixes: 5b3b1688
      
       ("MIPS: Add Cavium OCTEON processor support ...")
      Signed-off-by: default avatarJames Cowgill <James.Cowgill@imgtec.com>
      Acked-by: default avatarDavid Daney <david.daney@cavium.com>
      Reviewed-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/14978/
      
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      6f25f217
  2. 01 Feb, 2013 1 commit
  3. 12 Dec, 2012 1 commit
  4. 23 Jul, 2012 1 commit
  5. 11 Jan, 2009 1 commit
    • David Daney's avatar
      MIPS: Add Cavium OCTEON processor support files to arch/mips/cavium-octeon. · 5b3b1688
      David Daney authored
      
      These are the rest of the new files needed to add OCTEON processor
      support to the Linux kernel.  Other than Makefile and Kconfig which
      should be obvious, we have:
      
      csrc-octeon.c   -- Clock source driver for OCTEON.
      dma-octeon.c    -- Helper functions for mapping DMA memory.
      flash_setup.c   -- Register on-board flash with the MTD subsystem.
      octeon-irq.c    -- OCTEON interrupt controller managment.
      octeon-memcpy.S -- Optimized memcpy() implementation.
      serial.c        -- Register 8250 platform driver and early console.
      setup.c         -- Early architecture initialization.
      smp.c           -- OCTEON SMP support.
      octeon_switch.S -- Scheduler context switch for OCTEON.
      c-octeon.c      -- OCTEON cache controller support.
      cex-oct.S       -- OCTEON cache exception handler.
      
      asm/mach-cavium-octeon/*.h -- Architecture include files.
      Signed-off-by: default avatarTomaso Paoletti <tpaoletti@caviumnetworks.com>
      Signed-off-by: David Daney <ddaney@caviumnetwork...
      5b3b1688
  6. 29 Jan, 2008 3 commits
    • Ralf Baechle's avatar
      [MIPS] Eleminate local symbols from the symbol table. · c5ec1983
      Ralf Baechle authored
      
      These symbols appear in oprofile output, stacktraces and similar but only
      make the output harder to read.  Many identical symbol names such as
      "both_aligned" were also being used in multiple source files making it
      impossible to see which file actually was meant.  So let's get rid of them.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      c5ec1983
    • Thomas Bogendoerfer's avatar
      [MIPS] IP28: added cache barrier to assembly routines · 930bff88
      Thomas Bogendoerfer authored
      
      IP28 needs special treatment to avoid speculative accesses. gcc
      takes care for .c code, but for assembly code we need to do it
      manually.
      
      This is taken from Peter Fuersts IP28 patches.
      Signed-off-by: default avatarThomas Bogendoerfer <tsbogend@alpha.franken.de>
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      930bff88
    • Maciej W. Rozycki's avatar
      [MIPS] R4000/R4400 daddiu erratum workaround · 619b6e18
      Maciej W. Rozycki authored
       This complements the generic R4000/R4400 errata workaround code and adds 
      bits for the daddiu problem.  In most places it just modifies handwritten 
      assembly code so that the assembler is allowed to use a temporary register 
      as daddiu may now be treated as a macro that expands to a sequence of li 
      and daddu.  It is the AT register or, where AT is unavailable or used 
      explicitly for another purpose, an explicitly-named register is selected, 
      using the .set at=<reg> feature added recently to gas.  This feature is 
      only used if CONFIG_CPU_DADDI_WORKAROUNDS has been set, so if the 
      workaround remains disabled, the required version of binutils stays 
      unchanged.
      
       Similarly, daddiu instructions put in branch delay slots in noreorder 
      fragments are now taken out of them and the assembler is allowed to 
      reorder them itself as possible (which it does making the whole idea of 
      scheduling them into delay slots manually questionable).
      
       Also in the very few places where s...
      619b6e18
  7. 30 Jun, 2006 1 commit
  8. 29 Oct, 2005 1 commit
  9. 09 Sep, 2005 1 commit
  10. 05 Sep, 2005 2 commits
  11. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4