1. 14 9月, 2008 1 次提交
  2. 20 8月, 2008 1 次提交
  3. 31 7月, 2008 3 次提交
  4. 19 7月, 2008 1 次提交
  5. 18 7月, 2008 1 次提交
  6. 30 4月, 2008 1 次提交
  7. 26 4月, 2008 2 次提交
  8. 17 4月, 2008 1 次提交
    • R
      x86 vDSO: don't use disabled vDSO for signal trampoline · 1a3e4ca4
      Roland McGrath 提交于
      If the vDSO was not mapped, don't use it as the "restorer" for a signal
      handler.  Whether we have a pointer in mm->context.vdso depends on what
      happened at exec time, so we shouldn't check any global flags now.
      
      Background:
      
      Currently, every 32-bit exec gets the vDSO mapped even if it's disabled
      (the process just doesn't get told about it).  Because it's in fact
      always there, the bug that this patch fixes cannot happen now.  With
      the second patch, it won't be mapped at all when it's disabled, which is
      one of the things that people might really want when they disable it (so
      nothing they didn't ask for goes into their address space).
      
      The 32-bit signal handler setup when SA_RESTORER is not used refers to
      current->mm->context.vdso without regard to whether the vDSO has been
      disabled when the process was exec'd.  This patch fixes this not to use
      it when it's null, which becomes possible after the second patch. (This
      never happens in normal use, because glibc's sigaction call uses
      SA_RESTORER unless glibc detected the vDSO.)
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1a3e4ca4
  9. 07 3月, 2008 1 次提交
  10. 30 1月, 2008 7 次提交
  11. 11 10月, 2007 1 次提交
  12. 09 5月, 2007 1 次提交
  13. 13 2月, 2007 2 次提交
  14. 07 12月, 2006 1 次提交
  15. 31 10月, 2006 1 次提交
  16. 26 9月, 2006 4 次提交
  17. 27 6月, 2006 1 次提交
  18. 12 1月, 2006 1 次提交
  19. 10 10月, 2005 1 次提交
  20. 24 6月, 2005 1 次提交
    • R
      [PATCH] x86_64: never block forced SIGSEGV · 0928d6ef
      Roland McGrath 提交于
      This is the x86_64 version of the signal fix I just posted for i386.
      
      This problem was first noticed on PPC and has already been fixed there.
      But the exact same issue applies to other platforms in the same way.  The
      signal blocking for sa_mask and the handled signal takes place after the
      handler setup.  When the stack is bogus, the handler setup forces a
      SIGSEGV.  But then this will be blocked, and returning to user mode will
      fault again and iterate.  This patch fixes the problem by checking whether
      signal handler setup failed, and not doing the signal-blocking if so.  This
      copies what was done in the ppc code.  I think all architectures' signal
      handler setup code follows this pattern and needs the change.
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Cc: Andi Kleen <ak@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      0928d6ef
  21. 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