Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 11 Oct 2009 16:49:30 +0000 (UTC)
From:      Konstantin Belousov <kib@FreeBSD.org>
To:        cvs-src-old@freebsd.org
Subject:   cvs commit: src/sys/kern kern_sig.c kern_thr.c subr_trap.c src/sys/sys signalvar.h
Message-ID:  <200910111650.n9BGoCuK057206@repoman.freebsd.org>

next in thread | raw e-mail | index | archive | help
kib         2009-10-11 16:49:30 UTC

  FreeBSD src repository

  Modified files:
    sys/kern             kern_sig.c kern_thr.c subr_trap.c 
    sys/sys              signalvar.h 
  Log:
  SVN rev 197963 on 2009-10-11 16:49:30Z by kib
  
  Currently, when signal is delivered to the process and there is a thread
  not blocking the signal, signal is placed on the thread sigqueue. If
  the selected thread is in kernel executing thr_exit() or sigprocmask()
  syscalls, then signal might be not delivered to usermode for arbitrary
  amount of time, and for exiting thread it is lost.
  
  Put process-directed signals to the process queue unconditionally,
  selecting the thread to deliver the signal only by the thread returning
  to usermode, since only then the thread can handle delivery of signal
  reliably. For exiting thread or thread that has blocked some signals,
  check whether the newly blocked signal is queued for the process, and
  try to find a thread to wakeup for delivery, in reschedule_signal(). For
  exiting thread, assume that all signals are blocked.
  
  Change cursig() and postsig() to look both into the thread and process
  signal queues. When there is a signal that thread returning to usermode
  could consume, TDF_NEEDSIGCHK flag is not neccessary set now. Do
  unlocked read of p_siglist and p_pendingcnt to check for queued signals.
  
  Note that thread that has a signal unblocked might get spurious wakeup
  and EINTR from the interruptible system call now, due to the possibility
  of being selected by reschedule_signals(), while other thread returned
  to usermode earlier and removed the signal from process queue. This
  should not cause compliance issues, since the thread has not blocked a
  signal and thus should be ready to receive it anyway.
  
  Reported by:    Justin Teller <justin.teller gmail com>
  Reviewed by:    davidxu, jilles
  MFC after:      1 month
  
  Revision  Changes    Path
  1.375     +102 -29   src/sys/kern/kern_sig.c
  1.79      +1 -1      src/sys/kern/kern_thr.c
  1.309     +10 -1     src/sys/kern/subr_trap.c
  1.80      +5 -3      src/sys/sys/signalvar.h



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910111650.n9BGoCuK057206>