1. 01 11月, 2011 3 次提交
  2. 28 10月, 2011 1 次提交
    • E
      compat: sync compat_stats with statfs. · 1448c721
      Eric W. Biederman 提交于
      This was found by inspection while tracking a similar
      bug in compat_statfs64, that has been fixed in mainline
      since decemeber.
      
      - This fixes a bug where not all of the f_spare fields
        were cleared on mips and s390.
      - Add the f_flags field to struct compat_statfs
      - Copy f_flags to userspace in case someone cares.
      - Use __clear_user to copy the f_spare field to userspace
        to ensure that all of the elements of f_spare are cleared.
        On some architectures f_spare is has 5 ints and on some
        architectures f_spare only has 4 ints.  Which makes
        the previous technique of clearing each int individually
        broken.
      
      I don't expect anyone actually uses the old statfs system
      call anymore but if they do let them benefit from having
      the compat and the native version working the same.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      1448c721
  3. 20 10月, 2011 1 次提交
  4. 13 10月, 2011 2 次提交
  5. 08 10月, 2011 1 次提交
  6. 30 9月, 2011 1 次提交
    • D
      sparc64: Force the execute bit in OpenFirmware's translation entries. · f4142cba
      David S. Miller 提交于
      In the OF 'translations' property, the template TTEs in the mappings
      never specify the executable bit.  This is the case even though some
      of these mappings are for OF's code segment.
      
      Therefore, we need to force the execute bit on in every mapping.
      
      This problem can only really trigger on Niagara/sun4v machines and the
      history behind this is a little complicated.
      
      Previous to sun4v, the sun4u TTE entries lacked a hardware execute
      permission bit.  So OF didn't have to ever worry about setting
      anything to handle executable pages.  Any valid TTE loaded into the
      I-TLB would be respected by the chip.
      
      But sun4v Niagara chips have a real hardware enforced executable bit
      in their TTEs.  So it has to be set or else the I-TLB throws an
      instruction access exception with type code 6 (protection violation).
      
      We've been extremely fortunate to not get bitten by this in the past.
      
      The best I can tell is that the OF's mappings for it's executable code
      were mapped using permanent locked mappings on sun4v in the past.
      Therefore, the fact that we didn't have the exec bit set in the OF
      translations we would use did not matter in practice.
      
      Thanks to Greg Onufer for helping me track this down.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f4142cba
  7. 22 9月, 2011 1 次提交
    • D
      sparc: Make '-p' boot option meaningful again. · 11032c17
      David S. Miller 提交于
      If "-p" is given on the command line, clear the CON_BOOT
      flag for the initial early boot PROM console.
      
      This is necessary to try and see crash messages that occur
      between the registry of the VT console and the probing of
      the first framebuffer or serial console.  During this time
      no console messages are emitted because the VT console
      registry (even if no backend is registered to it) removes
      the early console if CON_BOOT is set.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      11032c17
  8. 21 9月, 2011 1 次提交
  9. 17 9月, 2011 1 次提交
  10. 30 8月, 2011 3 次提交
  11. 27 8月, 2011 1 次提交
  12. 21 8月, 2011 1 次提交
    • D
      sparc: Allow handling signals when stack is corrupted. · 5598473a
      David S. Miller 提交于
      If we can't push the pending register windows onto the user's stack,
      we disallow signal delivery even if the signal would be delivered on a
      valid seperate signal stack.
      
      Add a register window save area in the signal frame, and store any
      unsavable windows there.
      
      On sigreturn, if any windows are still queued up in the signal frame,
      try to push them back onto the stack and if that fails we kill the
      process immediately.
      
      This allows the debug/tst-longjmp_chk2 glibc test case to pass.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5598473a
  13. 19 8月, 2011 1 次提交
    • I
      sparc: fix array bounds error setting up PCIC NMI trap · 4a0342ca
      Ian Campbell 提交于
        CC      arch/sparc/kernel/pcic.o
      arch/sparc/kernel/pcic.c: In function 'pcic_probe':
      arch/sparc/kernel/pcic.c:359:33: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:359:8: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:360:33: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:360:8: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:361:33: error: array subscript is above array bounds [-Werror=array-bounds]
      arch/sparc/kernel/pcic.c:361:8: error: array subscript is above array bounds [-Werror=array-bounds]
      cc1: all warnings being treated as errors
      
      I'm not particularly familiar with sparc but t_nmi (defined in head_32.S via
      the TRAP_ENTRY macro) and pcic_nmi_trap_patch (defined in entry.S) both appear
      to be 4 instructions long and I presume from the usage that instructions are
      int sized.
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: sparclinux@vger.kernel.org
      Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4a0342ca
  14. 16 8月, 2011 3 次提交
    • D
      sparc64: Set HAVE_C_RECORDMCOUNT · 178a2960
      David S. Miller 提交于
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      178a2960
    • M
      sparc32: unbreak arch_write_unlock() · 3f6aa0b1
      Mikael Pettersson 提交于
      The sparc32 version of arch_write_unlock() is just a plain assignment.
      Unfortunately this allows the compiler to schedule side-effects in a
      protected region to occur after the HW-level unlock, which is broken.
      E.g., the following trivial test case gets miscompiled:
      
      	#include <linux/spinlock.h>
      	rwlock_t lock;
      	int counter;
      	void foo(void) { write_lock(&lock); ++counter; write_unlock(&lock); }
      
      Fixed by adding a compiler memory barrier to arch_write_unlock().  The
      sparc64 version combines the barrier and assignment into a single asm(),
      and implements the operation as a static inline, so that's what I did too.
      
      Compile-tested with sparc32_defconfig + CONFIG_SMP=y.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3f6aa0b1
    • M
      sparc64: remove unnecessary macros from spinlock_64.h · a0fba3eb
      Mikael Pettersson 提交于
      The sparc64 spinlock_64.h contains a number of operations defined
      first as static inline functions, and then as macros with the same
      names and parameters as the functions.  Maybe this was needed at
      some point in the past, but now nothing seems to depend on these
      macros (checked with a recursive grep looking for ifdefs on these
      names).  Other archs don't define these identity-macros.
      
      So this patch deletes these unnecessary macros.
      
      Compile-tested with sparc64_defconfig.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a0fba3eb
  15. 12 8月, 2011 1 次提交
  16. 06 8月, 2011 1 次提交
  17. 05 8月, 2011 2 次提交
  18. 04 8月, 2011 2 次提交
  19. 03 8月, 2011 7 次提交
  20. 31 7月, 2011 2 次提交
  21. 29 7月, 2011 1 次提交
    • D
      sparc: Sanitize cpu feature detection and reporting. · ac85fe8b
      David S. Miller 提交于
      Instead of evaluating the cpu features for ELF_HWCAP every exec,
      calculate it once at boot time.
      
      Add AV_SPARC_* capability flag bits, compatible with what Solaris
      reports to applications.
      
      Report these capabilities once in the kernel log, and also via
      /proc/cpuinfo in a new "cpucaps" entry.
      
      If available, fetch the cpu features from the machine description
      'hwcap-list' property of the 'cpu' node.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ac85fe8b
  22. 28 7月, 2011 3 次提交
    • D
      sparc: Detect and handle UltraSPARC-T3 cpu types. · 4ba991d3
      David S. Miller 提交于
      The cpu compatible string we look for is "SPARC-T3".
      
      As far as memset/memcpy optimizations go, we treat this chip the same
      as Niagara-T2/T2+.  Use cache initializing stores for memset, and use
      perfetch, FPU block loads, cache initializing stores, and block stores
      for copies.
      
      We use the Niagara-T2 perf support, since T3 is a close relative in
      this regard.  Later we'll add support for the new events T3 can
      report, plus enable T3's new "sample" mode.
      
      For now I haven't added any new ELF hwcap flags.  We probably need
      to add a couple, for example:
      
      T2 and T3 both support the population count instruction in hardware.
      
      T3 supports VIS3 instructions, including support (finally) for
      partitioned shift.  One can also now move directly between float
      and integer registers.
      
      T3 supports instructions meant to help with Galois Field and other HPC
      calculations, such as XOR multiply.  Also there are "OP and negate"
      instructions, for example "fnmul" which is multiply-and-negate.
      
      T3 recognizes the transactional memory opcodes, however since
      transactional memory isn't supported: 1) 'commit' behaves as a NOP and
      2) 'chkpt' always branches 3) 'rdcps' returns all zeros and 4) 'wrcps'
      behaves as a NOP.
      
      So we'll need about 3 new elf capability flags in the end to represent
      all of these things.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4ba991d3
    • D
      sparc: Don't do expensive hypervisor PCR write unless necessary. · 314ff527
      David S. Miller 提交于
      The hypervisor call is only necessary if hypervisor events are
      being requested.
      
      So if we're not tracking hypervisor events, simply do a direct
      register write.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      314ff527
    • D