Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 21 Oct 2006 08:58:04 +0800
From:      David Xu <davidxu@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org
Subject:   Re: cvs commit: src/sys/kern kern_sig.c
Message-ID:  <200610210858.04180.davidxu@freebsd.org>
In-Reply-To: <200610201619.k9KGJLZH076566@repoman.freebsd.org>
References:  <200610201619.k9KGJLZH076566@repoman.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 21 October 2006 00:19, John Baldwin wrote:
> jhb         2006-10-20 16:19:21 UTC
>
>   FreeBSD src repository
>
>   Modified files:
>     sys/kern             kern_sig.c
>   Log:
>   Remove the check that prevented signals from being delivered to exiting
>   processes.  It was originally added back when support for Linux threads
>   (and thus shared sigacts objects) was added, but no one knows why.  My
>   guess is that at some point during the Linux threads patches, the sigacts
>   object was torn down during exit1(), so this check was added to prevent
>   a panic for that race.  However, the stuff that was actually committed to
>   the tree doesn't teardown sigacts until wait() making the above race
> moot. Re-allowing signals here lets one interrupt a NFS request during
> process teardown (such as closing descriptors) on an interruptible mount.
>
>   Requested by:   kib (long time ago)
>   MFC after:      1 week
>
>   Revision  Changes    Path
>   1.333     +1 -3      src/sys/kern/kern_sig.c
This commit opens a window that may cause memory leak, since we have
signal queue in -CURRENT now, signal queue uses memory, before this
change, the P_WEXIT will prevents new signal to be queued, after the
flag is set in kern_exit, we call signqueue_flush to free memory. I think
we should move sigqueue_flush down to a safe point where the
PROC lock is no longer unlocked or move it to a place after p_state is set
to PRS_ZOMBIE.

David Xu



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