1. 01 May, 2013 5 commits
    • Oleg Nesterov's avatar
      coredump: sanitize the setting of signal->group_exit_code · acdedd99
      Oleg Nesterov authored
      
      
      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: default avatarOleg Nesterov <oleg@redhat.com>
      Tested-by: default avatarMandeep 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      acdedd99
    • Oleg Nesterov's avatar
      coredump: ensure that SIGKILL always kills the dumping thread · 6cd8f0ac
      Oleg Nesterov authored
      
      
      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: default avatarOleg Nesterov <oleg@redhat.com>
      Tested-by: default avatarMandeep 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6cd8f0ac
    • Oleg Nesterov's avatar
      coredump: only SIGKILL should interrupt the coredumping task · 403bad72
      Oleg Nesterov authored
      
      
      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: default avatarOleg Nesterov <oleg@redhat.com>
      Tested-by: default avatarMandeep 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      403bad72
    • Lucas De Marchi's avatar
      usermodehelper: split remaining calls to call_usermodehelper_fns() · 907ed132
      Lucas De Marchi authored
      
      
      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: default avatarLucas 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      907ed132
    • Lucas De Marchi's avatar
      coredump: remove trailling whitespace · fb96c475
      Lucas De Marchi authored
      
      Signed-off-by: default avatarLucas 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      fb96c475
  2. 28 Feb, 2013 1 commit
  3. 23 Feb, 2013 1 commit
  4. 29 Nov, 2012 1 commit
  5. 16 Oct, 2012 1 commit
    • Al Viro's avatar
      fix a leak in replace_fd() users · 45525b26
      Al Viro authored
      
      
      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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      45525b26
  6. 05 Oct, 2012 3 commits
  7. 03 Oct, 2012 1 commit