1. 17 10月, 2008 2 次提交
    • C
      compat: generic compat get/settimeofday · b418da16
      Christoph Hellwig 提交于
      Nothing arch specific in get/settimeofday.  The details of the timeval
      conversion varied a little from arch to arch, but all with the same
      results.
      
      Also add an extern declaration for sys_tz to linux/time.h because externs
      in .c files are fowned upon.  I'll kill the externs in various other files
      in a sparate patch.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: David S. Miller <davem@davemloft.net> [ sparc bits ]
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Cc: Matthew Wilcox <matthew@wil.cx>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b418da16
    • C
      compat: move cp_compat_stat to common code · f7a5000f
      Christoph Hellwig 提交于
      struct stat / compat_stat is the same on all architectures, so
      cp_compat_stat should be, too.
      
      Turns out it is, except that various architectures have slightly and some
      high2lowuid/high2lowgid or the direct assignment instead of the
      SET_UID/SET_GID that expands to the correct one anyway.
      
      This patch replaces the arch-specific cp_compat_stat implementations with
      a common one based on the x86-64 one.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: David S. Miller <davem@davemloft.net> [ sparc bits ]
      Acked-by: Kyle McMartin <kyle@mcmartin.ca> [ parisc bits ]
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f7a5000f
  2. 11 10月, 2008 1 次提交
  3. 19 4月, 2008 1 次提交
  4. 17 10月, 2007 1 次提交
  5. 27 4月, 2007 1 次提交
  6. 12 2月, 2007 1 次提交
    • K
      [PATCH] Common compat_sys_sysinfo · d4d23add
      Kyle McMartin 提交于
      I noticed that almost all architectures implemented exactly the same
      sys32_sysinfo...  except parisc, where a bug was to be found in handling of
      the uptime.  So let's remove a whole whack of code for fun and profit.
      Cribbed compat_sys_sysinfo from x86_64's implementation, since I figured it
      would be the best tested.
      
      This patch incorporates Arnd's suggestion of not using set_fs/get_fs, but
      instead extracting out the common code from sys_sysinfo.
      
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d4d23add
  7. 06 2月, 2007 2 次提交
    • G
      [S390] noexec protection · c1821c2e
      Gerald Schaefer 提交于
      This provides a noexec protection on s390 hardware. Our hardware does
      not have any bits left in the pte for a hw noexec bit, so this is a
      different approach using shadow page tables and a special addressing
      mode that allows separate address spaces for code and data.
      
      As a special feature of our "secondary-space" addressing mode, separate
      page tables can be specified for the translation of data addresses
      (storage operands) and instruction addresses. The shadow page table is
      used for the instruction addresses and the standard page table for the
      data addresses.
      The shadow page table is linked to the standard page table by a pointer
      in page->lru.next of the struct page corresponding to the page that
      contains the standard page table (since page->private is not really
      private with the pte_lock and the page table pages are not in the LRU
      list).
      Depending on the software bits of a pte, it is either inserted into
      both page tables or just into the standard (data) page table. Pages of
      a vma that does not have the VM_EXEC bit set get mapped only in the
      data address space. Any try to execute code on such a page will cause a
      page translation exception. The standard reaction to this is a SIGSEGV
      with two exceptions: the two system call opcodes 0x0a77 (sys_sigreturn)
      and 0x0aad (sys_rt_sigreturn) are allowed. They are stored by the
      kernel to the signal stack frame. Unfortunately, the signal return
      mechanism cannot be modified to use an SA_RESTORER because the
      exception unwinding code depends on the system call opcode stored
      behind the signal stack frame.
      
      This feature requires that user space is executed in secondary-space
      mode and the kernel in home-space mode, which means that the addressing
      modes need to be switched and that the noexec protection only works
      for user space.
      After switching the addressing modes, we cannot use the mvcp/mvcs
      instructions anymore to copy between kernel and user space. A new
      mvcos instruction has been added to the z9 EC/BC hardware which allows
      to copy between arbitrary address spaces, but on older hardware the
      page tables need to be walked manually.
      Signed-off-by: NGerald Schaefer <geraldsc@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c1821c2e
    • H
  8. 27 10月, 2006 1 次提交
  9. 19 10月, 2006 1 次提交
    • C
      [S390] fix vmlinux link when CONFIG_SYSIPC=n · 1df23957
      Cedric Le Goater 提交于
      Fix the following compile error:
      
        CC      init/version.o
        LD      init/built-in.o
        LD      .tmp_vmlinux1
      arch/s390/kernel/built-in.o(.text+0xdba4): In function `sys32_ipc':
      : undefined reference to `compat_sys_semtimedop'
      arch/s390/kernel/built-in.o(.text+0xdbee): In function `sys32_ipc':
      : undefined reference to `compat_sys_semctl'
      arch/s390/kernel/built-in.o(.text+0xdc08): In function `sys32_ipc':
      : undefined reference to `compat_sys_msgsnd'
      arch/s390/kernel/built-in.o(.text+0xdc30): In function `sys32_ipc':
      : undefined reference to `compat_sys_msgrcv'
      arch/s390/kernel/built-in.o(.text+0xdc58): In function `sys32_ipc':
      : undefined reference to `compat_sys_msgctl'
      arch/s390/kernel/built-in.o(.text+0xdc76): In function `sys32_ipc':
      : undefined reference to `compat_sys_shmat'
      arch/s390/kernel/built-in.o(.text+0xdcb0): In function `sys32_ipc':
      : undefined reference to `compat_sys_shmctl'
      make: *** [.tmp_vmlinux1] Error 1
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      1df23957
  10. 03 10月, 2006 1 次提交
    • D
      [PATCH] VFS: Make filldir_t and struct kstat deal in 64-bit inode numbers · afefdbb2
      David Howells 提交于
      These patches make the kernel pass 64-bit inode numbers internally when
      communicating to userspace, even on a 32-bit system.  They are required
      because some filesystems have intrinsic 64-bit inode numbers: NFS3+ and XFS
      for example.  The 64-bit inode numbers are then propagated to userspace
      automatically where the arch supports it.
      
      Problems have been seen with userspace (eg: ld.so) using the 64-bit inode
      number returned by stat64() or getdents64() to differentiate files, and
      failing because the 64-bit inode number space was compressed to 32-bits, and
      so overlaps occur.
      
      This patch:
      
      Make filldir_t take a 64-bit inode number and struct kstat carry a 64-bit
      inode number so that 64-bit inode numbers can be passed back to userspace.
      
      The stat functions then returns the full 64-bit inode number where
      available and where possible.  If it is not possible to represent the inode
      number supplied by the filesystem in the field provided by userspace, then
      error EOVERFLOW will be issued.
      
      Similarly, the getdents/readdir functions now pass the full 64-bit inode
      number to userspace where possible, returning EOVERFLOW instead when a
      directory entry is encountered that can't be properly represented.
      
      Note that this means that some inodes will not be stat'able on a 32-bit
      system with old libraries where they were before - but it does mean that
      there will be no ambiguity over what a 32-bit inode number refers to.
      
      Note similarly that directory scans may be cut short with an error on a
      32-bit system with old libraries where the scan would work before for the
      same reasons.
      
      It is judged unlikely that this situation will occur because modern glibc
      uses 64-bit capable versions of stat and getdents class functions
      exclusively, and that older systems are unlikely to encounter
      unrepresentable inode numbers anyway.
      
      [akpm: alpha build fix]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      afefdbb2
  11. 28 9月, 2006 1 次提交
    • M
      [S390] Inline assembly cleanup. · 94c12cc7
      Martin Schwidefsky 提交于
      Major cleanup of all s390 inline assemblies. They now have a common
      coding style. Quite a few have been shortened, mainly by using register
      asm variables. Use of the EX_TABLE macro helps  as well. The atomic ops,
      bit ops and locking inlines new use the Q-constraint if a newer gcc
      is used.  That results in slightly better code.
      
      Thanks to Christian Borntraeger for proof reading the changes.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      94c12cc7
  12. 27 9月, 2006 1 次提交
  13. 12 7月, 2006 1 次提交
  14. 01 7月, 2006 1 次提交
  15. 27 3月, 2006 2 次提交
  16. 18 2月, 2006 1 次提交
  17. 13 2月, 2006 1 次提交
  18. 08 2月, 2006 1 次提交
  19. 12 1月, 2006 1 次提交
  20. 11 1月, 2006 1 次提交
  21. 07 1月, 2006 1 次提交
  22. 13 9月, 2005 1 次提交
    • T
      [PATCH] x86-64: Fix 32bit sendfile · 83b942bd
      Tsuneo.Yoshioka@f-secure.com 提交于
      If we use 64bit kernel on ia64/x86_64/s390 architecture, and we run
      32bit binary on 32bit compatibility mode, sendfile system call seems be
      not set offset argument.
      
      This is because sendfile's return value is not zero but the code regards
      the result by return value is zero or not.
      
      This problem will be affect to ia64/x86_64/s390 and not affect to other
      architecture does not affect other architecture (mips/parisc/ppc64/sparc64).
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      83b942bd
  23. 14 7月, 2005 1 次提交
    • M
      [PATCH] s390: fadvise hint values. · 068e1b94
      Martin Schwidefsky 提交于
      Add special case for the POSIX_FADV_DONTNEED and POSIX_FADV_NOREUSE hint
      values for s390-64.  The user space values in the s390-64 glibc headers for
      these two defines have always been 6 and 7 instead of 4 and 5.  All 64 bit
      applications therefore use the "wrong" values.  To get these applications
      working without recompiling the kernel needs to accept the "wrong" values.
      Since the values for s390-31 are 4 and 5 the compat wrapper for fadvise64
      and fadvise64_64 need to rewrite the values for 31 bit system calls.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      068e1b94
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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