1. 17 10月, 2007 1 次提交
    • N
      core_pattern: ignore RLIMIT_CORE if core_pattern is a pipe · 7dc0b22e
      Neil Horman 提交于
      For some time /proc/sys/kernel/core_pattern has been able to set its output
      destination as a pipe, allowing a user space helper to receive and
      intellegently process a core.  This infrastructure however has some
      shortcommings which can be enhanced.  Specifically:
      
      1) The coredump code in the kernel should ignore RLIMIT_CORE limitation
         when core_pattern is a pipe, since file system resources are not being
         consumed in this case, unless the user application wishes to save the core,
         at which point the app is restricted by usual file system limits and
         restrictions.
      
      2) The core_pattern code should be able to parse and pass options to the
         user space helper as an argv array.  The real core limit of the uid of the
         crashing proces should also be passable to the user space helper (since it
         is overridden to zero when called).
      
      3) Some miscellaneous bugs need to be cleaned up (specifically the
         recognition of a recursive core dump, should the user mode helper itself
         crash.  Also, the core dump code in the kernel should not wait for the user
         mode helper to exit, since the same context is responsible for writing to
         the pipe, and a read of the pipe by the user mode helper will result in a
         deadlock.
      
      This patch:
      
      Remove the check of RLIMIT_CORE if core_pattern is a pipe.  In the event that
      core_pattern is a pipe, the entire core will be fed to the user mode helper.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Cc: <martin.pitt@ubuntu.com>
      Cc: <wwoods@redhat.com>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7dc0b22e
  2. 03 10月, 2007 2 次提交
  3. 09 6月, 2007 1 次提交
  4. 10 2月, 2007 1 次提交
  5. 09 12月, 2006 1 次提交
  6. 01 7月, 2006 1 次提交
  7. 26 6月, 2006 1 次提交
  8. 22 5月, 2006 1 次提交
    • A
      [PATCH] binfmt_flat: don't check for EMFILE · df88912a
      Andrew Morton 提交于
      Bernd Schmidt points out that binfmt_flat is now leaving the exec file open
      while the application runs.  This offsets all the application's fd numbers.
      We should have closed the file within exec(), not at exit()-time.
      
      But there doesn't seem to be a lot of point in doing all this just to avoid
      going over RLIMIT_NOFILE by one fd for a few microseconds.  So take the EMFILE
      checking out again.  This will cause binfmt_flat to again fail LTP's
      exec-should-return-EMFILE-when-fdtable-is-full test.  That test appears to be
      wrong anyway - Open Group specs say nothing about exec() returning EMFILE.
      
      Cc: Bernd Schmidt <bernd.schmidt@analog.com>
      Cc: Greg Ungerer <gerg@uclinux.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      df88912a
  9. 26 3月, 2006 1 次提交
  10. 11 1月, 2006 2 次提交
  11. 30 10月, 2005 1 次提交
  12. 02 9月, 2005 1 次提交
  13. 07 6月, 2005 1 次提交
  14. 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