1. 30 10月, 2005 1 次提交
  2. 22 10月, 2005 1 次提交
    • R
      [PATCH] Call exit_itimers from do_exit, not __exit_signal · 25f407f0
      Roland McGrath 提交于
      When I originally moved exit_itimers into __exit_signal, that was the only
      place where we could reliably know it was the last thread in the group
      dying, without races.  Since then we've gotten the signal_struct.live
      counter, and do_exit can reliably do group-wide cleanup work.
      
      This patch moves the call to do_exit, where it's made without locks.  This
      avoids the deadlock issues that the old __exit_signal code's comment talks
      about, and the one that Oleg found recently with process CPU timers.
      
      [ This replaces e03d13e9, which is why
        it was just reverted. ]
      Signed-off-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      25f407f0
  3. 11 10月, 2005 1 次提交
    • H
      [PATCH] Fix signal sending in usbdevio on async URB completion · 46113830
      Harald Welte 提交于
      If a process issues an URB from userspace and (starts to) terminate
      before the URB comes back, we run into the issue described above.  This
      is because the urb saves a pointer to "current" when it is posted to the
      device, but there's no guarantee that this pointer is still valid
      afterwards.
      
      In fact, there are three separate issues:
      
      1) the pointer to "current" can become invalid, since the task could be
         completely gone when the URB completion comes back from the device.
      
      2) Even if the saved task pointer is still pointing to a valid task_struct,
         task_struct->sighand could have gone meanwhile.
      
      3) Even if the process is perfectly fine, permissions may have changed,
         and we can no longer send it a signal.
      
      So what we do instead, is to save the PID and uid's of the process, and
      introduce a new kill_proc_info_as_uid() function.
      Signed-off-by: NHarald Welte <laforge@gnumonks.org>
      [ Fixed up types and added symbol exports ]
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      46113830
  4. 09 10月, 2005 2 次提交
    • A
      [PATCH] gfp flags annotations - part 1 · dd0fc66f
      Al Viro 提交于
       - added typedef unsigned int __nocast gfp_t;
      
       - replaced __nocast uses for gfp flags with gfp_t - it gives exactly
         the same warnings as far as sparse is concerned, doesn't change
         generated code (from gcc point of view we replaced unsigned int with
         typedef) and documents what's going on far better.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dd0fc66f
    • O
      [PATCH] fix do_coredump() vs SIGSTOP race · 788e05a6
      Oleg Nesterov 提交于
      Let's suppose we have 2 threads in thread group:
      	A - does coredump
      	B - has pending SIGSTOP
      
      thread A						thread B
      
      do_coredump:						get_signal_to_deliver:
      
        lock(->sighand)
        ->signal->flags = SIGNAL_GROUP_EXIT
        unlock(->sighand)
      
      							lock(->sighand)
      							signr = dequeue_signal()
      								->signal->flags |= SIGNAL_STOP_DEQUEUED
      								return SIGSTOP;
      
      							do_signal_stop:
      							    unlock(->sighand)
      
        coredump_wait:
      
            zap_threads:
                lock(tasklist_lock)
                send SIGKILL to B
                    // signal_wake_up() does nothing
                unlock(tasklist_lock)
      
      							    lock(tasklist_lock)
      							    lock(->sighand)
      							    re-check sig->flags & SIGNAL_STOP_DEQUEUED, yes
      							    set_current_state(TASK_STOPPED);
      							    finish_stop:
      							        schedule();
      							            // ->state == TASK_STOPPED
      
            wait_for_completion(&startup_done)
               // waits for complete() from B,
               // ->state == TASK_UNINTERRUPTIBLE
      
      We can't wake up 'B' in any way:
      
      	SIGCONT will be ignored because handle_stop_signal() sees
      	->signal->flags & SIGNAL_GROUP_EXIT.
      
      	sys_kill(SIGKILL)->__group_complete_signal() will choose
      	uninterruptible 'A', so it can't help.
      
      	sys_tkill(B, SIGKILL) will be ignored by specific_send_sig_info()
      	because B already has pending SIGKILL.
      
      This scenario is not possbile if 'A' does do_group_exit(), because
      it sets sig->flags = SIGNAL_GROUP_EXIT and delivers SIGKILL to
      subthreads atomically, holding both tasklist_lock and sighand->lock.
      That means that do_signal_stop() will notice !SIGNAL_STOP_DEQUEUED
      after re-locking ->sighand. And it is not possible to any other
      thread to re-add SIGNAL_STOP_DEQUEUED later, because dequeue_signal()
      can only return SIGKILL.
      
      I think it is better to change do_coredump() to do sigaddset(SIGKILL)
      and signal_wake_up() under sighand->lock, but this patch is much
      simpler.
      Signed-off-by: NOleg Nesterov <oleg@tv-sign.ru>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      788e05a6
  5. 30 9月, 2005 1 次提交
  6. 24 9月, 2005 1 次提交
    • L
      Make sure SIGKILL gets proper respect · 188a1eaf
      Linus Torvalds 提交于
      Bhavesh P. Davda <bhavesh@avaya.com> noticed that SIGKILL wouldn't
      properly kill a process under just the right cicumstances: a stopped
      task that already had another signal queued would get the SIGKILL
      queued onto the shared queue, and there it would remain until SIGCONT.
      
      This simplifies the signal acceptance logic, and fixes the bug in the
      process.
      
      Losely based on an earlier patch by Bhavesh.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      188a1eaf
  7. 11 9月, 2005 1 次提交
  8. 08 9月, 2005 2 次提交
  9. 18 8月, 2005 1 次提交
    • B
      [PATCH] NPTL signal delivery deadlock fix · dd12f48d
      Bhavesh P. Davda 提交于
      This bug is quite subtle and only happens in a very interesting
      situation where a real-time threaded process is in the middle of a
      coredump when someone whacks it with a SIGKILL.  However, this deadlock
      leaves the system pretty hosed and you have to reboot to recover.
      
      Not good for real-time priority-preemption applications like our
      telephony application, with 90+ real-time (SCHED_FIFO and SCHED_RR)
      processes, many of them multi-threaded, interacting with each other for
      high volume call processing.
      Acked-by: NRoland McGrath <roland@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      dd12f48d
  10. 26 6月, 2005 1 次提交
    • C
      [PATCH] Cleanup patch for process freezing · 3e1d1d28
      Christoph Lameter 提交于
      1. Establish a simple API for process freezing defined in linux/include/sched.h:
      
         frozen(process)		Check for frozen process
         freezing(process)		Check if a process is being frozen
         freeze(process)		Tell a process to freeze (go to refrigerator)
         thaw_process(process)	Restart process
         frozen_process(process)	Process is frozen now
      
      2. Remove all references to PF_FREEZE and PF_FROZEN from all
         kernel sources except sched.h
      
      3. Fix numerous locations where try_to_freeze is manually done by a driver
      
      4. Remove the argument that is no longer necessary from two function calls.
      
      5. Some whitespace cleanup
      
      6. Clear potential race in refrigerator (provides an open window of PF_FREEZE
         cleared before setting PF_FROZEN, recalc_sigpending does not check
         PF_FROZEN).
      
      This patch does not address the problem of freeze_processes() violating the rule
      that a task may only modify its own flags by setting PF_FREEZE. This is not clean
      in an SMP environment. freeze(process) is therefore not SMP safe!
      Signed-off-by: NChristoph Lameter <christoph@lameter.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e1d1d28
  11. 24 6月, 2005 1 次提交
  12. 25 5月, 2005 1 次提交
  13. 06 5月, 2005 1 次提交
    • S
      The attached patch addresses the problem with getting the audit daemon · c2f0c7c3
      Steve Grubb 提交于
      shutdown credential information. It creates a new message type 
      AUDIT_TERM_INFO, which is used by the audit daemon to query who issued the 
      shutdown. 
      
      It requires the placement of a hook function that gathers the information. The 
      hook is after the DAC & MAC checks and before the function returns. Racing 
      threads could overwrite the uid & pid - but they would have to be root and 
      have policy that allows signalling the audit daemon. That should be a 
      manageable risk.
      
      The userspace component will be released later in audit 0.7.2. When it 
      receives the TERM signal, it queries the kernel for shutdown information. 
      When it receives it, it writes the message and exits. The message looks 
      like this:
      
      type=DAEMON msg=auditd(1114551182.000) auditd normal halt, sending pid=2650 
      uid=525, auditd pid=1685
      Signed-off-by: NSteve Grubb <sgrubb@redhat.com>
      Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
      c2f0c7c3
  14. 01 5月, 2005 1 次提交
  15. 17 4月, 2005 2 次提交