1. 27 1月, 2007 1 次提交
    • R
      [PATCH] x86_64 ia32 vDSO: use VM_ALWAYSDUMP · e03f0ca1
      Roland McGrath 提交于
      This patch fixes ia32 core dumps on x86_64 to include just one phdr for the
      vDSO vma.  Currently it writes a confused format with two phdrs for the
      address, one without contents and one with.  This patch removes the
      special-case core writing macros for the ia32 vDSO.  Instead, it uses
      VM_ALWAYSDUMP in the vma.  This changes core dumps so they no longer include
      the non-PT_LOAD phdrs from the vDSO, consistent with fixed native i386 core
      dumps.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e03f0ca1
  2. 08 12月, 2006 2 次提交
  3. 04 10月, 2006 1 次提交
  4. 31 8月, 2006 1 次提交
  5. 11 7月, 2006 1 次提交
    • M
      [PATCH] x86_64: Bring x86-64 ia32 emul in sync with i386 on READ_IMPLIES_EXEC enabling · 3391c22e
      Markus Schoder 提交于
      Currently ia32 binaries behave differently with respect to enabling
      READ_IMPLIES_EXEC.  On i386 a binary with the exec_stack flag set is
      executed with READ_IMPLIES_EXEC enabled as well.  The same binary
      executes without READ_IMPLIES_EXEC on x86-64.
      
      This causes binaries that work on i386 to fail on x86-64 which goes
      somewhat against the whole 32 bit emulation idea.
      
      It has been argued that READ_IMPLIES_EXEC should not be enabled at all
      for binaries that have the exec_stack flag.  Which is probably a valid
      point.  However until this is clarified I think x86-64 should behave the
      same for ia32 binaries as i386.
      
      The following patch brings x86-64 in sync with i386 for ia32 binaries.
      Signed-off-by: NMarkus Schoder <lists@gammarayburst.de>
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3391c22e
  6. 31 5月, 2006 1 次提交
  7. 26 3月, 2006 1 次提交
  8. 17 1月, 2006 1 次提交
  9. 13 1月, 2006 1 次提交
  10. 13 12月, 2005 1 次提交
  11. 15 11月, 2005 1 次提交
  12. 15 9月, 2005 1 次提交
    • H
      [PATCH] error path in setup_arg_pages() misses vm_unacct_memory() · 2fd4ef85
      Hugh Dickins 提交于
      Pavel Emelianov and Kirill Korotaev observe that fs and arch users of
      security_vm_enough_memory tend to forget to vm_unacct_memory when a
      failure occurs further down (typically in setup_arg_pages variants).
      
      These are all users of insert_vm_struct, and that reservation will only
      be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some
      cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't.
      
      So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into
      Committed_AS each time they're run.  But don't add VM_ACCOUNT to them,
      it's inappropriate to reserve against the very unlikely case that gdb
      be used to COW a vDSO page - we ought to do something about that in
      do_wp_page, but there are yet other inconsistencies to be resolved.
      
      The safe and economical way to fix this is to let insert_vm_struct do
      the security_vm_enough_memory check when it finds VM_ACCOUNT is set.
      
      And the MIPS irix_brk has been calling security_vm_enough_memory before
      calling do_brk which repeats it, doubly accounting and so also leaking.
      Remove that, and all the fs and arch calls to security_vm_enough_memory:
      give it a less misleading name later on.
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Signed-Off-By: NKirill Korotaev <dev@sw.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2fd4ef85
  13. 22 6月, 2005 1 次提交
    • S
      [PATCH] x86_64: TASK_SIZE fixes for compatibility mode processes · 84929801
      Suresh Siddha 提交于
      Appended patch will setup compatibility mode TASK_SIZE properly.  This will
      fix atleast three known bugs that can be encountered while running
      compatibility mode apps.
      
      a) A malicious 32bit app can have an elf section at 0xffffe000.  During
         exec of this app, we will have a memory leak as insert_vm_struct() is
         not checking for return value in syscall32_setup_pages() and thus not
         freeing the vma allocated for the vsyscall page.  And instead of exec
         failing (as it has addresses > TASK_SIZE), we were allowing it to
         succeed previously.
      
      b) With a 32bit app, hugetlb_get_unmapped_area/arch_get_unmapped_area
         may return addresses beyond 32bits, ultimately causing corruption
         because of wrap-around and resulting in SEGFAULT, instead of returning
         ENOMEM.
      
      c) 32bit app doing this below mmap will now fail.
      
        mmap((void *)(0xFFFFE000UL), 0x10000UL, PROT_READ|PROT_WRITE,
      	MAP_FIXED|MAP_PRIVATE|MAP_ANON, 0, 0);
      Signed-off-by: NZou Nan hai <nanhai.zou@intel.com>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      84929801
  14. 17 4月, 2005 2 次提交
    • A
      [PATCH] x86_64: Use a VMA for the 32bit vsyscall · 1e014410
      Andi Kleen 提交于
      Use a real VMA to map the 32bit vsyscall page
      
      This interacts better with Hugh's upcomming VMA walk optimization
      Also removes some ugly special cases.
      
      Code roughly modelled after the ppc64 vdso version from Ben Herrenschmidt.
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1e014410
    • 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