1. 04 7月, 2013 5 次提交
  2. 05 5月, 2013 1 次提交
  3. 01 5月, 2013 8 次提交
    • O
      coredump: change wait_for_dump_helpers() to use wait_event_interruptible() · dc7ee2aa
      Oleg Nesterov 提交于
      wait_for_dump_helpers() calls wake_up/kill_fasync from inside the
      wait_event-like loop.  This is not needed and in fact this is not
      strictly correct, we can/should do this only once after we change
      pipe->writers.  We could even check if it becomes zero.
      
      Change this code to use use wait_event_interruptible(), this can also
      help to make this wait freezable.
      
      With this patch we check pipe->readers without pipe_lock(), this is
      fine.  Once we see pipe->readers == 1 we know that the handler
      decremented the counter, this is all we need.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc7ee2aa
    • O
      coredump: factor out the setting of PF_DUMPCORE · 079148b9
      Oleg Nesterov 提交于
      Cleanup.  Every linux_binfmt->core_dump() sets PF_DUMPCORE, move this into
      zap_threads() called by do_coredump().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      079148b9
    • O
      coredump: introduce dump_interrupted() · 528f827e
      Oleg Nesterov 提交于
      By discussion with Mandeep.
      
      Change dump_write(), dump_seek() and do_coredump() to check
      signal_pending() and abort if it is true.  dump_seek() does this only
      before f_op->llseek(), otherwise it relies on dump_write().
      
      We need this change to ensure that the coredump won't delay suspend, and
      to ensure it reacts to SIGKILL "quickly enough", a core dump can take a
      lot of time.  In particular this can help oom-killer.
      
      We add the new trivial helper, dump_interrupted() to add the comments and
      to simplify the potential freezer changes.  Perhaps it will have more
      callers.
      
      Ideally it should do try_to_freeze() but then we need the unpleasant
      changes in dump_write() and wait_for_dump_helpers().  It is not trivial to
      change dump_write() to restart if f_op->write() fails because of
      freezing().  We need to handle the short writes, we need to clear
      TIF_SIGPENDING (and we can't rely on recalc_sigpending() unless we change
      it to check PF_DUMPCORE).  And if the buggy f_op->write() sets
      TIF_SIGPENDING we can not distinguish this case from the race with
      freeze_task() + __thaw_task().
      
      So we simply accept the fact that the freezer can truncate a core-dump but
      at least you can reliably suspend.  Hopefully we can tolerate this
      unlikely case and the necessary complications doesn't worth a trouble.
      But if we decide to make the coredumping freezable later we can do this on
      top of this change.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Acked-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      528f827e
    • O
      coredump: sanitize the setting of signal->group_exit_code · acdedd99
      Oleg Nesterov 提交于
      Now that the coredumping process can be SIGKILL'ed, the setting of
      ->group_exit_code in do_coredump() can race with complete_signal() and
      SIGKILL or 0x80 can be "lost", or wait(status) can report status ==
      SIGKILL | 0x80.
      
      But the main problem is that it is not clear to me what should we do if
      binfmt->core_dump() succeeds but SIGKILL was sent, that is why this patch
      comes as a separate change.
      
      This patch adds 0x80 if ->core_dump() succeeds and the process was not
      killed.  But perhaps we can (should?) re-set ->group_exit_code changed by
      SIGKILL back to "siginfo->si_signo |= 0x80" in case when core_dumped == T.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Tested-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      acdedd99
    • O
      coredump: ensure that SIGKILL always kills the dumping thread · 6cd8f0ac
      Oleg Nesterov 提交于
      prepare_signal() blesses SIGKILL sent to the dumping process but this
      signal can be "lost" anyway.  The problems is, complete_signal() sees
      SIGNAL_GROUP_EXIT and skips the "kill them all" logic.  And even if the
      dumping process is single-threaded (so the target is always "correct"),
      the group-wide SIGKILL is not recorded in task->pending and thus
      __fatal_signal_pending() won't be true.  A multi-threaded case has even
      more problems.
      
      And even ignoring all technical details, SIGNAL_GROUP_EXIT doesn't look
      right to me.  This coredumping process is not exiting yet, it can do a lot
      of work dumping the core.
      
      With this patch the dumping process doesn't have SIGNAL_GROUP_EXIT, we set
      signal->group_exit_task instead.  This makes signal_group_exit() true and
      thus this should equally close the races with exit/exec/stop but allows to
      kill the dumping thread reliably.
      
      Notes:
      	- It is not clear what should we do with ->group_exit_code
      	  if the dumper was killed, see the next change.
      
      	- we need more (hopefully straightforward) changes to ensure
      	  that SIGKILL actually interrupts the coredump. Basically we
      	  need to check __fatal_signal_pending() in dump_write() and
      	  dump_seek().
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Tested-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6cd8f0ac
    • O
      coredump: only SIGKILL should interrupt the coredumping task · 403bad72
      Oleg Nesterov 提交于
      There are 2 well known and ancient problems with coredump/signals, and a
      lot of related bug reports:
      
      - do_coredump() clears TIF_SIGPENDING but of course this can't help
        if, say, SIGCHLD comes after that.
      
        In this case the coredump can fail unexpectedly. See for example
        wait_for_dump_helper()->signal_pending() check but there are other
        reasons.
      
      - At the same time, dumping a huge core on the slow media can take a
        lot of time/resources and there is no way to kill the coredumping
        task reliably. In particular this is not oom_kill-friendly.
      
      This patch tries to fix the 1st problem, and makes the preparation for the
      next changes.
      
      We add the new SIGNAL_GROUP_COREDUMP flag set by zap_threads() to indicate
      that this process dumps the core.  prepare_signal() checks this flag and
      nacks any signal except SIGKILL.
      
      Note that this check tries to be conservative, in the long term we should
      probably treat the SIGNAL_GROUP_EXIT case equally but this needs more
      discussion.  See marc.info/?l=linux-kernel&m=120508897917439
      
      Notes:
      	- recalc_sigpending() doesn't check SIGNAL_GROUP_COREDUMP.
      	  The patch assumes that dump_write/etc paths should never
      	  call it, but we can change it as well.
      
      	- There is another source of TIF_SIGPENDING, freezer. This
      	  will be addressed separately.
      Signed-off-by: NOleg Nesterov <oleg@redhat.com>
      Tested-by: NMandeep Singh Baines <msb@chromium.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Neil Horman <nhorman@redhat.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Roland McGrath <roland@hack.frob.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      403bad72
    • L
      usermodehelper: split remaining calls to call_usermodehelper_fns() · 907ed132
      Lucas De Marchi 提交于
      These are the only users of call_usermodehelper_fns().  This function
      suffers from not being able to determine if the cleanup is called.  Even
      if in this places the cleanup pointer is NULL, convert them to use the
      separate call_usermodehelper_setup() + call_usermodehelper_exec()
      functions so we can remove the _fns variant.
      Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      907ed132
    • L
      coredump: remove trailling whitespace · fb96c475
      Lucas De Marchi 提交于
      Signed-off-by: NLucas De Marchi <lucas.demarchi@profusion.mobi>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fb96c475
  4. 10 4月, 2013 2 次提交
  5. 28 2月, 2013 1 次提交
  6. 23 2月, 2013 1 次提交
  7. 29 11月, 2012 1 次提交
  8. 17 10月, 2012 1 次提交
    • A
      fix a leak in replace_fd() users · 45525b26
      Al Viro 提交于
      replace_fd() began with "eats a reference, tries to insert into
      descriptor table" semantics; at some point I'd switched it to
      much saner current behaviour ("try to insert into descriptor
      table, grabbing a new reference if inserted; caller should do
      fput() in any case"), but forgot to update the callers.
      Mea culpa...
      
      [Spotted by Pavel Roskin, who has really weird system with pipe-fed
      coredumps as part of what he considers a normal boot ;-)]
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      45525b26
  9. 06 10月, 2012 3 次提交
  10. 03 10月, 2012 1 次提交